7,000 Integrations at a Penny a Call: What a Hosted MCP Registry Costs vs Owning the Agent Path

One busy ops agent — a thousand tool calls a day, checking deploys, reading logs, filing tickets — costs about $345 a month on a metered MCP registry. Ten of them cost over $3,000 a month, before the enterprise tier that moves your tokens into your own VPC. Those numbers are not hidden; they fall straight out of the public price list. But almost nobody multiplies the per-call penny by how chatty agents actually are before wiring a hosted tool registry into the agent-to-platform path.

Arcade.dev is the sharpest example of the breed: the self-described MCP runtime for production AI agents, wrapping 7,000+ pre-built tool integrations behind the Model Context Protocol while brokering per-user OAuth centrally. The pitch is real — stop hand-rolling OAuth flows and debugging hallucinated API parameters. The question this post answers concretely is what renting that directory costs, in money and in control, against the alternative: an open, machine-readable platform API with your own MCP server in front of it, and no vendor standing between your agent and your infrastructure.

The bill first: metered registry vs owned control plane​

Arcade's public pricing is simple. Free gets you 2,000 auth events and 2,000 tool calls a month on Arcade Cloud. Team costs $25 a month plus $0.10 per auth event and $0.01 per tool call. Enterprise — the tier with VPC or air-gapped deployment, SSO, RBAC, and audit logs — is quote-based, so it has no public number at all.

Here is what that meter does at three realistic monthly volumes, next to a self-hosted baseline (a small VPS-class box running your own API plus MCP server, where tool calls are just HTTP requests you already know how to serve):

Two things jump out. First, the free tier is genuinely good for prototypes: Arcade wins row one outright, because zero dollars beats even cheap infrastructure plus an afternoon of OAuth plumbing. Second, the crossover sits almost immediately above the free tier — somewhere around 2,500–5,000 calls a month, depending on auth events — because the $25 platform fee alone is roughly the cost of the box, and every call past that is a penny of pure meter.

The sensitivity variable is agent chattiness, and it only runs one direction. A ReAct-style loop easily burns 10–50 tool calls per task across retries, confirmations, and follow-up reads. The agent that "checks on the deploy" does not make one call; it lists services, fetches the deploy, polls status, reads logs, and then does it again when the first attempt times out.

Metered pricing taxes exactly the behavior — thoroughness through retries — that makes agents reliable. On owned infrastructure, a retry costs a millisecond of a box you already pay for. On a registry meter, it costs another penny, ten thousand times a month.

The second sensitivity variable is whether you already operate infrastructure. If you run nothing, Arcade's $0 start is real value: no OAuth clients to register, no token vault to build, no MCP server to keep up. If you already run a platform — and everyone reading a self-hosting blog does — the marginal cost of exposing your own API over MCP is incremental, while the registry meter stacks on top of infrastructure you pay for anyway. And if you need the compliance-shaped deployment (your VPC, your audit trail, your SSO), the comparison has no public number on the hosted side at all, which is itself an answer about where that negotiation goes.

What Arcade actually sells​

Strip away the positioning and the Arcade Engine is three things fused into one control plane: a catalog of pre-built tools exposed over MCP, per-user OAuth brokerage with centralized token management, and a governed execution runtime. The Engine runs hosted on Arcade Cloud or, on Enterprise, inside your VPC or fully air-gapped. Agent frameworks including LangChain, OpenAI Agents, CrewAI, AG2, Google ADK, Vercel AI, Mastra, and TanStack AI can call through it.

The authorization story is the strongest part of the product and deserves a fair description. Arcade binds every authorization to a specific user: a tool declares which provider scopes it needs, Arcade runs the OAuth challenge for that user, vaults the resulting token keyed to that user, and injects it into the tool context only during that user's invocation.

The LLM never sees the credential — no tokens in reasoning traces, no API keys pasted into local MCP config files. Just-in-time consent, policy checks, and an immutable audit record ride along in the same path. If your threat model starts at "the model must never touch a raw credential," this is a serious, well-architected answer.

The catalog is the headline number: 7,000+ pre-built integrations surfaced as MCP tools, so agents can act across SaaS apps without anyone writing an integration per app. Custom tools are hand-written through the open-source arcade-mcp framework, while the Engine itself — the runtime that stores tokens, brokers OAuth, and executes calls — is proprietary. That split matters for everything that follows: the SDK is open, the vault is not.

What the catalog number hides​

Seven thousand is a count of tools, not of APIs you can reach. Independent teardowns of the catalog put the first-party footprint at roughly 80 MCP servers, split into hand-built "Optimized" and auto-generated "Unoptimized" tiers, with the long tail filled out by community and generated servers that may need customization before they are production-ready. That is not a scam — it is how every directory works — but it changes what the number promises. Coverage is deep on popular SaaS and thin exactly where your agent is differentiated: your internal APIs, your niche vendors, your own platform.

