Trunkline
A shared MCP registry that gives an organization one authenticated endpoint for every internal AI tool it builds.
trunkline.dev- Role
- Creator · Product Designer · Engineer
- Timeline
- 2025 – Present
- Built with
- Next.js 16 · TypeScript · Convex · Better Auth · MCP
/mcp/acmediscover · authenticate · routeThe tools were multiplying faster than teams could share them.
MCP made it easier for developers to give AI agents access to useful systems. It did not solve distribution. Each server still came with its own URL, setup instructions, credentials, and maintenance burden.
That created a familiar organizational failure mode: one team would build a valuable tool, a few people would configure it locally, and everyone else would either never discover it or rebuild a weaker version. New employees inherited a scavenger hunt through docs, chat threads, and copied configuration files.
An internal tool does not become organizational infrastructure until other people can discover, trust, and use it without knowing where it lives.
Centralize the contract, not the tools.
I did not want teams to rewrite working MCP servers or move their logic into a new platform. Trunkline sits between those servers and the agents that use them: it discovers what each server offers, presents a single organization-level catalog, then proxies calls back to the source.
The core loop stayed intentionally short. An admin registers a server. Trunkline discovers its tools. A teammate connects one endpoint. Their agent can then list and call everything the organization has made available.
- 01RegisterAdd a server URL once.
- 02DiscoverIndex its tools and schemas.
- 03ConnectConfigure one shared endpoint.
- 04RouteSend each call to its owner.
The product decisions followed the adoption path.
Each choice reduced the work required to share or consume a tool, while making the resulting system tradeoff visible.
- 01
Should teams move their tools into Trunkline?
- Signal
- Internal MCP servers already contained useful logic; the adoption problem was distribution, not implementation.
- Decision
- Centralize the contract while leaving each tool on the server that owns it.
- Tradeoff
- Trunkline must handle upstream differences and failures, but teams can adopt it without rewriting working services.
- 02
What should a teammate have to configure?
- Signal
- Separate URLs, credentials, and setup instructions made every additional server harder to discover and maintain.
- Decision
- Expose one stable organization endpoint that aggregates discovery and routes each tool call to its source.
- Tradeoff
- The routing layer becomes critical infrastructure, but the consuming experience shrinks to one URL and one credential.
- 03
How much infrastructure should the interface reveal?
- Signal
- Admins need server health and re-sync controls, while everyday users mainly need to know what tools exist and whether the endpoint works.
- Decision
- Separate infrastructure management from routine access through role-aware surfaces and organization-scoped keys.
- Tradeoff
- Role boundaries add product and authorization complexity, but prevent operational detail from burdening every teammate.
- 04
How broad should the first release be?
- Signal
- The product needed to prove that a real user could move from account creation to a successful routed tool call.
- Decision
- Ship the complete vertical path first and explicitly defer collision handling, scheduled monitoring, analytics, and enterprise controls.
- Tradeoff
- The MVP covers fewer edge cases, but validates the riskiest system and adoption assumptions end to end.
The product made infrastructure understandable.
The interface follows the same mental model as the system: organization, servers, tools, endpoint, access. Each surface answers one operational question without exposing the routing machinery underneath.
https://api.trunkline.dev/mcp/acmeAuthorization: Bearer trk_••••••••Server registry
Admins register an MCP server once. Trunkline checks the connection, stores its organization boundary, and keeps its health visible.
Tool catalog
The product calls tools/list, indexes each schema, and gives the team one shared inventory instead of a collection of local config files.
Organization endpoint
Every client connects to the same stable URL. Trunkline aggregates discovery and routes each call to the server that owns the tool.
Access controls
Organization-scoped API keys protect the shared endpoint, while admin and member roles separate infrastructure management from everyday use.
Team workspace
Invitations, organization switching, and shared access make the registry an organizational product rather than a single-developer utility.
Agent-ready contract
The endpoint implements MCP initialization, discovery, and tool calls over JSON-RPC so compatible clients can use the registry without custom adapters.
The routing layer is the product.
The web dashboard manages the registry; Convex owns realtime state and HTTP actions; the MCP endpoint translates one organization-level contract into calls against many upstream servers.
- 1 · Authenticate
- Hash the bearer key and verify that it belongs to the organization in the endpoint URL.
- 2 · Discover
- For tools/list, collect the organization's indexed tool definitions into one MCP response.
- 3 · Resolve
- For tools/call, find the registered server that owns the requested tool.
- 4 · Proxy
- Initialize the upstream server, forward the JSON-RPC request, and return its response.
- 5 · Observe
- Record method, tool, duration, and success for operational visibility.
Make many servers feel like one
The registry had to merge tool definitions across independent MCP servers, preserve their schemas, and still know exactly where to send a call.
Secure the invisible path
Because most usage happens agent-to-endpoint, authentication could not depend on the web session. Keys are generated once, stored as hashes, and checked against the organization on every request.
Keep failure legible
An upstream server can be unavailable even when Trunkline is healthy. Server status, re-sync actions, JSON-RPC errors, and request logs make that boundary visible.
Design for tenancy from day one
Organizations, memberships, servers, tools, invitations, keys, and logs all share the same explicit organization boundary rather than adding isolation later.
A working MVP, with the roadmap kept honest.
The first version deliberately proved the full path—from account creation to a real tool call—before expanding into enterprise controls and operational depth. The public product language described the larger vision, but the implementation kept a clear boundary between what worked and what still belonged on the roadmap.
Shipped
- Email and GitHub authentication
- Organizations, roles, and invitations
- Live MCP server registration and re-sync
- Automatic tool and schema discovery
- One authenticated endpoint per organization
- tools/list aggregation and tools/call routing
- API key creation, revocation, and last-used state
- Request logging for future usage analytics
Deferred
- Tool-name collision handling and namespaces
- Scheduled health monitoring
- Version-aware routing and rollback
- Usage trends and billing
- SSO, SAML, and enterprise controls
- A production registration CLI
The result was a complete vertical slice of shared AI infrastructure.
Trunkline moved from a dashboard concept to a functioning multi-tenant product: teams could create an organization, invite collaborators, register live MCP servers, discover their tools, issue an API key, and use those tools through one authenticated endpoint.
The most important design decision was also the simplest: make adoption easier for the people consuming tools than for the people distributing them. A teammate should not need to understand server topology to use organizational knowledge; they should need one URL and one credential.