← Back to blog
David6 min read

What is MCP? A protocol for calling external capabilities from agents

What the Model Context Protocol solves, what servers, clients, and tools are, and how a knowledge base becomes an MCP-callable service.

MCPAgentModel Context Protocol

The first time I connected a knowledge base to an agent, I wrote a pile of private interfaces: one HTTP endpoint for retrieval, another for ingesting documents, and the client still had to handle pagination, auth, and error codes on its own. It worked, but every new client meant writing it all again.

Later I learned about MCP, the Model Context Protocol. It unifies how a model or agent calls external capabilities. Once I understood it, I realized what I had been writing wasn’t a knowledge base; it was a one-off glue layer for each client.

What MCP solves

Without MCP, every model application that wants to connect to a tool has to define its own “how to connect, what to send, how to authenticate.” The result is an M×N problem: M tools and N clients need M×N integration efforts.

MCP collapses that M×N into M+N. The tool side implements an MCP server once, the client side implements an MCP client once, and the two talk over one protocol. The protocol is an open specification maintained at modelcontextprotocol.io.

Servers, clients, and tools

MCP has three core concepts:

  • server: the side that exposes capabilities. For example, Langhuan exposes tools like knowledge_search and document_ingest.
  • client: the side that uses capabilities, such as Claude Desktop, Cursor, or an agent you write yourself.
  • tool: a concrete callable action a server exposes, with a name, input schema, and return value.

There are also resources (data you can read) and prompts (preset templates). For connecting a knowledge base, the tool is what you reach for most often.

How a knowledge base becomes an MCP service

For Langhuan, this step is wrapping the existing retrieval and ingestion APIs in MCP tool semantics: retrieval is knowledge_search, ingestion is document_ingest, status is document_status. The client receives a standard tool list instead of a per-project manual.

You don’t have to parse the protocol yourself. The handshake, tool calls, and error responses are defined in the MCP specification, and the tool-side implementation is verifiable in the Langhuan repository.

In one sentence

MCP doesn’t change what a tool can do; it changes how a tool gets called. When your knowledge base exists as an MCP server, any MCP-capable client can use it directly. That is the key step that turns knowledge capability into infrastructure.

If your knowledge base is still a pile of private HTTP endpoints, it’s worth asking first: when the next agent comes along, will you be writing another glue layer?

Related · Further reading

What Happens When Your Project Knowledge Base Hits Context Limits

Stuffing every document into a Claude or ChatGPT project knowledge base eventually hits context limits — answers degrade first, uploads fail later. Symptoms, causes, and moving knowledge out of the context window.

MCP over HTTP vs stdio: which transport should your agent use

Comparing stdio, SSE, and streamable HTTP transports for MCP: when to use each, and the deployment and security trade-offs.

By the third enterprise agent, the knowledge base can't be rebuilt every time

When building several enterprise agents, I found the thing most often rebuilt isn't model capability — it's the ingestion, access control, retrieval, and evidence chain for knowledge.