Should you build "Openrouter for tools"?

Why does “OpenRouter for tools” suddenly make sense now?

An OpenRouter for tools makes much more sense today because AI agents can access thousands of external tools, and choosing the right one is becoming a problem of its own.

MCP is a big reason. Anthropic said in December 2025 that more than 10,000 active public MCP servers already existed, with MCP supported by ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code. Anthropic then donated MCP to the Linux Foundation's Agentic AI Foundation alongside OpenAI and Block. What started as an Anthropic protocol has effectively become shared infrastructure for the agent ecosystem.

The ecosystem keeps getting easier to aggregate. The official MCP Registry is now live and continues to receive new and updated servers. The July 2026 MCP specification also made requests easier for gateways to handle: tool lists can be cached, sessions no longer have to be used for every interaction, and routing information can be exposed in ordinary HTTP headers.

So a startup can now sit between agents and a large number of tools without inventing its own protocol. That was much harder two years ago.

The opportunity comes from what happens after those tools become available: finding the right one, deciding whether it can be trusted, comparing alternatives, paying for it and falling back when it fails.

Has someone already built an “OpenRouter for tools”?

Yes. The generic “OpenRouter for tools” pitch is already crowded enough that we would avoid launching another product with exactly that proposition.

ToolRouter currently describes itself almost word for word as “the OpenRouter for tools.” Its public catalog lists 254 tools and 1,345 skills, with one MCP connection and centralized billing. Monid uses the phrase “OpenRouter for agent tools” and currently advertises more than 1,700 tools across 71 categories, including price-based routing. ToolRoute also offers a unified API across more than 70 agent tools.

Then there are much larger adjacent products. Composio currently advertises more than 1,500 toolkits. Pipedream exposes more than 3,000 APIs and 10,000 prebuilt tools through its MCP infrastructure. Arcade is tackling the same action layer from the enterprise authorization side.

The exact counts need some caution because these companies define “tool,” “skill,” “API” and “integration” differently. Still, the competitive picture is clear. Putting lots of tools behind one endpoint is already a product category.

Platform	What it currently advertises	Main angle
ToolRouter	254 tools, 1,345 skills	Hosted specialist tools + billing
Monid	1,700+ tools	Discovery + price routing + pay per call
ToolRoute	70+ tools	Unified agent-tool API
Composio	1,500+ toolkits	SaaS integrations + auth + execution
Pipedream	3,000+ APIs, 10,000+ tools	Integration infrastructure + MCP
Arcade	Large governed tool layer	Authorization + enterprise actions

Is tool routing really the same problem as model routing?

Only partly. OpenRouter works unusually well because AI models and inference providers are much easier to compare and substitute than most software tools.

OpenRouter currently routes across more than 80 providers. When several providers serve the same model, the underlying job stays very similar. OpenRouter can compare price, latency, throughput and uptime, then try another provider if the first one fails. Its documentation now says the network serves more than 10 million developers.

Tools behave differently. Exa and Tavily can both perform web search, so routing between them makes sense. Two scraping providers may also compete for the same URL. Gmail and Salesforce are different. If an agent needs to update a Salesforce opportunity, another CRM cannot complete the same action just because Salesforce is temporarily unavailable.

Side effects make the problem harder too. Repeating an inference request usually costs extra money but causes little damage. Repeating a payment, email or database deletion can change the outside world twice. That makes retries, idempotency and permission handling much more important.

The OpenRouter analogy is therefore strongest when several providers can genuinely complete the same job.

Model routing	Tool routing
Inputs are fairly standardized	Inputs can differ a lot
Outputs are fairly comparable	Outputs may have different structures and quality
Several providers can serve the same model	Many tools have no real substitute
Automatic retries are usually safe	Some retries can repeat real-world actions
Price and speed are easy to measure	Quality often depends on the exact task
Provider credentials usually cover the request	SaaS actions often require each user's OAuth access

Does MCP make an OpenRouter for tools too easy to copy?

MCP is quickly commoditizing the basic aggregation layer, so “we connected lots of tools” is becoming a weak moat.

The official MCP Registry already handles public server discovery. Any compatible agent can inspect a server's available tools and schemas through the protocol. Recent MCP changes also make tool listings cacheable and give gateways cleaner ways to inspect, meter and route traffic.

