Skip to content

KCP vs MCP

Short answer: it's not a versus. The Model Context Protocol and the Knowledge Context Protocol solve different halves of the same problem, and the best agent stacks run both. MCP is how an agent calls tools. KCP is how an agent finds and trusts knowledge. One provides retrieval, the other provides structure — and structure is what tells the agent which retrieval is even worth doing.

The confusion is understandable — both are "context protocols" with three-letter names in the agent space. But they operate at different layers, and treating them as rivals is a category error that leaves a real gap in your architecture.

Side by side

MCP (Model Context Protocol) KCP (Knowledge Context Protocol)
Question it answers "What tools can I call, and how?" "What knowledge exists, and can I trust it?"
Nature An RPC/tool-invocation protocol — executable A YAML manifest format — passive data
Verb Do — call a function, fetch a result Know — navigate, select, trust before loading
Unit A tool with a schema A knowledge unit with intent, topology, freshness, trust
When it runs At invocation time (the agent acts) Before invocation (the agent orients)
Failure it leaves open The agent can call tools but doesn't know which knowledge is authoritative or current The agent knows what's true but has no way to act on it
Injection surface Larger — executable config can carry instructions Smaller — passive data an agent reads can't inject the way config it executes can

They compose — that's the whole point

The two are designed to stack. KCP tells the agent what knowledge exists, how fresh it is, and whether it's signed; MCP is one of the ways the agent then retrieves it. In practice you expose a KCP manifest and an MCP bridge, and the agent uses the manifest to plan and the bridge to fetch. The reference implementation ships exactly this pairing — kcp-agent runs as an MCP server (kcp_plan, kcp_load, kcp_validate), so KCP navigation is available as MCP tools.

Three failure modes KCP prevents that MCP alone doesn't

MCP gives an agent hands. It does not give it judgement about what to read:

  1. Rediscovery churn. Without a map, an agent re-explores the same context every session — the 33-tool-call bug that started KCP. A manifest turns 119 tool calls into 31.
  2. Stale confidence. MCP will happily fetch a document that stopped being true in February. KCP carries validated dates and temporal validity, so an agent can tell fresh from stale.
  3. Unverifiable sources. A tool result has no provenance. A KCP unit is signed and can be attested and verified, which is what makes an answer defensible to an auditor.

The decision rule

  • You need MCP the moment your agent has to call anything — a database, an API, a file system. Nearly every agent does.
  • You need KCP the moment your agent has to choose what to read or trust from a non-trivial body of knowledge — docs, regulations, a large codebase, multi-source context.
  • You need both for any serious agent on the agentic web: MCP to act, KCP to know what acting on is authoritative and current. They are complementary organs, not competing skeletons.

Where to go next

MCP is a widely-adopted open standard from Anthropic; KCP is an open standard developed under Cantara and submitted to the Linux Foundation's Agentic AI Foundation. This page is one practitioner's framing of how they fit — corrections welcome.