What is Weaviate’s Model Context Protocol server?

Weaviate’s Model Context Protocol server turns the database into a native tool surface for agents and IDEs. MCP is an open standard for connecting models to external systems without custom glue for every client. Weaviate implements it as a Streamable HTTP endpoint at /v1/mcp on the same port as the REST API. Once enabled, compatible clients can inspect schemas, list tenants, run hybrid search, and optionally upsert objects under the same authentication and RBAC rules as any other API call. This chapter explains what that built-in server provides, how permissions and tool descriptions keep agents safe, how Weaviate Engram fits as the managed memory path beside raw MCP database tools, and what a grounded agent loop looks like when long-term facts live in Engram while operational collections stay reachable through MCP.

Why Does a Database Need an MCP Endpoint at All?

Agents already call tools. Without a shared protocol, every product invents its own wrappers. MCP standardizes discovery and invocation so Cursor, Claude Code, VS Code, and other MCP-aware clients can speak to many servers the same way. Weaviate’s built-in server removes the need for a separate sidecar just to expose search. Enable MCP_SERVER_ENABLED, point the client at /v1/mcp, and authenticate with a Bearer API key. The cluster that already holds your vectors becomes an active participant in the agent loop.

That shift matters for memory architectures. A passive store waits for your application to query it. An MCP-enabled Weaviate instance can be asked, mid-reasoning, what a collection looks like or which hybrid hits match a phrase. Write tools stay off unless you set MCP_SERVER_WRITE_ACCESS_ENABLED. Read-first defaults keep exploration safer while you decide which agents deserve mutation rights.

Knowing the endpoint exists raises a sharper question. Which tools does the agent actually see?

Which Tools Does the Built-In Weaviate MCP Server Expose?

Four tools cover the common agent jobs. weaviate-collections-get-config returns schema and vector settings so the model can reason about property names before it invents filters. weaviate-tenants-list enumerates tenants and activity states on multi-tenant collections. weaviate-query-hybrid runs vector-plus-BM25 search with alpha, limits, optional tenant, filters, and return fields. weaviate-objects-upsert inserts or updates objects when write access is enabled.

Custom tool descriptions help more than clever prompts. Mount a YAML or JSON file at MCP_SERVER_CONFIG_PATH and rewrite what the model reads for each tool and argument. A catalog search description that names your product fields steers the agent better than a generic “run hybrid search” string. Keep descriptions honest. Overpromising a tool that cannot delete tenants will only produce failed calls.

RBAC still applies. MCP adds permissions such as read_mcp, create_mcp, and update_mcp, and each tool also needs the matching collection or data rights. A key that can call hybrid search without read_data still fails. Least privilege means a retrieval agent gets read MCP and read data on the collections it should see, nothing more.

Raw database tools are powerful. Most product agents still need a higher-level memory service that extracts and scopes facts automatically. That is where Engram sits.

How Should Engram Sit Beside Weaviate MCP in an Agent Stack?

Use Weaviate MCP when the agent must inspect or query operational collections you manage directly. Use Engram when the job is durable personal or workspace memory with extraction, reconciliation, and hard user isolation. Engram authenticates with a project API key. You add raw turns or notes, wait on runs when you need confirmation, and search with hybrid retrieval under a verified user_id. You do not ask the model to invent shard names for everyday recall.

A clean split keeps failure modes separate. MCP keys for ops collections can stay read-only. Engram keys stay scoped to the memory project. Session code derives user_id from auth, not from free-form tool arguments. Agents that “decide when to remember” often skip memory entirely. Prefer deterministic hooks that search Engram at turn start and store after the turn, while MCP remains available for explicit catalog or schema questions.

A distillery floor agent shows the Engram half of that pattern with a fresh scenario.

What Does Engram Memory Look Like Next to an MCP-Capable Agent?

A copper still shop assistant recalls batch notes through Engram. Separately, the same runtime may call Weaviate MCP to hybrid-search a spirit catalog collection. The memory path stays in the Engram SDK.

import os
from engram import EngramClient, HybridRetrieval

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

still = "copper-still-3"
group = "distillery_lab"

run = client.memories.add(
    "Still 3 cut hearts on barley batch BR-902 at 78.2C vapor. "
    "Foreshots ran longer than usual after the weekend shutdown. "
    "Do not blend this heart cut with Still 1's rye until sensory clears the solvent note.",
    user_id=still,
    group=group,
)
client.runs.wait(run.run_id)

# Deterministic recall before the agent answers — not left to optional tool luck
hits = client.memories.search(
    query="heart cut temperature and blending hold for barley batch",
    user_id=still,
    group=group,
    retrieval=HybridRetrieval(alpha=0.55),
)

memory_block = "\n".join(f"- {m.content}" for m in hits)
assert "BR-902" in memory_block

Inject memory_block into the system prompt, then let MCP tools handle collection-native questions such as hybrid search over bottled SKUs. The agent sees grounded still notes without needing a custom REST wrapper for Engram, and it sees catalog truth through Weaviate’s MCP hybrid tool when that is the right store.

Security and operations close the design. An open MCP port without tight keys is just a new attack surface.

What Operational Guards Belong Around the MCP Server?

Leave the server disabled until you need it. Enable write access only for identities that must mutate. Prefer short-lived or narrowly scoped API keys for IDE agents. Customize descriptions so models do not roam across collections you never intended to expose. Watch audit trails for denied MCP calls the same way you watch denied REST calls. Treat query text and returned objects as sensitive once they enter the model context.

For memory products, keep Engram as the default long-term store for user-scoped facts. Reach for the Weaviate MCP server when agents must operate on the same Weaviate collections your application already trusts, under the same RBAC story you configured for humans and services.

Our next chapter, How do you expose hybrid search as an agent tool via MCP?, zooms in on the hybrid search tool itself. It shows how to shape descriptions, alpha, and tenant arguments so agents call Weaviate search deliberately instead of guessing.