For the first agent that needs a handful of product documents, the easiest move is usually to upload the files into the application’s own knowledge base. The project gets moving, the answers are tangible, and there is no reason to build a service before there is a service-shaped problem.
The second agent changes the question. It needs the same product document. It also needs the current pricing rules. You can upload another copy, but the awkward questions arrive quickly: which copy is current? Who fixes a table that parsed badly from a PDF? When search returns a paragraph, which document revision did it come from?
What needs to be shared is not a pile of attachments. It is the process that turns a document into retrievable knowledge. An MCP knowledge base gives agents a common way to call that process instead of each one keeping its own sliced-up copy of the source material.
MCP exposes a capability, not a giant folder
It is easy to think of MCP as a pipe for letting a model read files. That is not wrong, but it leaves out the useful part.
A knowledge-base service needs to answer practical questions: what can be searched, where a result came from, whether an import finished, and whether a document was updated later. The agent should receive query tools and evidence, not a permanent block of documents occupying its context on every turn.
Langhuan serves knowledge_search, document ingestion, status lookup, and deletion over MCP over HTTP. The client may be Claude, Cursor, or an agent you built yourself. It does not need to know whether retrieval runs on PostgreSQL or SQLite, or how chunks are made. Given a workspace and a query, it needs a result with source anchors.
That is a different architecture from stuffing a project context with every file. In one, the agent fetches the few passages it needs when the question arrives. In the other, the model carries the whole library through every conversation. A large context window is still a poor filing cabinet. That distinction becomes painful when a project knowledge base reaches context limits.
Why the second agent is usually the boundary
Inside one application, handling documents locally can be a perfectly good boundary. The business workflow, permissions, and retrieval code sit in the same repository. Moving fast matters more than extracting infrastructure.
Once two applications share material, the edges blur. An employee assistant and a sales assistant both read product documents, while the first also reads internal policies. A delivery assistant adds client-isolated project files. Separate indexes are possible, but every application now makes its own decision about chunking, indexing, retry behavior, and access control.
The harder version of this problem is three indexes for the same policy. A document is updated, somebody says an answer is wrong, and the team spends half a day establishing which system they asked and which revision that system had before they can even talk about the model. It looks like an answer-quality problem. Usually the knowledge state has already forked.
Pulling out the retrieval layer does not make the upper-layer agents less distinct. It leaves them to do the things that actually differ: one handles an approval flow, another drafts a delivery plan. Both can work from the same evidence. I wrote more about that boundary in why enterprise agents should not keep rebuilding knowledge bases.
A result has to carry its source with it
“The search found something” is not enough to answer from it. Company material has old revisions, exceptions, and files with the same name. A passage without a source enters a model context looking authoritative, while nobody can check it.
A retrieval service should give the application enough context to handle that: matched content, document and revision, and a page, row, column, or offset anchor. Langhuan keeps those anchors in the retrieval path and assigns a stable query identifier so an administrator can replay why a search returned particular evidence. It does not compose the final sentence for an agent, and it does not turn an empty retrieval into a confident answer.
That division of work looks ordinary until an incident happens. If retrieval is wrong, inspect the evidence. If the evidence is sound but the answer is wrong, inspect the prompt or the agent flow. Those are different failures and they should not be debugged as one mystery.
Where to start with an MCP knowledge base
If you are trying one internal assistant, in-app retrieval can still be the right answer. Consider extracting it when one of these is true:
- more than one agent needs the same class of documents;
- someone already maintains versions and access permissions;
- the team needs to explain where an answer came from;
- connecting a new client should not mean writing ingestion and indexing again.
Starting the service and connecting one MCP client is often lighter than planting a future-sharing abstraction in every agent. Read what MCP is for the protocol itself, then how hybrid search works if your queries mix Chinese names and semantic questions. Langhuan’s actual data flow and revision boundary are documented in the public architecture guide.
MCP is not a reason to package every possible function as a tool. It fits a capability with stable inputs and outputs. For a knowledge base, retrieval, ingestion, and status are exactly that.