Every few months the AI story gets a new headline. A new model, a new agent, a new protocol. But if you squint, every headline since 2023 has been the same story underneath.
The model got smarter, and then it needed to touch something. A calendar. A CRM. A shipping system. A website. And every time, the thing it needed was an API.
This post is that story, from ChatGPT to MCP, and why APIs quietly became the most important part of the AI stack. Then it's the research: every agent API platform I could find, funded and open source, popular and tiny, with what they cost and what you give up with each.
Part 1: How we got here
2023: the chat box
When ChatGPT arrived, it answered questions. That was the whole product. You typed, it typed back.
Then OpenAI put the same models behind an API, and a wave of apps showed up overnight. Copywriting tools, email writers, SEO blog generators, resume fixers. Most of them were a prompt, a text box and a Stripe checkout. People called them "wrappers", and a lot of them made real money for a while.
Image generation came next, then voice, then video. Each one was a new API, and each one created a new wave of apps built on top of it.
But all of these apps shared one limit. The AI could write the email. It couldn't send it.
Mid-2023: the model learns to ask for tools
The first crack in that limit was function calling. OpenAI added it to its API in June 2023: instead of only returning text, the model could return "please call get_weather with city=Jaipur". Your code ran the function and passed the result back.
That small change is the root of everything that followed. The model still couldn't do anything by itself. But it could now say, in a structured way, which API it wanted called.
2024–2025: Claude, Claude Code and agents that do the job
Then the models got good enough to chain those calls without a human in between. Ask, plan, call a tool, read the result, call another tool, keep going until the job is done.
Claude Code is the cleanest example. You don't ask it how to fix a bug. It opens the files, runs the tests, edits the code and runs the tests again. It's an agent that doesn't answer, it works. I broke down the loop behind that in agent harnessing. The core is about 20 lines. The hard part is everything around it.
Notice what Claude Code actually does all day: it calls tools. Read a file. Run a command. Search. Edit. Every action is a tool with a defined input and output. That's an API, even when it's local.
AI moves into the real economy
The same pattern then spread far beyond software. Logistics companies wired models into route planning and warehouse systems. Robotics teams connected models to robot control software. Electronics and manufacturing teams used them to read sensor data and trigger machines. Automation tools added AI steps to every workflow.
In every one of those industries, the model's value depends on one question: can it reach the system that does the work? A model that understands a shipping delay but can't update the shipment is a very expensive chatbot.
I saw a small version of this myself when I went to sell AI to old-industry businesses. The AI was never the hard part. Getting it into their tools was.
Browser agents: when there's no API, use the screen
Some systems have no API at all. Old government portals, supplier dashboards, utility bill pages. So a new category appeared: browser agents that click through websites the way a person would.
Open-source projects like browser-use and Stagehand let an agent drive a real browser. Integuru took a smarter route: it records the browser's network requests and writes integration code that calls the site's hidden internal API directly. That second approach says a lot. Even when a site has no public API, the fastest way to automate it is to find the API underneath.
Browser agents work, but they're slow and they break when a button moves. Every team that runs them at scale ends up wishing the site just had an API.
Workflow tools: n8n and friends
At the same time, workflow tools like n8n, Activepieces and Zapier added AI agent steps. Now a non-developer could build "when an email arrives, let AI read it, update the CRM and post in Slack".
Look inside any of those workflows and it's the same thing again. Each node is a wrapper around one app's API. n8n's main repo has about 300 node folders in it. Activepieces has around 740 "piece" folders, and every piece is also available as an MCP tool. A workflow tool is, at its core, a big collection of maintained API integrations with a nice UI on top.
2024: MCP, and every app needs an adapter
Then Anthropic released the Model Context Protocol in November 2024. MCP is a standard way for any AI app to discover and call tools from any server. Write an MCP server once, and Claude, Cursor, ChatGPT and every other MCP client can use it.
MCP spread fast because it solved a real mess: before it, every AI app had its own plugin format. Now companies ship their own official MCP servers. GitHub, Cloudflare, Stripe and Supabase all have one.
But here's the part people miss. An MCP server doesn't replace an API. It wraps one. Almost every MCP server is a thin layer that turns "the agent wants to create an issue" into a call to the GitHub REST API. No API underneath, no MCP server on top.
The common thread
Put the whole timeline side by side:
| Era | What the AI does | What it needs |
|---|---|---|
| Chat (2023) | Writes text | The model's API |
| Wrapper apps | Writes copy, images, voice | Model APIs |
| Function calling | Asks for a function | Your APIs |
| Coding agents | Edits, runs, ships | Tool APIs (files, shell, git) |
| Industry AI | Plans routes, runs machines | Logistics, robotics and ERP APIs |
| Browser agents | Clicks websites | The site's hidden API, or a screen |
| Workflows | Moves data between apps | One API per app |
| MCP | Uses any tool in any client | An API under every server |
Every step is the same move: a smarter model, reaching for an API. When you look at how agent products get built and launched, from bots that reply on X to research agents, it's the same recipe under the hood. A model, a loop, and API access to the systems that matter.
Part 2: Why APIs are becoming the next big demand
Agents are a new kind of customer
Your website used to have one kind of visitor: a human looking at a screen. Now it has a second one that reads, calls and acts. I explained that through a sweet shop in the WebMCP post. The short version is that a business without an agent-friendly API is invisible to that second customer.
Most of the web isn't ready. When Cloudflare measured the top 200,000 domains for its Agent Readiness score, about 3.9% served Markdown when an agent asked for it, and fewer than 15 sites published MCP Server Cards or API catalogs. That gap is the opportunity. I covered how to check your own site in AI visibility checkers.
Every agent hits the same three walls
If you've built an agent that touches real user data, you've hit these:
- Auth. The agent needs to act as a specific user in Gmail, HubSpot, Slack and Notion. That means OAuth apps, consent screens, token storage, refresh tokens that expire, and per-user scoping. For one app it's a weekend. For fifty apps it's a team.
- Integration upkeep. APIs change, deprecate endpoints and rate-limit you. Every integration you write is one you maintain forever.
- Context limits. Give a model 500 tools and it gets confused and slow. You need search and routing so it only sees the 5 tools that matter for this request.
These three walls are why a whole category of companies exists. They sell API access for agents: managed auth, maintained integrations and smart tool discovery. Composio and Nango are the two names most developers hear first.
The cost nobody budgets for
Every one of these calls costs something: the model tokens to decide, the platform's per-call or per-connection fee, and the upstream API's own limits. I learned this running our own agents. The agent itself is rarely the expensive part, as I wrote in what our B2B agents actually cost. It's the scraping, the context and the integrations around it.
That's why picking the right integration platform is now a pricing decision, not just a technical one.
Part 3: The landscape, mapped
I sorted every tool I found into six groups, because "Composio alternative" covers very different things:
- Agent integration platforms. Managed auth plus prebuilt tools, built for agents. Composio, Arcade, Klavis, ACI.dev, Pica.
- Product integration platforms. Built for SaaS products that need integrations, now used for agents too. Nango, Pipedream Connect, Ampersand, StackOne, Paragon, Merge.
- Workflow automation with MCP. n8n, Activepieces, Zapier MCP.
- MCP gateways and registries. One endpoint in front of many MCP servers, with governance. IBM ContextForge, Docker MCP Gateway, Microsoft MCP Gateway, 1MCP, MetaMCP, Speakeasy Gram.
- Builders and generators. Make your own API agent-ready. FastMCP, mcp-use, Arcade MCP, openapi-mcp-generator, UTCP.
- No-API fallbacks. When there's no API to wrap. browser-use, Stagehand, Integuru.
How I checked these
Every GitHub repo in the tables below was cloned and checked on 17 October 2026. "Last commit" is the date of the most recent commit on the main branch. "License" is read from the repo's own license file. Integration counts come either from the repo itself (counting connector folders or provider entries) or from the project's README, and the table says which. Pricing pages change often, so instead of copying numbers that will be stale next month, each row links to the vendor's pricing page and describes the pricing model.
Part 4: Composio vs Nango, the two names everyone compares
Composio
Composio gives agents what its README calls 1,000+ pre-authenticated toolkits, plus per-user sessions, auth, triggers and a sandbox.
The developer experience is very short. You create a session for one of your users, ask it for tools, and hand those tools to your agent framework (OpenAI Agents, Claude Agent SDK, Vercel AI SDK, LangChain and others):
const composio = new Composio({ provider: new OpenAIAgentsProvider() });
const session = await composio.create("user_123");
const tools = await session.tools();- What's open source: the SDK monorepo (TypeScript, Python and a CLI) is MIT licensed and very active. The platform that stores tokens and runs the tools is Composio's hosted service.
- Best for: agent-first products where you want hundreds of apps working this week and don't want to touch OAuth.
- Watch out for: usage-based pricing on a hosted service, so every action your agents take depends on Composio being up. Composio changed its pricing in 2026, and Scalekit wrote up what changed. Check the current pricing page against your expected call volume.
Nango
Nango describes itself as an open-source platform for building product integrations, with support for 1,000+ APIs. I counted 1,058 provider entries in its providers.yaml file.
Nango gives you three building blocks:
- Auth: managed OAuth, API keys and token refresh, with an embeddable white-label connect UI.
- Proxy: authenticated requests on behalf of your users, with retries and rate-limit handling.
- Functions: integration logic written as TypeScript functions and deployed to Nango's runtime, which it says you can generate with an AI builder.
Its README says it's used in production by Replit, Ramp and Mercor.
- What's open source: the code is public under the Elastic License 2.0. That's source-available, not OSI open source: you can self-host and modify it, but you can't offer it as a competing hosted service.
- Best for: SaaS products that need deep, customisable integrations (sync data, write back, webhooks) and want to own the integration code.
- Watch out for: more work than Composio for a quick agent demo, since you write or generate functions instead of getting ready-made tools. Pricing is on nango.dev/pricing.
The one-line difference
Composio gives your agent tools. Nango gives your product integrations. Composio is faster for "my agent should use Gmail". Nango is better for "my product needs a reliable, customisable HubSpot sync, and an agent will use it too". Both vendors publish their own comparison posts (Nango's Composio alternatives, Composio's Nango alternatives), and both are, naturally, a little biased.
Part 5: The full comparison tables
Agent integration platforms
| Tool | GitHub | License | Last commit | Integrations | Self-host | Pricing model |
|---|---|---|---|---|---|---|
| Composio | ComposioHQ/composio | MIT (SDK) | 2026-10-16 | 1,000+ toolkits (README) | No, hosted platform | Hosted, usage-based · pricing |
| Arcade | ArcadeAI/arcade-mcp | MIT (framework) | 2026-10-15 | 7,500+ tools across 81 MCP servers (README) | Framework yes, auth service is Arcade Cloud | Hosted · pricing |
| Klavis AI | Klavis-AI/klavis | Apache 2.0 | 2026-06-01 | ~100 MCP servers in repo | Yes, Docker images per server | Free to self-host; hosted version · klavis.ai |
| ACI.dev | aipotheosis-labs/aci | Apache 2.0 | 2026-05-28 | 600+ (README) | Yes, fully open source | Free to self-host; managed service · aci.dev |
| Pica | picahq/pica | GPL (community edition) | 2026-08-19 | 200+ integrations, 25,000+ actions (README, cloud) | Community edition no longer maintained | Hosted only now · picaos.com |
A few notes from reading the code:
- Arcade has the clearest security model of the group. A tool declares the OAuth scopes it needs, and Arcade injects the token at call time, so the client and the LLM never see it. The
arcade evalscommand tests tool-call accuracy against real models. - Klavis ships "Strata", which tackles the too-many-tools problem by letting the agent discover tools step by step instead of loading them all at once.
- ACI.dev is the most fully open option here, with backend, portal and integrations all under Apache 2.0. Its commits slowed after May 2026, so check its activity before you bet a product on it.
- Pica is a warning sign worth noticing. Its README says the open community edition is no longer maintained and the product moved to a private cloud platform. Open-core projects can close up.
Product integration platforms (now used by agents)
| Tool | GitHub | License | Last commit | Integrations | Self-host | Pricing model |
|---|---|---|---|---|---|---|
| Nango | NangoHQ/nango | Elastic License 2.0 | 2026-10-16 | 1,058 providers (counted in providers.yaml) | Yes | Cloud plans, or self-host · pricing |
| Pipedream Connect | PipedreamHQ/pipedream | MIT (components) | 2026-10-16 | 3,401 component folders (counted) | Components yes, platform hosted | Free for individual developers within limits; paid plans · pricing |
| Ampersand | amp-labs/connectors | MIT (Go library) | 2026-10-15 | 148 providers (counted) | Library yes, platform hosted | Free to start · withampersand.com |
| StackOne | StackOneHQ/stackone-ai-node | Apache 2.0 (SDK) | 2026-10-10 | Hundreds of tools via MCP (README) | No, hosted | See site · stackone.com |
| Paragon ActionKit | Closed source | n/a | n/a | Not checked | No | See site · useparagon.com |
| Merge (Agent Handler) | merge-api/merge-mcp (small MCP repo) | No license file | 2025-04-30 | Unified APIs by category | No | See site · merge.dev |
- Pipedream is the quiet giant. Its public repo holds the code for every prebuilt component, more than 3,000 app folders. Its README says there are no fees for individual developers, within limits.
- Ampersand is built for deep, bidirectional SaaS sync (Salesforce, HubSpot) defined in a YAML manifest. It's a good fit if your agent lives inside a B2B product.
- StackOne leans on search: the agent finds an action in natural language and executes it by ID, so a large catalog never has to fit in the model's context.
- Paragon and Merge are enterprise-focused and closed. I couldn't verify their catalogs from code, so they're listed for completeness only.
Workflow automation with MCP
| Tool | GitHub | License | Last commit | Integrations | Self-host | Pricing model |
|---|---|---|---|---|---|---|
| n8n | n8n-io/n8n | Sustainable Use License | 2026-10-16 | ~300 node folders (counted) | Yes | Self-host under its license terms; cloud plans · n8n.io |
| Activepieces | activepieces/activepieces | MIT | 2026-10-16 | ~740 piece folders (counted), all usable as MCP | Yes | Free to self-host (MIT); cloud plans · activepieces.com |
| Zapier MCP | zapier/zapier-mcp (plugin) | MIT (plugin) | 2026-07-29 | 9,000+ apps (README) | No | Uses your Zapier plan · zapier.com |
The cheapest serious option for a solo founder is probably Activepieces self-hosted. It's MIT licensed, every piece doubles as an MCP tool, and its README says about 60% of pieces come from the community. n8n is more popular, but its Sustainable Use License limits how you can use it commercially, so read it before you build a product on it. Zapier MCP has by far the biggest catalog, and you pay Zapier for every task.
MCP gateways and registries
These don't give you integrations. They sit in front of many MCP servers and add one endpoint, auth, governance and logging. You need one once you have more than a handful of servers.
| Tool | GitHub | License | Last commit | What it does |
|---|---|---|---|---|
| IBM ContextForge | IBM/mcp-context-forge | Apache 2.0 | 2026-10-16 | Registry and proxy that federates MCP, A2A and REST/gRPC APIs, turns REST into MCP, 40+ plugins |
| Docker MCP Gateway | docker/mcp-gateway | MIT | 2026-09-16 | Runs each MCP server in its own container behind one gateway, with secrets kept out of env vars |
| Microsoft MCP Gateway | microsoft/mcp-gateway | MIT | 2026-10-13 | Reverse proxy with routing, authorization and lifecycle management, with an Azure deploy |
| 1MCP | 1mcp-app/agent | Apache 2.0 | 2026-10-15 | Aggregates your MCP servers into one runtime, with step-by-step tool discovery for agents |
| MCP Gateway & Registry | agentic-community/mcp-gateway-registry | Apache 2.0 | 2026-10-15 | Governed registry for MCP servers, agents and skills, with natural-language search |
| MetaMCP | metatool-ai/metamcp | MIT | 2026-06-23 | Aggregator and middleware for MCP servers |
| Speakeasy Gram | speakeasy-api/gram | AGPL-3.0 | 2026-10-16 | Company-wide AI control plane: MCP distribution, permissions, threat detection, cost tracking |
| Smithery CLI | smithery-ai/cli | AGPL-3.0 | 2026-05-31 | CLI for the Smithery MCP registry |
Builders: make your own API agent-ready
If you run a SaaS, this is the group that matters most. Agents will come to your product, and these tools help you meet them.
| Tool | GitHub | License | Last commit | What it does |
|---|---|---|---|---|
| FastMCP | jlowin/fastmcp | Apache 2.0 | 2026-10-16 | The popular Python framework for writing MCP servers |
| mcp-use | mcp-use/mcp-use | MIT | 2026-10-14 | Typed MCP servers and clients, with an inspector and MCP Apps support |
| Arcade MCP | ArcadeAI/arcade-mcp | MIT | 2026-10-15 | Python MCP framework with built-in authorized tool calling |
| openapi-mcp-generator | harsha-iiiv/openapi-mcp-generator | MIT | 2026-09-26 | Turns an OpenAPI 3 spec into a typed MCP server that proxies your REST API |
| UTCP | universal-tool-calling-protocol/python-utcp | MPL-2.0 | 2026-09-16 | An alternative protocol that calls tools over HTTP, CLI and more directly, without a server in between |
| MCP reference servers | modelcontextprotocol/servers | MIT / Apache | 2026-10-11 | Official reference implementations to learn from |
The quickest win for most SaaS founders: if you already have an OpenAPI spec, openapi-mcp-generator gets you an MCP server in an afternoon. Then list it in a registry so agents can find it.
No-API fallbacks
| Tool | GitHub | License | Last commit | Approach |
|---|---|---|---|---|
| browser-use | browser-use/browser-use | MIT | 2026-10-16 | Lets an agent drive a real browser |
| Stagehand | browserbase/stagehand | MIT | 2026-10-15 | Browser automation with natural-language actions |
| Integuru | Integuru-AI/Integuru | AGPL-3.0 | 2026-05-25 | Reverse-engineers a site's internal API from network requests and writes code for it |
Scraping is its own deep topic. I wrote about the API side in one Hono file for an entire web scraping API.
The graveyard: projects that stopped
Two projects are worth knowing about precisely because they stopped:
- Agentic, pitched as "RapidAPI for LLM tools", was archived by its author in February 2026.
- Supaglue, an early open-source unified API, hasn't had a commit since February 2024.
The lesson: in this market, check the last commit date before the star count. A popular repo that stopped six months ago is a migration you'll do later.
Part 6: How to compare pricing without getting surprised
Exact prices change too often to be worth copying into a blog post. The pricing model is what decides your bill, and it barely changes. Here's what to look at:
- Per tool call or execution. Cheap for low-volume agents, and it scales linearly with usage. Ask what counts as a call: does a retry count? Does a failed call count?
- Per connected account. Common in product integration platforms. Predictable per customer, but it adds up if each user connects five apps.
- Per task or workflow run. Zapier-style. Easy to understand, and expensive when an agent loops.
- Seats and plans. Enterprise platforms often charge a platform fee plus seats, whatever the usage.
- Self-hosted. Activepieces, ACI.dev and Klavis cost nothing in licence fees, and n8n can be self-hosted within its license terms. You pay for the server, the database, backups and your own time maintaining OAuth apps for every provider.
The hidden cost on every platform is the upstream API itself. Some APIs need paid plans for API access at all, and some have strict rate limits. A platform can't make HubSpot's limits go away.
A quick decision guide
- "I want my agent using Gmail, Slack and Notion by Friday." Composio or Arcade.
- "My SaaS needs reliable two-way sync with customers' CRMs." Nango, Ampersand or Pipedream Connect.
- "I'm bootstrapped and want to self-host everything." Activepieces, ACI.dev or Klavis.
- "I have 20 MCP servers and no idea who uses what." IBM ContextForge, Docker MCP Gateway or MCP Gateway & Registry.
- "Agents should be able to use my product." FastMCP or openapi-mcp-generator, plus a clean public API.
- "The site I need has no API." Integuru first, browser-use or Stagehand as the fallback.
If you're running agents in production, also read the AI agent sandbox companies and agent auditing and compliance. An agent that can call any API is also an agent that can call the wrong one.
Part 7: What this means if you're building
The pattern from 2023 to today is simple. Models keep getting better, and the bottleneck keeps moving to access. Whoever controls clean, reliable, well-documented API access to a system becomes the way agents reach it.
That creates three opportunities:
- If you run a SaaS, your API is now a sales channel. Agents choose tools they can use. A public API, an OpenAPI spec and an MCP server are the new "listed on the app store".
- If you build agents, integrations are your moat and your biggest cost. Pick the platform by pricing model and lock-in, not just catalog size.
- If you're looking for a business, every vertical without good APIs is a gap. Logistics, manufacturing, local services and government portals are full of systems agents can't reach yet. Someone will build the API layer for each of them.
I'm building in this space myself. If you want the next deep-dive, comparisons like this land in the monthly magazine first, and the full article index has everything else on agents.