Why Your Team’s AI Memory Should Ship as MCP Tools, Not Just an API

If your team has built a knowledge layer that an LLM agent might query, the question is not whether to expose it. The question is how. The traditional answer is a REST API: pick a route shape, document the auth, write the OpenAPI spec, hope the next agent framework implements an integration. The MCP-first answer is different. Ship the same capabilities as Model Context Protocol tools, and every Claude Code session, every Cursor instance, every compatible agent runtime can call your memory layer the moment it lands. No custom code on the agent side. No new SDK to learn.

The shift is small in protocol terms, large in adoption terms. Here is why it is worth doing from day one.

What MCP solves that REST does not

REST APIs are an integration handshake. The agent (or the human writing the agent's tooling) has to know the route exists, know its shape, write the request, parse the response. Every new agent runtime needs that handshake repeated.

MCP servers are self-describing. The agent runtime queries the server, the server lists its tools with their input schemas, the agent dispatches to whichever tool fits the current task. Discovery is automatic. The integration cost across N agent runtimes goes from N times the integration work to one MCP server, full stop.

For a team building a knowledge layer that they want any agent (theirs, the contractors', the open-source experimental one a developer is trialling next month) to be able to use, this is the difference between "we have an API documented somewhere" and "anyone with a compatible runtime can call us right now".

The five tools that cover most team-context use cases

Across the products we run for ourselves and for clients, five MCP tools cover the bulk of agent interactions with the brain. These are deliberately narrow and composable: each tool does one thing, the agent composes them.

• memory_search(query, k=10): deterministic FTS plus vector search across the vault, returns ranked chunks with stable hash references. Sub-second, no LLM cost. Used as the cheap first-pass retrieval.
• memory_ask(query): synthesised answer with inline citations on every claim. Slower, more expensive, used when the agent actually needs an answer rather than raw chunks.
• memory_expand_ref(ref_hash, siblings=N, file=true): progressive drill-down into a chunk surfaced by memory_search. Optionally returns siblings or the full file centred on the chunk's location.
• memory_session_list(): returns recent agent sessions and their topical chunks. Lets a fresh session pick up where yesterday's left off.
• record_adr(title, context, decision, alternatives, consequences): captures an Architecture Decision Record inline as the decision is being made. The brain assigns the next sequential number and indexes it for future retrieval.

The first four are read paths. The last is a write path, and it is the one that compounds the brain's value over time.

Why MCP-first changes the agent loop

Agents have always been able to retrieve from a knowledge base. What MCP-first changes is the capture loop. When record_adr is a callable tool and not a separate workflow the developer has to remember to do, decisions get captured as they are made. The brain learns continuously. The next agent session sees today's decisions in retrieval, not next week's wiki update.

The same shape applies to gotchas, to session logs, to research notes. Every callable write tool turns the agent's normal working motion into ingestion. The team-context brain stops being a system the developer has to feed and starts being the substrate the work runs on.

Discovery and security boundaries

A practical concern with MCP-first: discoverability is good, exposure is bad. The fix is the same as any other internal service.

Run the MCP server on a private network boundary. Tailscale, internal VPC, whatever your organisation uses. Bind it to localhost or a private interface. Require an API key at the transport layer for any tool call. Never expose it to the public internet.

Inside that boundary, every team agent gets full access. Outside it, the server is invisible. Same posture as any internal API, with the added benefit that MCP makes the integration cost so low that there is no reason for anyone to expose it more widely than necessary.

When MCP-first is the wrong call

MCP-first is right when:

• The capabilities will be called by multiple AI agent runtimes over time.
• The team owns both the server and at least some of the agents.
• The capability set fits the tool-call abstraction (each tool is a clean function, not a long-running session).

It is the wrong call when:

• The integration is human-driven (a person in a browser, not an agent in a session).
• The capability is a long-running streaming workflow that the tool-call shape does not capture well.
• You are building a public API for third-party consumption and a stable REST contract is a feature.

For internal team-context infrastructure, MCP-first is almost always correct. The gap between "we have an MCP server" and "we have a REST API" is the gap between an agent that can use the brain by default and an agent that needs custom integration work to even see it.

Take the Next Step

If your team has built a knowledge layer and is wondering why your AI agents are not actually using it, the answer is often the integration shape. We help teams expose their existing memory and decision infrastructure as MCP tools so the agents already in the building can start grounding their work in the team's actual context. Get in touch if you want a fresh pair of eyes on yours.