The short answer
MCP can expose access to a knowledge system; persistence, retrieval quality and permissions still depend on the implementation.
Understand what an MCP tool interface can expose, what a memory system still needs to do, and how to review a proposed retrieval contract.Separate the interface from the system behind it
A tool called "search memory" does not tell you where records live, how recently they changed or whether they survive between sessions. Behind the interface could be a durable store, a temporary process or a service with its own retention model.
The MCP tools specification defines how servers expose callable tools and describe inputs and results. It does not establish the quality or durability of a particular memory implementation. This article uses that dated specification as its reference, without assuming every client implements every feature.
Ask what sits behind the tool
| Layer | Question for the implementation |
|---|---|
| Storage | What persists after the server and agent restart? |
| Retrieval | Which sources can be searched, and how are they updated? |
| Identity and scope | Who is calling, and what may they access? |
| Result | Does each passage identify its source and version? |
| Writes | What validates, authorizes and records a change? |
Once the connection works, check what happens in a later session. Update a fact and query it again. Also check that the caller cannot retrieve evidence it has no permission to read.
Review a small read-only contract
The following is an illustrative application contract, not a Gigabrain API or a complete MCP wire message. It describes useful information to require from a proposed integration.
Request:
query: "What is the approved prototype date?"
project_id: "synthetic-project-17"
limit: 5
Result:
passages: [text, source_id, location, source_revision]
searched_scope: "synthetic-project-17"
index_revision: "record the actual revision"
warnings: [stale source, incomplete import, or none]
no_supported_evidence: true or falseThe server must enforce the caller's allowed scope. Accepting a project identifier from the request does not by itself authorize access to that project.
Keep structured results and evidence distinct
The referenced specification supports structured tool results and optional output schemas. A schema can help a client validate the shape of a response. A well-formed result can still contain an outdated passage or an unsupported claim.
Retain source locations and inspect returned text. Do not treat a tool annotation describing read-only behavior as proof of enforcement. The specification explicitly treats annotations as untrusted unless they come from a trusted server.
Test restarts, corrections and access boundaries
Create a synthetic record, retrieve it, restart the relevant processes and retrieve it again. Correct the source through the supported path and inspect whether the returned evidence changes. Test a missing answer and an unauthorized scope.
Record client, server and adapter versions separately. A result from one client or local setup should not be generalized to every agent that can speak the protocol. Check timeout and error behavior before adding writes or unattended tasks.
Check Gigabrain's actual integration status
This tutorial explains MCP concepts. The illustrative contract above is not the product API. Gigabrain now supplies the local MCP server described below. The compatibility page identifies tested integrations and required manual steps. The evidence page describes what was checked.
Use the tool-contract worksheet when evaluating an integration. If Gigabrain's supported file-based workflow suits your agent, compare packages for the tools and workflows you will use.
Follow the shipped MCP read path
Gigabrain 1.1.0 includes an optional MCP server that runs through local standard input and output. The connection binds to the vault or one approved project.
Agent client → local Gigabrain MCP server
search → scoped memory service → source passages and graph paths
verify_citation → current source text → verification resultThe server returns evidence. It does not generate the agent's answer. A hosted agent may send that returned context to its model provider.
The default tool set includes search, source inspection, citation checks, graph inspection, deletion plans and memory proposals. It does not expose the apply tool.
An owner-controlled approval directory can enable application of reviewed changes. Each approval binds the exact proposal digest. Separate agent file access still depends on host permissions and trust.
Inspect a real protocol check
The archive-bound operations report records actual MCP SDK calls. The read test checks tool discovery, retrieval, invalid input and a path outside the allowed source directory.
A separate test checks that a missing approval blocks application and that repeating an approved change does not duplicate it. These component checks do not certify every agent conversation.
Use the reproduction instructions and integration worksheet before enabling writes.
Method note: Gigabrain Labs prepared this material with AI assistance. Fictional exercises and executed component checks have separate labels.