Three consequences follow. First, when your API is not in the catalog, you hand-write an MCP server in the SDK — which is precisely the work the registry was supposed to eliminate, now done on someone else's framework instead of your own. Second, generic auto-generated tools bloat agent context: a tool shaped for everyone's intent carries parameters and descriptions your agent must read on every call, and practitioners consistently report that bespoke, intent-shaped tools are both cheaper in tokens and more reliable than generic ones. Third, the directory thins under version skew: every SaaS API drifts, and a generated tool tracks the drift only as fast as the registry regenerates it.

None of this makes a catalog useless. It makes it a directory problem — discovery, naming, and routing across a large surface — and directories have a well-known shape: they want to be open protocols and machine-readable APIs, not rented meters. Nobody pays per lookup to resolve a package name. The question is never whether 7,000 integrations are impressive; it is whether your agent's calls should be metered by whoever maintains the phone book.

The three things a hosted registry puts in your agent path​

Beyond the bill, renting the registry inserts a vendor into three places that used to be yours.

1. A meter on chattiness. Covered above, but worth restating as an architectural point: per-call pricing makes your infrastructure bill a function of your agent's reasoning style. Every retry policy, every verification read, every "let me double-check that deploy status" is a purchasing decision.

Teams respond the way teams always respond to meters — by throttling the behavior being metered — and a throttled agent is a less reliable one. The meter does not just cost money; it quietly reshapes agent design toward fewer, more fragile calls.

2. Someone else's trust root for your users' credentials. On the standard tiers, end users authorize through Arcade's OAuth client — they see Arcade's name on the consent screen and sign in through Arcade's domain. Putting your own brand on the flow means registering your own OAuth client per provider and building a custom verifier route: workable, but per-provider configuration you own, not a drop-in default.

Meanwhile the tokens themselves sit in a proprietary vault on shared infrastructure, with dedicated tenant isolation, SSO/SAML, RBAC, and audit reporting gated to the Enterprise tier. The runtime that holds your users' credentials is the part you cannot inspect and cannot self-host without an enterprise contract.

3. Tool calls — and only tool calls. The registry covers the run side of one pattern: an agent calling a tool right now. Durable data syncs for RAG, webhook ingestion, polling triggers, a unified-API layer across providers — none of that is in the box.

The moment your agent needs the freshest CRM records on hand instead of fetched per call, or has to react when something changes upstream rather than poll for it, you build the sync, the schedule, the resume logic, and the webhook receiver yourself, outside the registry. Scope the platform to tool calling and the catalog shines; widen the surface to everything an agent system actually needs and the registry becomes one component among several you operate anyway.

The self-hosted alternative: an open API plus your own MCP server​

The alternative is not "hand-roll OAuth for 7,000 SaaS apps." It is a much narrower claim: for the platform your agents operate — your services, deploys, logs, incidents, and data — the agent path should be your own machine-readable API with your own MCP server in front of it, and no vendor in between.

bex takes exactly this shape. One MCP server lives with the platform API at api.bex.co/mcp: Streamable HTTP, stateless so any replica answers any request, authenticated through OAuth 2.1 or an API key exchanged for a short-lived bearer token, with RFC 9728 discovery and a small scope ladder (bex.read, bex.write, bex.sensitive). Underneath it sits a Render-compatible REST and GraphQL API — the same contract the dashboard and CLI use, which means the agent sees the platform the way every other client does, not through a translated shadow of it. Connecting Claude Code is one command:

claude mcp add --transport http bex-api https://api.bex.co/mcp

What this keeps in-house is the mirror image of the registry's three insertions. No per-call meter: tool calls are HTTP requests against infrastructure you already run, so retries are free and agent thoroughness is never a purchasing decision. Your own OAuth client and token boundary: users authorize your app, tokens live in your vault, and the audit trail is your own log pipeline rather than an enterprise upsell. And a full-surface API instead of one pattern: the same endpoints that serve syncs, webhooks, and dashboards serve the agent, because the agent is just another API client.

The honest cost of this path is the OAuth and vault engineering the registry would have done for you — scoped to your providers and your users, not 7,000 SaaS apps. That is a bounded project, not an integration treadmill. And it composes: nothing stops you from pointing agents at a hosted registry for long-tail SaaS while your own platform's tools come from your own server. The decision is per surface, not per company.

Rent the directory or own the path: a decision table​

Pulling the cost math and the control analysis together:

The rows share one hinge: the registry sells breadth (thousands of tools you did not build) while the self-hosted path sells depth (your own surface, unmetered, under your trust root). Breadth wins when your agent's value is reaching many SaaS apps you will never integrate yourself. Depth wins the moment the agent's most important tools are the ones describing infrastructure you own — because then the registry is charging you rent to operate your own machines, and holding your users' tokens in a vault you cannot open, to do it.

That is the directory problem restated as a buying rule. Rent directories for discovery across surfaces you do not own. Never rent the path to surfaces you do — publish an open, machine-readable API, put your own MCP server in front of it, and keep the penny-per-call meter out of your agent's reasoning loop.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API and a self-hosted MCP server your agents can operate today. Star the repo on GitHub or deploy your first app today.