concepts · MCP
MCP should make pods reachable, not centralize memory
MCP is interesting for sempods because agents need a simple way to ask for data. It is also dangerous if it becomes a second, more privileged path around the system.
The reference implementation takes the conservative route: the pod MCP endpoint sits at /_system/mcp and exposes tools over the same pod model. The agent is a client. It receives what its token and grants allow.
web app agent via MCP website
| | |
v v v
HTTP/CRUD MCP tools SPARQL
\ | /
\ | /
v v v
same pod authorizationThe useful tools are boring on purpose
The useful MCP surface is not magic. It exposes primitives an agent can combine: list contexts, find a foothold, fetch a resource, read property values, or run sandboxed SPARQL.
That is enough to support graph retrieval. The agent does not need a custom "answer my whole product question" endpoint. It needs safe access to the graph and enough structure to inspect what it found.
Multi-pod MCP
Multi-pod MCP is where the model becomes more than an assistant integration. A single client can connect to several pods, call find across them, and merge the results into a working graph.
Each pod still decides its own visibility. One pod can fail, require reconnect, or return only public data without poisoning the whole result. That is a better shape for federation than copying all memories into one assistant-owned store.
Agent memory without agent ownership
A hosted MCP service can make several pod connections convenient, but the architectural goal is still the same: the source of truth remains in pods, not in the agent host.
The revolution is quieter when it is phrased as a rule: agents come to the data.
What is still early
The rough edges are in tool ergonomics, hosted connection UX, richer retrieval adapters and future write constraints. The baseline is already useful because it keeps the MCP surface close to the same HTTP, SPARQL and permission model the pod already uses.