Authorization is moving into the standard as well. Enterprise-Managed Authorization became an MCP extension in 2026, allowing companies to provision access centrally instead of making every employee repeatedly authorize every tool.

These improvements are great for the ecosystem. For a new startup, though, basic plumbing earns less and less credit.

A catalog can still be useful, but catalog size will become harder to defend. The valuable questions sit one level higher: which provider should the agent choose, which provider actually works best for this request, how much will it cost, and what happens when it fails?

Do AI agents really need tool routing, or just a bigger catalog?

AI agents increasingly need tool routing because giving a model more tools can actually make tool selection harder.

A May 2026 research paper tested tool retrieval across registries containing between 20 and 3,251 tools. On the Berkeley Function Calling benchmark, which contained 370 tools, an adaptive retrieval system showed the model only about seven tools on average and still included the correct tool 90.3% of the time. Showing 50 tools achieved 90.8%.

The difference became more interesting when Claude Sonnet 4.6 had to choose the final tool. Adaptive shortlists reached 93.1% selection accuracy compared with 87.1% for a fixed five-tool shortlist. On medium-difficulty requests, where the correct tool existed but was harder to retrieve, the gap widened to 76.8% versus 60.9%.

We should be careful with one preprint, especially because benchmark tool selection is cleaner than production agent behavior. But the direction makes intuitive sense. An agent with access to 3,000 tools should search its tool universe before deciding what to call, just as a person searches the web instead of reading thousands of websites at once.

Runtime tool retrieval is one of the more convincing parts of the opportunity.

Is MCP tool reliability bad enough for routing to help?

Yes. Even the limited public measurements we have show enough variation in MCP reliability and latency to make fallback useful today.

MCPWatch tested 11 public MCP servers in June 2026 using a real MCP handshake rather than a simple uptime ping. The fastest completed the handshake in 97 milliseconds. The slowest took 20.8 seconds. Median latency was 522 milliseconds, creating a 215-fold gap between the fastest and slowest servers.

Eleven servers are far too few to describe the whole MCP ecosystem, so we would not turn that result into a grand reliability statistic. What it does show is that two supposedly compatible MCP endpoints can offer wildly different experiences.

The same problem appears when schemas change. MCPWatch found 245 tools across those 11 servers and pointed out that a normal HTTP uptime check will happily report a server as healthy even after a tool has been renamed or its expected inputs have changed.

A useful router could watch the actual execution path, detect degradation and move traffic elsewhere when an equivalent provider exists. For interchangeable tools, that is a real product, not just a nicer gateway.

Which tools are actually good candidates for OpenRouter-style routing?

The best candidates today are search, scraping, enrichment, browser automation and other capabilities where several providers can complete roughly the same job.

Web search is the cleanest example. An agent could potentially use Exa, Tavily, Brave Search, Serper or SerpAPI. Providers vary in price, freshness, latency, geographic coverage and the kinds of queries they handle well.

Scraping has the same shape. One provider may handle ordinary HTML cheaply while another succeeds more often on JavaScript-heavy or protected websites. Image and video generation also fit because the user usually cares about the output rather than which underlying API produced it.

SaaS actions behave very differently. A user's Gmail inbox has to be accessed through Google. A Notion page lives in Notion. A Salesforce opportunity lives in Salesforce. Routing can help an agent choose the right connected system, but there is little provider competition once the destination is known.

Tool category	Routing potential	Why
Web search	Very high	Several providers answer the same request
Web scraping	Very high	Providers compete on success, speed and cost
Data enrichment	High	Multiple vendors sell overlapping data
Image/video generation	High	Many models and inference providers
OCR/transcription	High	Inputs and expected outputs are fairly standardized
Browser automation	Medium-high	Same goal can be executed by different runtimes
Gmail/Slack	Low	The user's account determines the provider
Salesforce/HubSpot	Low	Data lives inside a specific application
Payments	Very low	Stateful actions make rerouting risky

Is one balance for every agent tool actually valuable?

Yes. Unified billing is one of the genuinely useful parts of an OpenRouter for tools, especially when agents start discovering paid capabilities dynamically.

Monid currently lets agents discover tools together with their per-call prices and charges everything against one balance. ToolRouter takes a similar approach: free tools remain free, while paid calls include the provider's cost plus a $0.005 platform fee. Its credit top-ups currently carry a 5.5% purchase fee.

