PATTERN Cited by 1 source
Multi-surface MCP composition¶
Pattern¶
Compose an agent's tool catalog from multiple MCP surfaces with distinct latency, scaling, and ownership characteristics — then present them to the agent as a single unified catalog. The processor/composition layer resolves which surfaces apply (based on team, context, session) before the agent loop starts.
Surfaces (Instacart Blueberry example)¶
| Surface | Properties | Examples |
|---|---|---|
| In-process MCP | Low latency, shared session state, co-deployed | Fast local helpers |
| Shared MCP server | Independent scaling, heavier compute, cross-team | Deploy analysis, error analysis, anomaly sweeps |
| Team-hosted remote MCP | Team-owned, externally mounted, team-unique data | Team-specific dashboards, domain data sources |
Why not one surface?¶
- Latency: in-process helpers need sub-second response; heavy investigators can take seconds
- Blast radius: updating a shared investigator shouldn't require redeploying agent workers
- Ownership: teams want to iterate on their tool endpoints without touching core
- Cost: heavy tools can be right-sized independently
Seen in¶
- sources/2026-07-14-instacart-blueberry-on-call-reasoning-harness — Blueberry's three-layer MCP architecture