concepts · MCP
Let agents come to the knowledge
MCP gives an agent tools for finding and reading pod data. The useful part is where the knowledge stays: in independent pods whose owners decide what the connection may reach.
One pod, one optional surface
A pod implementing the MCP module exposes /_system/mcp. Its tools can list Contexts, call find, fetch a resource, inspect properties and run sandboxed SPARQL. An agent combines those operations into a retrieval loop.
The tools add no authority. Authentication and server-resolved grants determine their reach, just as they do for HTTP resource operations.
Several pods, one agent connection
The Kotlin hosted MCP service maintains connections to multiple pods. An agent can gather results from independent data spaces, with each pod enforcing its own permissions.
The hosted service mediates those requests and handles connection credentials. Choose its operator as part of your trust decision. The source data remains in the pods; the agent can combine the returned facts for its task.
An answer can cross a boundary
An agent could read public events from a venue and private plans from your pod. The venue decides what is public. You decide what the agent may read from your plans. Combining an answer transfers no authority from one pod to the other.
Check the implementation you connect to
MCP is optional in the specification. Kotlin 0.2 supplies both per-pod and hosted surfaces, with setup described in their guides. A running host's configuration and revision need their own verification.
The contract requires conformance discovery. Kotlin 0.2 does not yet serve /_system/conformance; its release notes record the deviation. Use its documented capabilities rather than assuming that discovery is available.
MCP module Per-pod MCP guide Hosted MCP guide Follow the retrieval loop