Composio has independently moved toward the same economic model for expensive capabilities. Its premium tools include things such as web search, browser automation and media generation, with the underlying provider charge passed through plus a 5% platform fee.

The pattern is pretty clear. Unified credits make the most sense for capabilities that already have metered external costs. An agent can decide that it needs a search, a browser session or an image without its developer opening another account every time.

The awkward part is provider contracts. Some APIs allow resale or hosted credentials, while others expect every customer to bring a separate API key. A universal balance therefore requires commercial integration work alongside the technical integration work.

Can an OpenRouter-for-tools business make good margins?

A generic tool-call gateway can become a painfully low-value business unless it routes expensive work or processes huge volume.

Composio's current pricing shows how cheap ordinary tool execution is becoming. New customers receive 100,000 tool calls per month for free, with standard overage priced at $0.0003 per call. Even 10 million billable calls at that rate would generate only about $3,000 in usage charges before considering the cost of running the infrastructure.

ToolRouter's current $0.005 platform fee on a successful paid call produces $5,000 from one million paid calls. Better, but it still demands meaningful volume unless the company also earns from credit purchases, subscriptions or other services.

Premium capabilities have more attractive economics because more money already flows through each request. A 5% fee on $100,000 of search, scraping, browser and generation spend produces $5,000 in platform revenue. The router can also save enough money through provider selection to justify its share.

We would not build the business around millions of almost-free Gmail or Notion actions. Expensive, substitutable API consumption gives the router more room to earn money and more room to save customers money.

Is authentication more valuable than routing for SaaS tools?

For Gmail, Slack, Salesforce and other SaaS tools, authentication and permission management currently look more valuable than provider routing.

Pipedream illustrates the scale of this problem. Its current MCP product exposes more than 3,000 APIs and 10,000 tools while managing the underlying account connections. Developers get the integrations without having to build separate OAuth flows and token-refresh systems for every application.

Arcade has gone even harder at this layer. The company raised a $60 million Series A in June 2026, bringing total financing to $72 million, and said tool-call volume had increased 25-fold in six months. Its pitch centers on delegated authorization, identity, permissions and governance rather than finding a cheaper alternative to Gmail.

Snowflake's planned acquisition of Natoma in May 2026 points in the same direction. Snowflake said Natoma's MCP gateway would extend governance from company data to the actions AI agents perform across enterprise applications.

For enterprise SaaS actions, buyers seem increasingly worried about who authorized the agent, what it can access and what it is allowed to change. A new company attacking this part of the market would run directly into well-funded specialists and large infrastructure vendors.

Could execution data become the real moat for a tool router?

Yes. The strongest version of this company would learn which provider actually works best for each kind of request, using millions of real executions rather than documentation and marketing claims.

OpenRouter gives us a good picture of what that can become. Its provider routing currently uses live price, latency, throughput and uptime data. Providers need enough requests before their reliability is scored, and OpenRouter's Auto Exacto system separately looks at real tool-calling success when ranking providers for tool-heavy model requests.

A capability router could build a richer version of that dataset. Over time it might learn that one search API performs better for breaking news, another produces cleaner company URLs, a particular scraper fails more often on Cloudflare-protected sites, or one browser provider completes checkout-like workflows with fewer retries.

Composio is already accumulating the kind of volume that could feed such systems. The company currently says it processes more than 300 million tool calls per month across more than one million connected accounts and uses those execution patterns to improve tool accuracy and retries. Those are company-reported figures, but the order of magnitude is important.

A static catalog is copyable. A large history of request types, provider choices, failures, costs and successful outcomes gets harder to reproduce with every call.

Does a new tool router have a cold-start problem?

Yes. A new tool router begins with almost none of the data needed to make its routing genuinely intelligent.

On day one, we can read provider documentation, collect published prices and run benchmarks. We still will not know how those providers behave across thousands of messy real requests. We will have little evidence about failure rates by task, changing latency during load spikes, retry behavior, geographic differences or which outputs users actually accept.

Trying to solve this across 1,000 unrelated tools would make the problem worse. Most tools would receive too little comparable traffic to teach us much.

A much better starting point would be one capability with several competing providers. If we route 100,000 search or scraping requests, each request teaches us something comparable. If we route 100,000 requests across 5,000 unrelated SaaS actions, the resulting data is much thinner.

