Dora NodaTwo MCP servers tell you everything about where agent infrastructure stands in 2026. Arcade.dev offers your agent more than 7,500 prebuilt tools across 81 MCP servers: Gmail, Slack, GitHub, Salesforce, and thousands more, all behind one OAuth-brokered connection. Capix MCP offers 37 tools.
Thirty-seven. And yet only one of these two servers can deploy a private LLM to a GPU, roll back a website, or re-run a failed batch job — because only one of them operates infrastructure at all.
That is the comparison this post makes concrete. Tool count is the wrong metric for agent infrastructure. The right question is what happens when a tool call mutates something you own: who authorized it, what did it cost, and can you prove afterward exactly what the agent did? Here is the shape of the answer, up front:
| Integration runtime (Arcade) | Infrastructure control (Capix) | |
|---|---|---|
| What the agent operates | Someone else's SaaS: mail, chat, CRM, repos | Deployments, GPU compute, models, jobs, websites |
| Auth model | Per-user OAuth brokered server-side; the LLM never sees a token | OAuth PKCE or API key; read-only tools auto-run, billable tools need a bound approval token |
| Spend control | None needed — SaaS calls don't mint bills per call | Quote first (15-minute TTL), then approve, then deploy — no spend without explicit consent |
| Blast radius of one bad call | A wrong email sent, a wrong row written | A workload deployed, a GPU-hour billed, a site rolled back |
| Audit story | Governed execution logs of SaaS actions | Signed route receipts: placement, price, cost basis, fees, margin |
| State model | Stateless per call; truth lives in the SaaS | Deployment phases, job cursors, release histories the agent reads back |
Neither row is "better." They solve different problems. But if you run machines — a self-hosted PaaS, a GPU fleet, any substrate with bills and blast radius — only the second column is your blueprint, and even it leaves work for you to finish.
What 7,000 integrations actually solve
Start with what Arcade gets right, because it is genuinely the hard part of its problem. Before an integration runtime, every agent that touched SaaS repeated the same undifferentiated plumbing: implement an OAuth dance per provider, store and refresh per-user tokens somewhere safe, scope each call, and keep all of it out of the model's context. Arcade's Engine — hosted or self-hostable — absorbs that whole layer. A tool declares what it needs, as in the framework's own example:
@app.tool(requires_auth=GitHub(scopes=["repo"]))
async def list_my_repos(context: Context) -> list[str]:
"""List the authenticated user's GitHub repositories."""
token = context.get_auth_token_or_empty()
...Arcade prompts the end user to authorize, stores and refreshes the token, and injects it into that call's context at runtime. The client and the LLM never see the secret. Twenty-two provider helpers ship with the open-source framework (GitHub, Google, Slack, Notion, Linear, and the rest), a generic OAuth2 class covers everything else, and late-2025 additions like URL Elicitation let users complete authorization, payments, or sensitive-data collection in the browser from inside an MCP session. Framework support spans LangChain, OpenAI Agents, CrewAI, Google ADK, Vercel AI, and more — the point being that the runtime, not your agent code, owns the credential lifecycle.
That is a real achievement, and production agent deployments genuinely needed it. But notice the shape of every tool in the catalog: each one calls an API that someone else operates. The blast radius of a confused tool call is bounded by the SaaS's own permissions.
There is no per-call bill to approve, no fleet state to reconcile, no machine to provision. When your agent's whole world is other people's services, "broker the credentials and log the call" is a complete answer. The moment the agent operates infrastructure you own, it stops being one.
What 37 tools do differently
Capix MCP is the opposite bet: a small tool surface where every verb exists to mutate infrastructure. The server (Apache-2.0, stdio or streamable HTTP, wired into Claude Code with a three-line .mcp.json) exposes 37 capix_ tools in six scopes: discovery, quoting, deploy and jobs, training runs, agent runtimes, websites, and the GPU marketplace. A private model endpoint, a LoRA fine-tune, a durable batch job with log cursors, a hosted agent runtime, a website with build → preview → promote → rollback — each is an MCP tool call away from any coding agent.
The interesting part is not the inventory. It is the control loop around the billable verbs, which reads like a checklist for anyone building agent-operated infrastructure:
Quote before spend. Nothing billable runs directly. The agent first calls capix_compute_quote or capix_model_quote and gets a canonical quote with a 15-minute TTL. Only then can it call capix_deploy — with a bound approvalToken obtained after quoting the cost upstream.
No quote, no token, no spend. The consent is cryptographic, not conversational: "the user said yes in chat" is not the mechanism; a token bound to a specific quoted price is.
Receipts after spend. capix_receipts and capix_inspect_receipt return signed route receipts recording placement, price, cost basis, fees, and margin for completed work. The agent's actions produce machine-readable evidence with a signature, not just a chat transcript claiming something happened.
No phantom routes. A registry-level gate test asserts every tool's canonical path against an audited allowlist of real control-plane route families — the documented surface is the true surface, verified in CI, so a tool can't drift into calling an endpoint nobody reviewed.
Read-only tools auto-run after authentication; the friction lands exactly where the money and the mutations are. That is the correct shape. And it is also where the remaining gaps become visible — because Capix demonstrates the pattern on Capix's network, while your PaaS has to complete it on machines you own.
The owned-infrastructure checklist
Think of each item below as a status line: Arcade doesn't attempt it (SaaS-shaped by design), Capix partially demonstrates it (on its own network), and a self-hosted PaaS must complete it (on your hardware, under your tenants).
1. Scoped deploy authority. Capix authenticates the caller — OAuth PKCE through its auth broker or a CAPIX_API_KEY — and scopes reads to a project. But one key that can deploy anything is still one key. On shared hardware with multiple tenants, deploy authority needs finer grants: this agent may deploy to staging, may promote to production only with a human approval token, may never touch another tenant's namespace.
Borrow the established shape — per-agent scoped tokens, per-tool grants, credentials held by the server so agents never see them — and apply it to infrastructure verbs, where "over-permissioned" means a runaway agent re-provisions your GPU pool, not just reads the wrong inbox.
2. Machine-readable fleet state. Capix returns deployment phases, allocation states, and job log cursors the agent can read back — the minimum viable loop of act, then observe. Your PaaS has to ground that loop in owned-node reality the network API can't see: is the node the deployment landed on actually healthy, is the GPU under memory pressure, did the rollout stall because the machine is draining?
An agent operating a fleet needs the reconciled state (desired vs. actual, per machine), not just the control plane's optimistic answer.
If the state endpoint can say "deployed" while the workload is crash-looping on a sick node, the agent will confidently report success and move on.
3. An audit trail the agent can't rewrite. Capix's signed receipts are the pattern to copy: every mutation emits tamper-evident evidence. The completion step is anchoring that evidence outside the agent's reach — append-only storage where the agent holds no delete or modify grant, with the authorization decision (which approval token, which quoted price, whose consent) recorded alongside the action. This is also where the broader MCP security guidance converges: log every tool invocation with parameters and originating context, keep immutable records of actions and authorizations, and treat scope-enforcement logs as first-class evidence.
When a tenant asks "why did my bill spike Tuesday," the answer must come from records the billing agent itself could not have edited.
4. Cost guardrails that bind before spend — adopted, not reinvented. This one Capix already solves: quote with a TTL, bind the approval to the quoted price, deploy only with the token. A PaaS MCP server should lift the mechanism wholesale. The only remaining work is mapping it onto owned cost: network credits become node-hours, GPU-hours, and egress bytes, and the quote has to reflect your actual capacity (a GPU-hour you don't have isn't quotable at any price).
The failure mode to avoid is the "conversational yes" — an agent that treats chat consent as spend authorization will eventually spend real money on a misunderstood sentence.
5. Break-glass human override. Neither runtime's tool catalog helps when the agent itself is the failure: the loop submitting deploys in a retry storm, the promotion that should never have happened, the job burning GPU-hours on a hung run. Cancel, rollback, and terminate must be human-reachable without going through the agent — a dashboard, a CLI, an API key on a different trust path — and they must work when the agent layer is wedged, not just when it's cooperative. Capix ships the verbs (capix_cancel, capix_website_rollback, capix_job_cancel); the PaaS completes them by guaranteeing a human can reach them during the incident the agent caused.
Why your PaaS MCP server looks like Capix, not Arcade
Map the checklist onto PaaS primitives and the design falls out. Deploy-from-git becomes a billable verb behind quote-and-approve. Build logs and release histories become the machine-readable state.
Preview → promote → rollback becomes the guarded promotion path with human break-glass. Node and GPU pools become the capacity behind the quotes. The MCP server for a self-hosted platform is not an integration layer over other people's SaaS — it is the control plane's agent-shaped front door, with the same obligations any control plane has: authenticate, authorize, reconcile, and keep receipts.
That framing also predicts where the ecosystem goes next. Integration runtimes will keep winning on breadth — more providers, smoother OAuth, better governance for SaaS-shaped tools — because that problem is genuinely about coverage. Infrastructure control will be won on depth: finer scopes, truer state, harder receipts. The two surfaces may eventually merge into one runtime that does both, but today they are different engineering problems wearing the same protocol, and confusing them is how you end up with an agent that can read your inbox superbly and deploy to your fleet with no audit trail at all.
So count verbs, not tools. Seven thousand integrations that can't touch a machine are worth less — to an operator — than thirty-seven that can quote, deploy, and prove it. And if you're building the platform those machines live on, the checklist above is your spec: scoped authority, reconciled state, immutable audit, binding quotes, human break-glass. Everything else is SaaS somebody else operates.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agents as first-class operators. Star the repo on GitHub or deploy your first app today.
