AI
Reusing RPCs Instead of Writing MCP Servers
HubSpot runs 2.1 microservices per engineer across 2,300 engineers. When MCP arrived, teams wanted to add tools to a central server. The bottleneck was real. Klapow’s team noticed that every new MCP tool was just a thin Python wrapper around an existing RPC call. They asked why not call the RPC directly. HubSpot had already moved from REST to a custom typed RPC framework called Chirp. Chirp uses contract-first definitions, generated clients, and a schema registry. The infrastructure was already in place.
Two Annotations Unlock 2,000 Tools
HubSpot added two annotations to Chirp: @ChirpToolService and @ChirpTool. Engineers add a tool description and an audience parameter to their existing RPC interface. That is it. The only new component is a gateway that serves the MCP protocol. The gateway translates incoming MCP calls into Chirp RPCs. Engineers never touch MCP directly. The gateway also handles dynamic schema remapping for different model providers and exposes a registry of all tools for vector search. Teams can scope which tools appear on which gateway for internal employees versus third-party integrations.
97% of Tools Come From Other Teams
The platform inverted control. Teams outside the AI group own 97% of the 2,000 tools. They build and ship without telling Klapow’s team. The single pattern for tool calling across all languages reduced fragmentation. Engineers stopped deploying separate MCP servers in Python, TypeScript, and Cloudflare. Security improved because the attack surface collapsed to one validated protocol. MCP tool calls grew 80x over the measured period. The same approach now extends to agents through an internal library called Aviator, where registering any of the 2,000 tools takes one line of code.
Q&A
How do you handle MCP features beyond tool calling? Tool calling is the dominant use case. Other MCP features are deferred to the gateway layer or remain TBD until a major use case appears. ▶ Watch (18:04)
Do agents get confused with 1,800 tools? No agent loads all 1,800 tools. Tool search over the registry works well because every schema requires descriptions. Agents with 150 tools loaded do not perform well. ▶ Watch (20:56)
Can tools call other tools? Yes. Every tool is also a normal Chirp RPC with generated clients. Teams compose tools from different services into new agents without coordination. ▶ Watch (22:03)
Notable Quotes
“Why don’t we just call that RPC directly? Like, why are we going through this extra work of distributing this SDIO MCP server and annotating in Python and etc. etc. It doesn’t seem worth it.” Ze’ev Klapow · ▶ Watch (6:17)
“97% of tools are owned by teams other than my team and they don’t talk to us. They don’t tell us that they’re building these things. I have no idea what 90% of these tools do.” Ze’ev Klapow · ▶ Watch (13:24)
“Even crappy RPCs exposed via MCP have been a huge unlock for us.” Ze’ev Klapow · ▶ Watch (20:09)
Key Takeaways
- Annotating existing RPCs with two markers replaced writing separate MCP servers.
- A single gateway translates Chirp RPCs into MCP for any client.
- 97% of tools are built by teams outside the central AI platform group.
About the Speaker(s)
Ze’ev Klapow is a Principal Software Engineer at HubSpot, where he has spent 13 years building infrastructure. He currently leads efforts to bring AI tooling to HubSpot engineers and designed the unified agent infrastructure that powers both internal and customer-facing AI products.