---
type: "Article"
title: "Designing an MCP Server Agents Cannot Misuse: Lessons from FAQ Hub"
description: "What we learned exposing a shared SaaS platform to AI agents over the Model Context Protocol: scoped keys, plan-then-apply tools, explicit publish and a gap feedback loop."
resource: "https://www.theknowledgeelephant.com/blog/designing-an-mcp-server-agents-cannot-misuse/"
tags:
  - "Model Context Protocol"
  - "Agentic AI"
  - "API design"
  - "FAQ Hub"
status: "stable"
stale_after: "2027-05-07"
tke:
  published_at: "2026-11-07"
  author: "Dane Hollenbach"
  category: "Agentic Workflows"
  service: "ai-integration-agentic-workflows"
---
# Designing an MCP Server Agents Cannot Misuse: Lessons from FAQ Hub

> **Answer:** Treat an MCP server as a product API for a probabilistic caller. Bind every key to one customer and product with least-privilege permissions, split writes into export, plan, apply and publish steps, keep publication an explicit and audited action, treat all imported content as untrusted data, and give agents a way to report what they could not answer.

FAQ Hub, our help-centre and AI assistant platform that serves many businesses from one system, exposes its content to AI agents through a [Model Context Protocol](https://modelcontextprotocol.io) server. Authoring agents in IDEs and pipelines use it to keep help content in sync with a product's repository. Support agents use it to read published knowledge.

Exposing a platform shared by many customers to agents forced us to make design decisions that apply to any MCP server or agent tool surface. Here are the ones that mattered most.

## 1. One key, one customer, one product, explicit permissions

Every MCP request authenticates with a product API key. The customer and product come from the key, never from tool arguments, so an agent cannot ask for another customer's content even if a prompt tells it to.

Keys carry explicit scopes, and we ship presets rather than asking customers to compose them:

- A **support agent** preset can read published knowledge and report gaps. It can never see drafts.
- A **writer** preset can read content and create plans and drafts.
- **Admin** keys exist, but are not what we recommend for automation.

Least privilege only works if the least-privileged option is the obvious one. Presets make it obvious.

## 2. Split every write into plan and apply

Agents are good at producing changes and bad at knowing when they are wrong. So no tool writes directly. Content changes go through a sequence:

1. **Export** the current state, so the agent works from facts rather than memory.
2. **Plan** a change set. The server validates it and returns a dry-run diff: what would be created, updated or left alone.
3. **Apply** the plan, which creates drafts only, with idempotency so a retry does not duplicate work.
4. **Publish** as a separate, explicit step.

The plan step is where most mistakes are caught, by the agent itself, by a human reviewer or by validation rules, before anything changes.

## 3. Publication is a human decision, and the record says so

Publishing is the moment content reaches customers, so it stays explicit and attributable. Published knowledge carries a trust tier: content published by an identified person is marked human-reviewed; content published through automation is marked as such. We never upgrade automation to "human" because we cannot prove a person approved an API call.

That distinction flows into our [Open Knowledge Format](/index.md) exports, where each concept's `verified` metadata records who or what published it.

## 4. Imported content is data, never instructions

Agents bring content in from repositories, documentation sites and other knowledge bundles. Every file is treated as untrusted:

- Bounded size and file count, safe paths only.
- Markdown converted with raw HTML disabled, then run through the same sanitising validator as any other input.
- Links rewritten only when they point at content inside the import, so nothing points at a page that does not exist.
- The import produces a dry-run plan like any other change. Nothing is written until a caller applies it.

Prompt injection is much less dangerous when the content an agent reads cannot change what the server allows.

## 5. Close the loop with gap reporting

The most valuable tool we added was not a write tool. It lets a support agent report a question it could not answer from published knowledge. Gap reports are deduplicated, rate-limited and visible only to that customer, and zero-result agent searches are tracked the same way as zero-result searches from human visitors.

Authoring agents can then list open gaps, search existing content and propose new articles through the normal plan-and-review flow. The system improves from its own failures, with a person still deciding what gets published.

## What carries over to your platform

You do not need to be building a knowledge product for these lessons to apply. Any MCP server or agent tool surface benefits from the same rules:

- Derive scope from credentials, not arguments.
- Offer least-privilege presets.
- Make writes plan-then-apply, idempotent and reviewable.
- Keep irreversible or customer-facing actions explicit and attributed.
- Treat everything an agent reads as data.
- Give agents a structured way to say "I could not do this".

Our [AI integration and agentic workflows](https://www.theknowledgeelephant.com/services/ai-integration-agentic-workflows/) practice designs tool surfaces like this for existing products, and you can see the production version in [FAQ Hub](https://www.theknowledgeelephant.com/products/faq-hub/).

## Related

- [Keeping customer data separate when AI agents call your systems](/blog/keeping-customer-data-separate-with-ai-agents.md) - the data-separation side of the same problem
- [Agentic workflows in regulated fintech](/blog/agentic-workflows-in-regulated-fintech.md) - propose-and-approve for money movement
- [What AI readiness actually means](/blog/what-ai-readiness-means.md) - safe system connections is area three