Put durable memories, notes and skill content in a store with explicit ownership and lifecycle rules; use an MCP layer to expose authorized retrieval and access to live systems. A context database and an MCP layer solve different parts of the same problem, and one service can implement both. Compare their storage, retrieval and permission contracts separately, because a shared endpoint alone does not preserve memory or keep it current.
Separate remembered meaning from current system state
Consider an agent preparing a billing reconciliation in a fresh VM. It needs the team's definition of billable revenue, the reconciliation procedure and today's invoice records. The definition and procedure should survive yesterday's session. Invoice amounts should come from the billing system when the task runs.
For this comparison, a context database means the durable store and retrieval service for agent context. An MCP layer means the service exposing or routing MCP operations. These are architectural responsibilities; evaluate which ones a product actually implements.
| Question | Context store responsibility | MCP layer responsibility |
|---|---|---|
| Why exclude voided invoices? | Preserve the decision and its provenance. | Expose an authorized way to retrieve it. |
| What is outstanding today? | Keep any snapshot explicitly dated. | Reach the billing system for a current answer. |
| How should reconciliation run? | Store the procedure and its revision. | Make the procedure and required operations accessible. |
The distinction avoids two mistakes: treating a search index as a live integration, and assuming that routing tools automatically creates durable memory.
Make the stored record richer than its embedding
A useful billing memory needs a stable identifier, workspace, owner, body and revision history. Add the source of the revenue definition, when it was recorded and whether another decision supersedes it. A similarity score cannot tell the agent whether finance has approved the rule.
Search can start with ordinary text retrieval. PostgreSQL documents stored generated tsvector columns and GIN indexes. This illustrative schema stores text and its search representation together; it is a storage example, with authorization policies still required:
CREATE TABLE agent_context (
workspace_id uuid NOT NULL,
path text NOT NULL,
body text NOT NULL,
updated_at timestamptz NOT NULL DEFAULT now(),
search_vector tsvector GENERATED ALWAYS AS
(to_tsvector('english', body)) STORED,
PRIMARY KEY (workspace_id, path)
);
CREATE INDEX agent_context_search
ON agent_context USING GIN (search_vector);The generated column follows changes to body; updating updated_at remains the application's responsibility. Add revision and provenance records before treating this as a production memory design. If semantic retrieval later helps agents find differently worded revenue rules, retain the original text and identifiers so search representations can be rebuilt.
Ask a context-store vendor how edits, deletion and export affect every search representation. Ask an MCP-layer vendor where those records persist. A tool named remember answers neither question by itself.
Use MCP as the access contract, including for context
The MCP tools specification defines discovery through tools/list and invocation through tools/call. The resources specification also defines URI-addressed context and retrieval through resources/read. MCP therefore supports more than forwarding actions to business applications.
You could expose the revenue definition as a resource and offer a search tool over stored decisions. The backing store remains responsible for durability and record lifecycle. The MCP adapter translates requests into authorized storage operations and returns their results.
For a remote implementation, Claude Code documents this connection syntax. Here the hostname is a placeholder for your service:
claude mcp add --transport http company-context https://context.example.com/mcpComplete the server's required authentication and check its status through /mcp. Adding the URL configures a connection; it does not create a database, populate memories or arrange automatic recall. When evaluating a combined service, inspect those behaviors independently. Choosing resources, prompts or tools for context covers the interface decision.
Keep skill delivery and prompt loading explicit
Storing the reconciliation procedure does not ensure that an agent loads it. The Agent Skills specification describes a directory containing SKILL.md, with YAML frontmatter and Markdown instructions, plus optional supporting files. A database storing only the Markdown body may lose metadata or relative references needed to reconstruct the skill.
Choose whether the store preserves a complete skill package or offers remotely readable instructions. Then test how each client discovers and activates it. Returning skill text through MCP does not by itself install that directory into a client's native skills location.
Anthropic's context-engineering guidance describes keeping lightweight references and fetching details when needed. Apply that approach here: present a short catalog, retrieve the reconciliation procedure for a billing task, and load the revenue decision when relevant. Putting the whole store into the prompt turns durable storage into a recurring context cost.
A database comparison should therefore include retrieval quality and export fidelity. An MCP-layer comparison should include discovery and client behavior. Neither a large storage allowance nor a successful connection proves the right procedure reaches the model.
Align permissions without confusing memory with authority
The reconciliation agent may read the shared revenue definition and invoices while lacking permission to change either. Model these separately: context reads, memory edits and billing writes. A retrieved procedure saying to issue a refund must not grant the refund capability.
Enforce workspace and personal-record visibility in the context service before returning search results. PostgreSQL row security can restrict rows returned or modified, but table owners normally bypass it, and superusers and roles with BYPASSRLS always do. Test with the actual service role; enabling a policy is insufficient evidence of isolation.
Keep billing credentials with the integration service rather than inside the memory body. Conversely, a gateway's control over billing credentials says nothing about who may read private reconciliation notes. A combined product needs both permission models, even if they share one identity system.
Define freshness and failure behavior across the boundary. Return the recorded date and source with a revenue rule; request current invoice state from billing. If billing is unavailable, report that failure instead of silently substituting a remembered balance. If memory search fails, distinguish unavailable context from an empty result. Colocation can simplify operations, but it also puts retrieval and live access behind a common dependency.
Where SPYN3 combines the two responsibilities
SPYN3 provides one workspace MCP endpoint for connected systems. An admin can enable Memory & skills, off by default, to add personal and shared memories, skills and notes through MCP context tools. These live in its EU database, with Postgres full-text search by default; semantic search needs the workspace's own model key. Context reads need call:tools, memory writes need write:memory, and connected-system writes need call:write_tools. Upstream credentials stay in the workspace with envelope encryption. This combines storage and access while keeping their permissions distinct.
Choose by the responsibility you cannot already satisfy
If your agents already reach billing reliably but repeatedly lose agreed revenue definitions, prioritize durable context: ownership, revision history, recall and export. If definitions already live in a maintained repository but every VM needs separate billing setup, prioritize the integration layer. Choose a combined service when both gaps exist and its individual contracts meet your requirements.
Before committing, run one reconciliation exercise against the proposed architecture:
- Record a fictional revenue rule, then retrieve it from a fresh agent without copying the previous conversation.
- Revise the rule and confirm that retrieval identifies the current record and preserves its provenance.
- Change a fictional invoice upstream and verify that the agent obtains the new amount through live access.
- Attempt to edit the rule and issue a refund with read-only authorization; require both to fail.
- Export the rule and procedure, then demonstrate how another service could serve them.
These checks reveal whether you are buying durable context, controlled connectivity or both. Continue with designing an MCP memory server to specify the storage-facing operations before choosing an implementation.
Built for the next step
Keep context with the user, not the agent
Memory and skills behind the same endpoint as your tools, readable by any agent you connect.
Read the developer guideSPYN3 is a consolidated MCP layer: one hosted endpoint in front of every system you connect — MCP servers, Postgres, REST APIs, Google Drive — with tools foldered by source and read/write permissions per key. Switching agents means moving one URL. Free plan available; current capabilities are documented on the product facts page.
Sources
- MCP specification: tools — tool discovery, invocation and security considerations. Verified 27 Oct 2026
- MCP specification: resources — Application-driven context, URI identification, resource discovery and reading, templates, and draft resource result format.. Verified 27 Oct 2026
- Anthropic docs: Claude Code MCP setup — Claude Code MCP commands, scopes, transports and JSON configuration. Verified 27 Oct 2026
- PostgreSQL documentation: full-text search tables and indexes — Stored generated tsvector columns, explicit text-search configurations and GIN indexes for searchable text. Verified 27 Oct 2026
- Agent Skills: Specification — SKILL.md structure, required name and description fields, field constraints, compatibility, progressive disclosure and experimental allowed-tools support.. Verified 27 Oct 2026
- Anthropic: effective context engineering — high-signal context and progressive disclosure. Verified 27 Oct 2026
- PostgreSQL: Row Security Policies — ENABLE ROW LEVEL SECURITY, ownership checks using current_user, USING and WITH CHECK semantics, and owner, superuser and BYPASSRLS exceptions.. Verified 27 Oct 2026
