Toolshed model: 400+ tools behind one MCP (Stripe)

The Toolshed model, pioneered by Stripe, consolidates hundreds of distinct tools behind a single MCP endpoint. Rather than running dozens of separate MCP servers - one for GitHub, one for Jira, one for internal APIs, one for the database, one for Slack - the Toolshed model runs one centralized MCP server that routes requests to the appropriate backend. Stripe's implementation reportedly exposes over 400 tools through this single endpoint, covering the full spectrum of developer workflows: code retrieval, issue tracking, deployment triggering, incident management, documentation lookup, and internal API access.

The architectural innovation is the aggregation layer. Instead of agents needing to know which MCP server handles which tool category, they connect to one endpoint and discover all available tools through the MCP protocol's tool enumeration mechanism. The agent sends a tools/list request and receives a complete catalog of 400+ available tools with their descriptions, input schemas, and permission requirements. The agent then calls whichever tool the task requires without knowing (or caring) which backend system ultimately handles the request.

RBAC in the Toolshed model operates at the single endpoint level. Rather than each backend server implementing its own authorization, the Toolshed gateway enforces a unified policy: this agent role can call these tools, this agent identity is permitted to use these data sources. The policy enforcement is centralized and consistent, which makes auditing, updating, and reasoning about access much simpler than maintaining authorization logic across dozens of separate servers.

The Toolshed model represents the maturation of MCP from "we connected a few tools" to "MCP is the standard way everything in this organization is accessed by agents." At this level, if a developer wants to give an agent access to a new data source, they add it to the Toolshed rather than deploying a new standalone MCP server. The Toolshed becomes the standard integration layer between AI agents and organizational systems.

• Eliminates MCP server proliferation - instead of managing 30 separate MCP servers with independent credentials, deployments, and failures, the organization manages one platform; operational complexity drops dramatically
• Enables true tool discovery - with a single endpoint, agents can enumerate all available tools and select the right one for any task; with 30 separate servers, agents need to know which server to connect to before they can discover its tools
• Unifies RBAC and audit - authorization policies and access logs live in one place; security teams can query "what did agent X do in the last 24 hours" against a single log, not 30 separate logs
• Makes new tool addition trivial - adding a new integration means adding a backend to the Toolshed, not deploying a new server, creating new credentials, and updating agent configurations; the marginal cost of new tools approaches zero
• Demonstrates MCP at enterprise scale - Stripe's 400+ tools validates that the MCP protocol is technically sound at enterprise scale; the Toolshed model is a proven architecture, not a theoretical design

1. Audit your current MCP server footprint - list every MCP server currently deployed or planned. If you have 10+ servers, the Toolshed model's ROI is immediate. If you have 3, the payoff is in the future but the architectural direction is the same.
2. Design the gateway layer - the Toolshed gateway is the core of the model. It needs to: accept MCP connections from agent clients, maintain an internal registry of backend tools and their routing, enforce RBAC policies, aggregate tool lists from all backends, and route tool calls to the correct backend.
3. Implement tool namespace conventions - with 400 tools, naming collisions and confusion are real risks. Establish a naming convention: {service}.{resource}.{action} (e.g., jira.ticket.create, github.pr.merge, datadog.alert.acknowledge). This convention makes tools discoverable and self-documenting.
4. Migrate existing servers to Toolshed backends - rather than replacing existing MCP servers, reconfigure them to register their tools with the Toolshed instead of accepting direct client connections. The Toolshed becomes the client-facing layer; the existing servers become internal backends.
5. Build a tool catalog UI - with 400+ tools, agents need good descriptions to use them correctly, but humans need a browsable catalog to understand what's available. Build a simple web UI that lists all tools with their descriptions, required parameters, and permission requirements. This catalog also serves as documentation for teams building new agent workflows.
6. Establish tool quality standards - at this scale, tool quality variance becomes a problem. Establish standards: every tool must have a description longer than 50 characters, must include parameter descriptions, must handle errors gracefully, must be covered by integration tests. Enforce these standards as part of the tool registration process.

Building the gateway before standardizing tool schemas. If you aggregate 30 MCP servers with inconsistent tool schemas, naming conventions, and error formats, the Toolshed gateway inherits all that inconsistency. Standardize tool schemas across existing servers before aggregating them. The aggregation exposes inconsistencies that were previously hidden behind server boundaries.

Creating a single point of failure. A Toolshed gateway that all agents depend on is critical infrastructure. If it goes down, all agent workflows stop. Design for high availability from the start: at least two gateway instances behind a load balancer, health checks, and automatic failover. The operational maturity requirements for the Toolshed gateway are the same as for any production service your business depends on.

Not monitoring tool usage patterns. 400 tools means many tools that are rarely or never used. Monitoring which tools are called, at what frequency, with what success rate, reveals both optimization opportunities (popular tools get performance investment) and cleanup candidates (tools with zero usage for 90 days should be reviewed for deprecation). The usage data also reveals what agents actually need versus what the organization thought they'd need.

Scaling the tool count without scaling tool quality. Adding 400 tools is easy; ensuring all 400 tools have good descriptions, handle edge cases correctly, and return useful errors is hard. A poorly described tool in a 400-tool catalog is worse than the same tool in a 3-tool catalog - it's harder to discover and harder to distinguish from similarly-named tools. Quality gates on tool registration maintain the usefulness of the catalog as it scales.