What's Actually in Our MCP Server (and Why an Agent Can't Publish a Single Word)
13 July 2026
MCP is the acronym everyone started asking me about this year. Model Context Protocol. It’s an open standard for connecting AI agents to outside tools, and we built a server for it early because it’s exactly the kind of thing our whole product is pointed at. If your knowledge is the source of truth, then the agents acting on your behalf should be reading from it, not guessing.
But “can an agent read our knowledge base” turns out to be the easy question. The one that actually matters, the one I get on calls, is quieter: what can the agent change? So let me walk through what our MCP server actually exposes, and then the part I care most about, which is everything it deliberately won’t let an agent do.
Three kinds of tools
The server gives a connected agent eighteen tools, and they fall into three groups.
Read tools. These let an agent search your articles, ask a question and get an answer synthesised from your content with citations, pull a specific article, and browse your document library. This is the bulk of what agents do day to day. Someone’s AI assistant needs to know your refund policy, so it searches your knowledge base and reads the real one, instead of inventing something plausible.
Write tools. These let an agent create a draft article, suggest an update to an existing one, or bulk-import content. Useful when an agent notices a gap, spots that a procedure has drifted, or you’re migrating a pile of old documentation in.
Analytics tools. These let an agent look at search trends, chat patterns, content gaps, and review history, so it can tell you what’s missing or what’s gone stale. An agent that can see which searches returned nothing is an agent that can suggest the article you should write next.
That’s the surface. Read, write, analyse. Nothing exotic.
The line we won’t cross
Here’s the design decision the whole thing hangs on. Every single write an agent makes lands as a draft for a human to review. Not live. Not published. A draft, sitting in a queue, waiting for a person to look at it.
An agent connected to KnowledgeScout can never publish, archive, or delete content. It can propose. It cannot commit. A human always makes the final call, and every action the agent took is logged and visible in your analytics.
I know that sounds like a limitation. It’s the opposite. It’s the feature.
The failure mode for AI on top of a knowledge base isn’t that the agent can’t write. It’s that it writes something confident and wrong, and that wrong thing becomes the source everyone else trusts. Once bad content is live and being cited, by your team, by your customer-facing bot, by the next agent that reads it, you’ve got a problem that spreads. The review queue is the circuit breaker. An agent can do the tedious 80 percent, draft the article, flag the stale one, rough out the migration, and a human spends two minutes deciding whether it’s right before anyone sees it.
Drafts, not direct writes. That’s the whole philosophy in three words.
Internal and external, same server, different jobs
Worth naming that “AI agent” covers two quite different situations, and the server handles both.
There are internal agents, the ones acting for people inside your business. Someone’s Claude or Copilot setup, a custom build your team wired together. They read from the substrate so their answers are grounded in your verified content rather than whatever they inferred.
And there are external agents, the customer-facing ones. A support bot answering the public. Same principle, much tighter door: instead of the full eighteen, an external agent gets a subset of five read-only tools, enough to search your public articles and documents and nothing else. It only ever sees the content you’ve made public, and it still can’t change a thing.
Both read from one knowledge base. You maintain the truth once, and every agent, yours and your customers’, works from the same copy.
The honest bit
Two admissions.
First, this approach is slower than letting an agent write straight to your live knowledge base. That’s true, and it’s on purpose. If you want an AI that edits your source of truth with no human in the loop, we are not the tool for you, and I’d gently suggest that’s a decision you’ll regret the first time it’s confidently wrong at scale.
Second, an MCP server is only as good as the knowledge underneath it. Connect an agent to a stale, contradictory knowledge base and you’ve just given it faster access to bad answers. The server matters because of what it sits on top of: content with review dates, version history, and human editors who keep it honest. The protocol is plumbing. The water is your knowledge.
MCP integration runs on our Business and Enterprise plans and works with any tool that speaks MCP, including Claude, GitHub Copilot, and Cursor. If you want the specifics of what’s on which plan, the pricing page has the numbers, no call required.
The interesting thing about agents isn’t how much you let them do. It’s how carefully you decide what they can’t.
The KnowledgeScout Team