auto.
The three tiers
Flat
Every permitted tool is defined up front. Best experience with no indirection, for small setups.
Apps
One meta-tool per MCP, named for the MCP (for example
github, supabase). The tool list itself is the readable inventory; each MCP’s tool definitions load on demand inside its meta-tool.Compact
Two global meta-tools (a search and a call) whose descriptions carry the MCP manifest. For very large fleets.
How auto chooses
When the mode isauto, the workspace endpoint picks a tier from the count of permitted tools and MCPs for the caller:
Flat, until the threshold
While the total number of permitted tools is at or below the discovery threshold (default 40), the gateway serves flat.
Apps, past the threshold
Once the tool count passes the threshold, the gateway switches to one meta-tool per MCP, as long as there are 24 or fewer permitted MCPs.
auto, and you can change the threshold (any value from 1 to 500).
Auto only applies to the workspace endpoint (
/mcp and /w/{workspace}/mcp). A per-MCP endpoint (/s/{appKey}/mcp) and a bundle endpoint (/b/{bundleKey}/mcp) are already curated slices, so they always stay flat regardless of this setting.Why the inventory always stays visible
Hiding the inventory would make an AI client capability-blind. It would answer “I don’t have GitHub” on clients that never proactively search. So at every tier the list of MCPs a person can reach stays readable. Inapps mode the tool list is that inventory. In compact mode the meta-tool descriptions carry it. Only the detailed per-tool definitions load on demand, which is what keeps the context cost down.
The repeatable context-efficiency benchmark measures the definition, task-context, wire, result, CLI-process, and latency costs of flat MCP, compact MCP, and Passport CLI against the same deterministic governed task.