Eight Doors Instead of One

VaultCrux started with a single MCP endpoint. One door. You connected, you authenticated, and the system handed you every tool it had. Fifty-something tools across retrieval, memory, economy, proof generation, watch monitoring, feedback, org management, and intel analysis.

It worked. Technically. The agent could call any tool. The auth layer checked permissions. The rate limiter throttled abuse. Everything was correct.

But everything was also expensive, slow, and imprecise.

Let me give you the numbers, because abstractions hide the waste.

The full VaultCrux tool manifest, all fifty-plus tools with their JSON-RPC schemas, compiles to approximately 9,800 tokens. That's the context window cost of connecting to VaultCrux. Before you've asked a question. Before the agent has done anything. Nearly ten thousand tokens, sitting in the window, describing tools the agent will never call.

A typical agent session calls five to eight tools. A retrieval-focused session calls query_vault, maybe get_journal, and a handful of proof or watch tools. An admin session calls invite_seat, list_seats, change_seat_role. A feedback session calls submit_feature_request and get_feature_requests.

These session types barely overlap. The agent doing retrieval has no use for org management tools. The agent managing seats has no use for proof generation. But every session paid the same ten thousand token entry fee because every session connected to the same door.

That's one problem. Here's the other.

When a language model looks at fifty tools, it doesn't search them the way you'd search a menu. It reads all of them, builds an internal representation of what each one does, and then tries to match your request against that representation. More tools means more ambiguity. More ambiguity means more wrong choices.

VaultCrux has query_vault and query_memory. It has get_watches and get_watch_alerts. It has proof_document and get_proof_receipt and get_proof_chunks and get_proofpack. Some of these are called together. Most aren't. But the model has to hold all of them in working memory and discriminate between them on every tool call.

I watched an agent call get_proof_receipt when it needed get_proofpack. The names are close. The descriptions overlap. The agent's task was to retrieve a complete proof bundle, and get_proof_receipt sounded right. It got metadata instead of content. It then called get_proof_chunks to get the actual content. Two calls instead of one. The right tool was in the manifest the whole time. It just got lost in the crowd.

The endpoint split

The solution is what we call the Phase 1 Logical Split. Instead of one MCP endpoint with fifty tools, VaultCrux now exposes eight scoped endpoints, each serving a focused subset of tools with a specific capability profile.

Vault (/mcp/vault) - seventeen tools. This is the primary surface for agents doing knowledge work: retrieval, journal queries, stale pin detection. It's the endpoint that most sessions connect to, and it's read-only. An agent on this endpoint can search, retrieve, and inspect, but it cannot modify anything.

Economy (/mcp/economy) - eight tools. Credit balance, escrow, spend receipts, pricing, bundles. A separate surface because economic actions have different risk profiles than retrieval. An agent that can query documents shouldn't automatically be able to purchase credit bundles.

Audit (/mcp/audit) - thirteen tools. The investigative toolkit. Proof status, chunks, receipts, proofpacks, plus the intel suite for compliance and trust evaluation. Heavier tools with higher latency, separated so lightweight retrieval sessions don't carry their weight.

