How do granular MCP permissions work for memory access?

Granular MCP permissions decide whether an agent key may use Weaviate’s Model Context Protocol tools at all, and which data those tools may touch afterward. Enabling /v1/mcp is not the same as granting every connected IDE a free pass. Weaviate splits MCP capability into read_mcp, create_mcp, and update_mcp, then still requires ordinary collection and data rights for each tool. This chapter explains that two-layer model, how it protects memory-related collections in agent workflows, how Weaviate Engram remains the safer default for user-scoped memory access, and how to test that a read-only retrieval agent cannot escalate into writes or foreign tenants.

Why Do MCP Tools Need Their Own Permission Family?

MCP exposes high-leverage operations through a standard tool surface. Hybrid search, schema inspection, tenant listing, and optional upserts become one prompt away. If authorization only checked generic REST habits, a key meant for catalog search could still discover write tools once MCP_SERVER_WRITE_ACCESS_ENABLED is on. Dedicated MCP actions close that gap. Without read_mcp, the read tools fail even if the key can read data through other APIs. Without create_mcp and update_mcp, upserts fail even when write access is enabled on the server.

That design matches least privilege for agents. A retrieval agent should see hybrid search and maybe schema read. It should not inherit mutation rights because someone reused an admin key in Cursor. Permissions live on the server. Prompt instructions are not a control plane.

Knowing MCP actions exist raises the next question. What else must the role include for a tool call to succeed?

How Do MCP Actions Combine With Collection and Data Rights?

Each tool needs both an MCP action and a matching resource permission. weaviate-collections-get-config needs read_mcp plus read_collections. weaviate-tenants-list and weaviate-query-hybrid need read_mcp plus read_data on the relevant collections, with tenant filters when you scope data permissions that tightly. weaviate-objects-upsert needs create_mcp and update_mcp plus create_data and update_data.

Missing either layer denies the call. A key with broad data read but no read_mcp cannot use the MCP hybrid tool. A key with read_mcp but no read_data on OpticsCatalog cannot search that collection through MCP either. Keep write MCP flags and write data permissions off for memory-adjacent agents unless mutation is an explicit product requirement. Prefer separate roles for human operators, read-only agents, and rare write agents instead of one shared root key.

Server flags still matter. MCP_SERVER_ENABLED must be true for the endpoint to exist. MCP_SERVER_WRITE_ACCESS_ENABLED must be true before upsert tools appear. RBAC then decides which identities may use those tools. Defense in depth means both switches and roles agree.

Agent memory products often should not put end-user facts behind raw MCP data permissions at all. Engram gives a narrower contract.

Why Is Engram Usually the Better Gate for Personal Memory?

Engram authenticates with a project-scoped API key. Every request stays inside that project. User-scoped topics require a user_id, and Engram enforces hard isolation between users with Weaviate multi-tenancy underneath. Groups separate use cases. Your application derives user_id from a verified session. The model does not get to pick another person’s memory shard by inventing a tool argument.

Use Weaviate MCP when agents must query operational collections you manage directly, under RBAC roles that name those collections and tenants. Use Engram when the artifact is durable personal or workspace memory with extraction and reconciliation. Mixing the two without a clear split invites an MCP key that can hybrid-search a memory collection across tenants you never meant to expose.

An optics bench scenario shows how application code keeps Engram access honest even when MCP exists elsewhere in the stack.

What Does Session-Bound Memory Access Look Like in Engram?

A lens grinding shop stores setup notes per bench. Floor software authenticates the operator, maps the session to a bench id, then calls Engram. Cross-bench search must stay empty.

import os
from engram import EngramClient, HybridRetrieval

client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])

# From the signed shop session — never from model-chosen tool args
bench = "lens-grinder-4"
group = "optics_bench"

run = client.memories.add(
    "Bench 4 finished a 50mm achromat with a 0.4 lambda peak on the Foucault test. "
    "Pitch lap stayed cooler than usual after the lunch break. "
    "Do not reuse Bench 7's cerium mix on this crown element.",
    user_id=bench,
    group=group,
)
client.runs.wait(run.run_id)

own = client.memories.search(
    query="Foucault test result and cerium mix for the achromat",
    user_id=bench,
    group=group,
    retrieval_config=HybridRetrieval(limit=5),
)

other = client.memories.search(
    query="Foucault test result and cerium mix for the achromat",
    user_id="lens-grinder-7",
    group=group,
    retrieval_config=HybridRetrieval(limit=5),
)

assert any("0.4 lambda" in m.content for m in own)
assert not any("0.4 lambda" in m.content for m in other)

The Engram project key proves the caller may use this memory project. The session-bound user_id proves which bench is in scope. On the Weaviate MCP side, give a separate catalog agent read_mcp and read_data only on optics SKU collections, with tenant patterns that match that agent’s customers. Do not reuse the Engram key as a cluster root, and do not reuse the MCP catalog key as a memory backdoor.

Permissions still need proof. Quiet denials are how leaks hide.

How Should You Prove MCP and Memory Permissions in Practice?

Create a read-only agent role with read_mcp, read_collections where schema peek is required, and read_data on one collection pattern. Attempt hybrid search on an out-of-scope collection and expect denial. Attempt upsert with that same key and expect denial even if write access is enabled globally. Rotate keys after incidents. Keep audit logs of allow and deny decisions for MCP the same way you keep them for REST.

For Engram, automate cross-user probes in CI. Store a canary under lens-grinder-4, search as lens-grinder-7, assert empty. Log the authenticated principal beside every memory call. Granular MCP permissions protect the database tool door. Engram scopes protect the memory door. Production agent stacks need both doors locked to different keys.

Our next chapter, What is Weaviate Engram as a managed memory service?, steps back from MCP authorization and introduces Engram itself as the managed memory service those safer access patterns are meant to protect.