Insights8 April 2026Updated 26 October 20264 min read

MCP Tools for Team AI Memory: Discovery Without Blanket Access

Agent Grounding Dendro Logic diagram showing a central hub connected to multiple nodes via glowing lines.

MCP gives team memory a defined discovery and invocation interface: clients request the tool catalogue with tools/list and invoke a named tool with tools/call. For an engineering team, we recommend treating that interface as an additional way into the existing knowledge service, rather than a reason to replace its API. Keep the search rules and permission checks in the service, then expose the operations an agent needs through a small MCP interface.

This is a narrower proposal than promising that every agent can use every memory server without setup. The MCP architecture assigns connection permissions and consent enforcement to the host, while clients and servers declare supported capabilities during initialisation. Before adopting the interface, test the actual combination of host, transport and authentication your team intends to support.

Discovery is a contract, not a deployment plan

An agent node views a catalogue of floating tool shapes, only some lit and within reach

An MCP tool definition includes a name, description and input schema, with an optional output schema for structured results, as the tools specification sets out. Use those fields to explain what each memory operation returns and when an agent should choose it. A search description should distinguish finding original records from generating an answer about those records. Make project scope explicit in the contract instead of leaving the model to infer which team's information it may retrieve.

For a first implementation, we would expose search and source expansion before adding answer generation or writes. Keep the same permission checks behind both operations so that possession of a source reference does not become an alternative route around access controls. Test that rule by searching as one permitted user, then attempting to expand the reference as a user without access.

The protocol's standard transports include stdio, where the client launches a server subprocess, and Streamable HTTP, where the server runs independently. Choose between them as a deployment decision, then document the supported connection method for each host. Do not count a successful catalogue response as proof that authentication, result handling and denied operations work across the whole integration.

Design memory tools around evidence

Consider the following names as an illustrative interface, not a prescribed MCP tool set or a description of a deployed system. A memory_search operation could return short results with a source identifier, project scope and record date. An expand_source operation could accept that identifier and return the original passage with enough surrounding text to interpret it. Require both operations to distinguish a missing record from one the caller is not allowed to read, without disclosing restricted content.

If you add answer_from_memory, require its response to identify the passages supporting the answer and to state when the available records do not resolve the question. Keep an answer's generated wording separate from the original passages so reviewers can inspect the evidence rather than another summary. These are design recommendations for the memory service, not accuracy guarantees supplied by MCP. The protocol allows structured tool results and optional output schemas, which provide a place to specify those response fields.

Build acceptance tests around a superseded decision, a missing source and an unauthorised project. For the superseded decision, require the response to preserve the earlier record while pointing to its replacement. For the missing source, require an explicit failure instead of an answer assembled without the promised evidence. Agree those expected behaviours before comparing retrieval speed or answer quality.

Keep writes separate from reads

Two channels into a memory core, a wide open one for reading and a narrow gated one for writing

A decision-recording operation should have a different permission policy from search, even if both appear in the same server catalogue. Start with a proposed record containing the decision, its reasoning and links to the evidence, then require the designated owner to approve it. Only make automatic recording available where the team has explicitly authorised that behaviour and defined how to correct mistakes. The tools specification recommends human oversight with the ability to deny tool invocations and user confirmation for sensitive operations.

For writes, we recommend a request identifier and a recorded outcome that a caller can inspect after a timeout. Test retrying the same request and require the service to avoid creating a second decision record. Treat that as an application requirement, not something to assume from protocol compatibility. MCP distinguishes protocol errors from tool execution errors, with the latter reported through isError: true. Make the host's handling of each error type part of the integration test.

A private network does not define authorisation

For HTTP-based connections, MCP specifies an authorisation flow using OAuth roles and access tokens. That specification requires protected MCP servers to validate that tokens were issued for them as the intended audience. It treats stdio differently, recommending credentials from the environment rather than the HTTP authorisation flow. Choose credentials and deployment together instead of prescribing a single shared API key for every installation.

The Streamable HTTP security guidance requires origin validation and recommends localhost binding for locally running servers. The tools specification also requires server-side input validation, access controls, rate limiting and output sanitisation. Our recommendation is to test these controls with an authenticated caller who lacks permission, not only with a connection that has no credentials. Keep search-only access available for agents whose work does not require recording decisions.

For a pilot, connect the intended host to search and expansion, verify denied access, then introduce a reviewed write operation. Keep the existing API available for consumers that need it, with the same underlying ownership and permission rules. Approve wider use only after the team can inspect both the source behind a memory answer and the outcome of a proposed write.

Update, October 2026

Our engineering article on grounding packs develops the distinction between supplying an agent with initial context and letting it retrieve further evidence while working. Use it as a companion design discussion when deciding what context to supply before the first memory tool call.

Sources

Want this in your team?

Tell us what you're building and where you want to get to, and we'll think it through with you.

Let's have a chat Follow by RSS →

All insights →