Watch (/mcp/watch) - four tools. Monitoring: set watches, remove watches, list watches, get alerts. Mutating (you're creating monitoring commitments) but scoped to a specific, well-understood surface.

Coord (/mcp/coord) - six tools. Coordination actions that span surfaces: operations that touch both economy and private state. The smallest endpoint with the most complex permission model.

Admin (/mcp/admin) - four tools. Seat management. Invite, list, change role, revoke. These are the tools with the highest blast radius per call (revoking a seat is hard to undo) and the lowest call frequency (you manage seats once, you query documents a thousand times).

Feedback (/mcp/feedback) - four tools. Feature requests, votes, revenue signals. Low-stakes, high-value for product development, but completely irrelevant to an agent doing retrieval or audit work.

Memory (/mcp/memory) - seven tools. The MemoryCrux query subset: knowledge queries, topics, snapshots, audit trails, claim checks, freshness, contradictions. Read-only access to organisational memory without the decision plane or constraint management tools.

Plus a ninth: Discover (/mcp/discover) - one tool, no auth required. Returns the endpoint manifest so an agent can see what's available before connecting to anything.

What changes

The token arithmetic is immediate.

An agent connecting to the Vault endpoint loads seventeen tool definitions instead of fifty. That's roughly 3,200 tokens instead of 9,800. A savings of 6,600 tokens. For a context window under pressure, that's the equivalent of getting an extra three to four pages of code or documentation into the working set.

An agent connecting to Admin loads four tool definitions. About 700 tokens. The savings against the full manifest is 9,100 tokens. That's almost the entire tool manifest, reclaimed for actual work.

The accuracy improvement follows from the reduction in ambiguity. An agent on the Vault endpoint doesn't see invite_seat or purchase_bundle or submit_feature_request. It can't accidentally call them. It can't waste time evaluating whether they're relevant. The tool selection space is smaller, the descriptions are more clearly differentiated within each scope, and the model makes better choices.

The time improvement is subtler but real. Smaller manifests mean faster tool selection. Faster tool selection means fewer wasted round trips. And because each endpoint has a clear capability class, the MCP server can optimise internally: Vault endpoints skip Shield policy checks for mutation (there are no mutations to check), Admin endpoints skip retrieval pipeline setup (there's no retrieval to do).

The security surface

There's a design principle underneath the optimisation: access should match intent.

An agent that connects to do retrieval work should not, as a side effect of that connection, have the ability to invite new seats to the tenant, purchase credit bundles, or generate proofs. Even if the auth layer would ultimately deny those calls. Even if the rate limiter would catch abuse. The principle is that the capability surface should match the declared purpose of the connection.

This is defence in depth applied to the tool layer. The auth layer is the last line. The endpoint scope is the first. An agent connected to /mcp/vault cannot call invite_seat because the tool doesn't exist in that endpoint's manifest. It's not forbidden. It's absent. The distinction matters for the same reason that a firewall rule matters even when the application behind it validates input: layers of protection reduce the blast radius of any single failure.

Each endpoint declares its capability classes: READ_ONLY, READ_PRIVATE, ECONOMY_MUTATE, WRITE_PRIVATE, DELEGATE_ACCESS, FEEDBACK. These classes map to Shield policy tiers. An agent with READ_ONLY clearance connects to Vault and gets the full set. An agent with ECONOMY_MUTATE clearance connects to Economy and can purchase bundles. The capability class system means that the endpoint topology isn't just an optimisation. It's a formal access control surface.

The legacy door stays open

The original single endpoint, /rpc, still exists. It serves the full manifest. Every tool. No scoping.

This isn't an oversight. It's a migration strategy.

Existing clients that connect to /rpc continue to work. No breaking changes. No forced migration. The scoped endpoints are opt-in. Clients that want the benefits of reduced token cost, improved accuracy, and scoped access connect to the specific endpoints they need. Clients that don't care, or that genuinely need cross-surface access in a single connection, stay on /rpc.

Over time, the goal is to deprecate /rpc and require scoped connections. But that's a product decision, not an architecture decision, and it depends on how clients actually use the system. If it turns out that most sessions genuinely need tools from three or four endpoints, forcing scoped connections just adds connection management overhead. The data will tell us.

What I'm watching

The question I can't answer yet is whether the endpoint boundaries are right.

The current split follows domain lines: retrieval, economy, audit, watch, coordination, admin, feedback, memory. These feel correct. They map to the way VaultCrux is architected internally. But internal architecture and agent usage patterns aren't always aligned.

If agents consistently connect to Vault and then immediately connect to Memory (because retrieval and memory queries go together), those should probably be a single endpoint. If agents on the Audit endpoint never call more than four of the thirteen tools, maybe Audit should be split further.

The discover endpoint exists partly to answer this question. By watching which endpoints agents connect to, in what combinations, and which tools they actually call on each, we can empirically validate the boundaries. The Phase 1 split is a hypothesis. The data will tell us whether it's the right one.

What I'm confident about is the direction. Fifty tools behind one door is the wrong architecture for a system that serves specialised agents doing focused work. The details of which tools go behind which door will evolve. The principle that tools should be scoped to purpose, that access should match intent, and that every token in the context window should earn its place, that part isn't going to change.