That is a big reason the narrow version looks more attractive than the universal one.

Is there enough money in agent tools for another infrastructure company?

Yes, the agent-tool market is already big enough to create large infrastructure companies, although that does not guarantee a horizontal router will win.

OpenRouter itself gives us the strongest analogy. When it announced its Series B in June 2026, weekly traffic had grown from 5 trillion to 25 trillion tokens in six months. The company said it was serving more than eight million developers at the time; its current provider page now says more than 10 million. OpenRouter raised $113 million in that round.

The action side is attracting serious money too. Arcade has raised $72 million. Snowflake decided that enterprise MCP governance was important enough to acquire Natoma. Pipedream and Composio are both turning large existing integration catalogs into infrastructure specifically designed for AI agents.

We are well past the stage where the question is whether agents will spend money calling external tools. They already do.

The harder question is who captures the margin. Tool providers own the underlying service. Integration companies own many authenticated connections. Cloud and enterprise platforms own distribution. A router has to earn its position in the middle by making execution materially cheaper, more reliable or easier.

What should an “OpenRouter for tools” actually route?

We would focus an OpenRouter for tools on interchangeable capabilities and let existing integration companies handle most traditional SaaS connectors.

The first version could cover web search, scraping, structured extraction and perhaps browser automation. A developer would ask for the job they need instead of choosing a provider themselves. The router would select an eligible provider using price, recent reliability and task performance, then normalize the result and fall back safely when required.

For example, a developer could send “search the recent web for this company” without deciding whether Exa, Tavily or another provider should handle it. Another request could say “extract the products from this page,” leaving the router to choose between several scraping backends.

Once enough requests accumulate, routing could become more specific. Search providers might be scored differently for academic research, news, people, companies and shopping. Scrapers could be scored by website type. Browser runtimes could be scored by task completion rather than simply uptime.

MCP should be supported because agents increasingly expect it, but REST and agent Skills could expose the same capabilities. The product would live above those interfaces.

We would also resist the temptation to launch with 5,000 tools. Ten genuinely interchangeable providers generating dense execution data are more useful than thousands of integrations that barely overlap.

Could a small team build this without becoming another huge integration platform?

Yes. A small team could test the useful part of the OpenRouter-for-tools thesis without rebuilding Zapier, Pipedream or Composio.

Search and scraping look especially attractive for a first wedge. Several providers already compete for the same jobs, developers frequently use more than one, failures are common enough for fallback to help, pricing is usage-based, and many results can be evaluated automatically.

The first product can stay simple: one API, several providers, normalized output, automatic fallback and one balance. We would initially let developers choose their routing rule themselves, such as cheapest, fastest or preferred provider with fallback.

Intelligent routing should come after real usage creates enough evidence to support it. Before that, “AI routing” is mostly a fancy name for a few hard-coded conditions.

If the narrow product gets meaningful traffic, adjacent capabilities can be added one by one. Each new category should have enough provider overlap for routing to improve the experience. That constraint keeps the catalog smaller but makes almost every addition useful.

Should you build “OpenRouter for tools”?

We would skip the generic “OpenRouter for tools” idea today and seriously consider a narrower router for interchangeable agent capabilities.

The broad version has lost much of its whitespace. ToolRouter, Monid and ToolRoute are already pitching it directly. Composio and Pipedream have much larger integration catalogs. Arcade and enterprise MCP gateways are building the authorization and governance layer. Meanwhile, MCP keeps making raw connectivity and discovery easier to reproduce.

The narrower opportunity still looks good. Search, scraping, enrichment, browser automation, media generation and similar capabilities have several competing providers, meaningful price differences, uneven reliability and enough usage cost to support a routing fee. They also generate comparable executions, which gives a startup a realistic way to build proprietary routing data.

We would make that data the center of the company. Every call should improve our understanding of which provider works best for which task, how much it costs and when it is likely to fail. As the dataset gets better, automatic routing becomes harder for a developer or a new competitor to recreate.

So the answer is no to “OpenRouter for every tool,” but yes to the underlying idea if it is narrowed aggressively. The version we would build is an OpenRouter for capabilities: a small set of substitutable tools, one bill, safe fallback, normalized outputs and routing that gets measurably better as usage grows.