A knowledge base through MCP: trace one search from request to source

MCP can expose a knowledge tool to an AI application. The useful result is a traceable piece of evidence, not a promise that every source or permission is automatically connected.

A connection is not yet an answer

An assistant connected to a company knowledge base still has to find the right source, retrieve enough of it and avoid inventing the missing details. MCP provides a way for a client and server to exchange requests and results; your application decides which knowledge exists behind that interface and who may use it.

This is an architecture guide with an illustrative tool contract, not an installation tutorial. The tool name and company documents below are fictional. Do not paste them into a client expecting a live HeyBrain endpoint.

The pieces in one small example

Imagine a fictional studio with a current travel guide. Its AI application has an MCP client. A server exposes a read-only knowledge search tool connected to the studio’s approved document collection. The user asks: “Can I expense a taxi from the airport?”

The MCP server’s tool definition tells the client what the search tool does and which arguments it accepts. The application must also establish the user’s identity and allowed scope through its actual access design; a query string saying “I work here” is not authorization.

The MCP tools specification defines tool discovery, input schemas and tool calls. It does not turn a custom search tool into an automatically complete, permission-correct mirror of a source system.

An illustrative call and returned passage

Assume the server advertises a tool named search_travel_policy whose required input is a string called query. Its implementation searches only the permitted travel collection. A client could issue the following JSON-RPC request. The name and argument are specific to this example, not standard MCP tools.

{"jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": {"name": "search_travel_policy", "arguments": {"query": "airport taxi reimbursement"}}}

For readability, the fictional tool result is shown as fields rather than a complete wire response. In an MCP response, the server can return text in the result’s content array; this example’s source labels would be content supplied by the application.

Answer only the question the passage supports

A grounded answer would be: “Yes, for approved business travel, up to $60 per trip. Attach the receipt to your claim. That is what section 4 of the travel guide, revision 6, says.” The source reference should let the authorized user inspect the passage in the application.

The assistant should not add “your manager can approve anything above $60” or “submit it within 30 days.” Neither statement appears in the returned evidence. A follow-up about exceptions needs another relevant source; if none is found, the answer should say that the available result does not establish the exception policy.

This is where a knowledge interface becomes useful: it supplies bounded evidence for an answer. For a more detailed claim-by-claim example, see checking hallucinations against company data.

Define failure behavior before broadening access

If the search returns no matching passage, the assistant should report that it could not find support in the searched collection. That is different from concluding that no policy exists anywhere.

If the server denies access, the client should not bypass it by asking another agent to retrieve the same document under a broader identity. The application also needs to decide what it can safely reveal about a denied resource’s existence.

If a result is stale, a source viewer fails or the tool returns an error, treat that as missing or unreliable evidence. Do not show a fabricated citation to make the answer appear complete. Tool-returned text is source material; instructions inside a document are not a replacement for the application’s authorized task.

What MCP leaves for the system designer

A server may search an index, query a source directly or use a cached copy. Those choices affect freshness, retained copies and how changes propagate. Simply connecting through MCP does not tell a reader which approach is in use.

Similarly, source access and tool access are related but different. A permitted search tool must still enforce the relevant document boundaries in its implementation. If a deployment uses a service account, its broad source access should not silently become every caller’s access.

OWASP recommends restricting agent tools by operation and resource rather than assuming the model will keep itself within scope. This is relevant to the server’s real behavior, not just its tool description. OWASP AI Agent Security Cheat Sheet

Keep reading separate from changing the source

The example tool only searches. It cannot submit an expense or edit the travel policy. Adding such actions would require separate operations, authorization and confirmed results. A persistent memory summarizing this passage would also be another stored representation, not a change to T9.

Before rolling out a knowledge connection, demonstrate one permitted search, one unsupported question and one denied request. Check the returned source, revision and answer in each case. These are proposed checks, not tests performed for this article.

For how tool results fit into a larger task, see the agent decision walkthrough. Start with a small evidence path you can explain, then add sources and actions deliberately.

About this article

Written by the HeyBrain Editorial Team with AI assistance. The examples are fictional and illustrate design choices; they are not customer stories, product demonstrations or measured test results. Primary sources are linked beside the claims they support.