Token Fetch + Skill Beats MCP Abstraction: Why TapAuth Took a Different Path Than Composio
If you're building AI agents that talk to third-party APIs, you've probably run into the same wall everyone else has: authentication. Your agent needs to send emails through Gmail, create issues in GitHub, post to Slack — and every one of those providers wants an OAuth token before they'll cooperate.
There are two schools of thought on how to solve this. One says: wrap every API in an abstraction layer, give the agent a menu of "actions," and handle auth behind the scenes. That's the approach Composio and similar MCP-based platforms take. The other says: give the agent a valid token and let it talk to the API directly. That's what TapAuth does.
We think the second approach wins. Here's why.
Infrastructure vs. Platform
TapAuth is auth infrastructure. You make one API call, you get back a scoped OAuth token for the provider you need. Your agent takes that token and hits the provider's API directly. There's no middleware runtime sitting between your agent and Gmail, no proprietary action format to learn, no vendor-specific SDK you have to import.
Composio is a platform. It wraps hundreds of APIs into its own action system, translates your agent's intent into API calls on your behalf, and manages the auth as part of that bundle. It's batteries-included, and for some teams that's exactly what they want.
But there's a cost to that convenience. When your agent's API call goes through a middleman, you've added a dependency that touches every request. If Composio's wrapper for the Gmail API has a bug, or doesn't expose a parameter you need, or adds 200ms of latency to every call — you're stuck. You can't route around it without ripping out the integration.
With TapAuth, the only thing we touch is the token. Once your agent has it, we're out of the picture.
LLMs Already Know How to Call APIs
Here's something that gets lost in the tooling conversation: modern LLMs are already good at making API calls. GPT-4, Claude, Gemini — they've all been trained on massive amounts of API documentation. Give Claude a valid GitHub token and tell it to create an issue, and it'll construct the right HTTP request without needing a wrapper to translate for it.
The bottleneck for AI agents was never "how do I format this API call." It was "how do I get a valid token for this user's account without asking them to paste credentials into a prompt." That's the actual hard problem — OAuth flows with redirect URIs, token refresh, scope management, secure storage. TapAuth solves that problem specifically, and nothing else.
Action wrappers solve a problem that was already mostly solved. Auth infrastructure solves the problem that was actually blocking people.
The Abstraction Tax
Every abstraction layer has a tax. With Composio's action system, the taxes look like this:
- Latency. Your agent's request goes to Composio's servers, gets translated into the provider's API format, gets proxied to the provider, and the response comes back through the same chain. That's not free.
- Surface area for bugs. Composio maintains wrappers for hundreds of API endpoints. Each wrapper is a place where a translation error, a missing field, or a stale schema can cause failures that have nothing to do with your code or the provider's API.
- Lock-in. Your agent code is written against Composio's action definitions, not against the provider's API. Switching away means rewriting every integration, not just swapping out a token fetch.
TapAuth's "abstraction" is one function call that returns a token. If you want to stop using TapAuth tomorrow, you replace that one call with however else you want to get tokens. Your agent code — the part that actually talks to APIs — doesn't change at all.
Context Bloat: A Solvable Problem
One argument for action wrappers is that they reduce context. Instead of feeding your agent the entire Gmail API reference, you give it a concise list of Composio actions. That's a real benefit — context windows are finite, and stuffing 50 pages of API docs into a prompt is wasteful.
But there's a catch. Composio doesn't eliminate context — it substitutes it. Instead of learning the Gmail API, your agent (or your developer) learns the Composio action format. Instead of reading Google's docs, you're reading Composio's docs. The knowledge didn't go away; it just moved.
The approach we prefer: use skills. A skill is a lightweight tool definition that gives your agent just enough context about an API to use it correctly — the key endpoints, the right parameters, the gotchas. It's the same context reduction benefit, without requiring a runtime abstraction layer to sit between your agent and the API.
TapAuth supports skill registries and .well-known/skills for exactly this reason. Your agent gets the auth token from TapAuth and the API guidance from a skill definition. No middleman needed at runtime.
Context Windows Are Getting Bigger
There's also a timing argument here. When GPT-3 had a 4K token context window, aggressive context optimization made sense. You needed to be surgical about what went into the prompt. Today, Claude has 200K tokens. Gemini has a million. The trend is clearly toward larger windows, not smaller ones.
That means the pressure to hyper-optimize context with abstraction layers is easing. Meanwhile, the pressure for reliable, secure auth is increasing — because agents are doing more sensitive things with more providers, on behalf of more users. The investment that pays off long-term is in the auth layer, not in shrinking context by another 2K tokens.
The Middleman Problem Compounds
Here's a scenario that plays out regularly with any API wrapper service: Google updates the Gmail API. Maybe they add a new label type, change a rate limit response, or deprecate a parameter. Now what?
If your agent talks to Gmail directly, you update your code to handle the change. Straightforward.
If your agent goes through Composio, you wait. You wait for Composio to notice the change, update their wrapper, test it, and deploy it. If the change broke something in the wrapper, you file a support ticket and wait more. If you need a new parameter they haven't exposed yet, you're stuck until they prioritize it.
This is the middleman problem, and it compounds. The more providers you integrate with, the more often you're blocked by someone else's update cycle. With TapAuth, you're only dependent on us for the token. Everything after that is between your agent and the provider — no waiting on a third party to update an API wrapper.
MCP's Real Value Is Discovery, Not Runtime
We should be clear: MCP (Model Context Protocol) has real value. A standardized way to describe available tools and let agents discover them is genuinely useful. If you're building an agent that needs to figure out which APIs are available and what they can do, a tool registry helps.
But MCP's value is in the discovery and description layer — not in being a mandatory runtime abstraction that sits between your agent and every API call. You can get the discovery benefits without the runtime tax.
That's why TapAuth invests in discoverability — CLI tooling, skill registries, .well-known/skills — without requiring that every API call flow through an MCP server at runtime. Your agent discovers what's available through standardized descriptions, gets a token from TapAuth, and talks to the API directly. Best of both worlds.
Security Posture
Let's talk about the trust surface. With TapAuth, your agent gets a scoped token with a TTL (time to live), then talks directly to the provider. The data flows from the provider to your agent. TapAuth never sees the data itself — we handle the auth handshake and get out of the way.
With platforms that proxy API calls, your data flows through their servers. Every Gmail message your agent reads, every Slack message it sends, every GitHub issue it creates — all of it transits through the platform's infrastructure. That's a bigger trust surface. It's more data at rest on servers you don't control. It's another place where a breach could expose your users' information.
For teams building agents that handle sensitive data — and increasingly, that's most teams — the direct-to-provider model is a significantly smaller attack surface.
Where Composio Wins
Let's be fair. Composio does things well that TapAuth doesn't try to do. If you want a fully opinionated framework where someone else has decided the best way to interact with 200+ APIs, Composio provides that. If your team doesn't want to write any API integration code and prefers pre-built actions, their approach saves time upfront. They've invested heavily in breadth of integrations, and for teams that want batteries-included, that matters.
The trade-off is that convenience comes with the costs we described above. And we think the trend line favors the other direction: as LLMs get smarter and more capable of handling APIs directly, the value of action wrappers decreases while the value of reliable auth infrastructure increases.
The Bet
TapAuth is making a bet: that the future of AI agents is agents that are capable enough to talk to APIs on their own, and what they need from infrastructure is secure, reliable, scoped access to do so. Not training wheels. Not action menus. Just a valid token and clear documentation.
If you're building agents today and want to evaluate the difference, here's the quick version: TapAuth gives you the token, your agent handles the rest. One dependency for auth, zero dependencies at runtime. That's the architecture we think scales.