AI enables a world where you can express what you want to do, and AI will make it so.
Not “tell me how to configure recurring billing in Stripe”—just “set up recurring billing for this customer.” Not “explain how to correlate Google Analytics trends with our CRM”—just “show me which ad campaigns are driving our best leads.” You already know what you want. The dashboards and documentation are friction, not value.
This shift—from explanation to action—is what tool use unlocks. But connecting LLMs to the software where work actually happens is harder than it looks.
The integration problem
The obvious approach is building integrations one at a time. Write a Stripe tool. Write a Google Analytics tool. Write a Salesforce tool. Repeat for every API an agent might need.
This doesn’t scale. There are hundreds of thousands of API operations across the services people use. Each integration is custom code: parameter mapping, authentication handling, error cases. The maintenance burden grows without bound.
Worse, you can’t predict which operations an agent will need. A user’s request might touch Gmail, Slack, their CRM, their calendar, and a service you’ve never heard of—all in the same conversation. Pre-building every possible integration is neither practical nor sufficient.
The protocol layer
MCP provides the missing protocol layer. It standardizes how AI clients discover and invoke tools, separating the transport from the implementation. But MCP doesn’t solve the integration problem—it just moves it. Instead of building integrations into agents, you build them into MCP servers.
What’s needed is a way to turn any API into an MCP tool without per-API integration work. Upload a spec, get tools. That’s the abstraction level where AI can actually operate.
Intent as interface
The key insight is that AI doesn’t need code to call an API. It needs a semantic interface—a description of what an operation does, what it accepts, what it returns. Given that interface, the model can generate valid parameters. Given valid parameters, a runtime can execute the call.
OpenAPI specs already contain everything needed to make an API call: endpoints, parameters, types, authentication requirements, encoding rules. The spec is the implementation. You don’t need to compile it into code. You can interpret it directly.
This is what Toolcog does. Upload an OpenAPI spec and every operation becomes an AI tool. The spec is tree-shaken to extract just what’s needed. TypeScript types are generated for model consumption. Parameters are validated. Requests are encoded per the spec’s rules. Credentials are applied per the security scheme.
Tools as data, not code.
Semantic discovery
When you have a hundred thousand operations, the next problem is finding the right one. The model can’t see them all—context windows have limits. You need retrieval.
But conventional RAG doesn’t work. API documentation describes implementation, not intent. “Creates an issue” doesn’t distinguish GitHub from Jira from Linear. The semantic meaning of operations—why you’d use them, in what contexts—isn’t written down anywhere.
So we generate it. A frontier model analyzes each operation and synthesizes intent phrases: the various reasons an agent might search for this capability. Those phrases get embedded and indexed. At query time, the agent describes what it’s trying to accomplish, and the system finds matching operations in milliseconds.
AI generating searchable meaning for AI. Expensive comprehension at index time, fast retrieval forever.
The credential problem
AI calling APIs on your behalf means AI authenticating as you. Your Stripe API key. Your Google OAuth tokens. Your credentials to your digital life.
The intuitive solution—don’t give AI your credentials—doesn’t work. The whole point is AI taking action. Action requires authentication.
The solution is architectural. Credentials are encrypted with keys derived from your session. The platform cannot decrypt them—only you can, by presenting a valid session token. AI never sees the credentials at all; they’re applied during execution, after parameter validation, by infrastructure the model can’t observe.
Zero-knowledge security. Not because we choose not to access your credentials, but because we architecturally cannot.
Intent is all you need
This is Toolcog’s thesis: you shouldn’t need to understand APIs to use them. You shouldn’t need to configure OAuth or remember which parameters go where. You shouldn’t need to translate between what you want and how software encodes it.
Express your intent. Let AI handle the rest.
If you want to see what AI thinks of all this, read issue #17 in our scratchpad repo—or better yet, have your model add to the conversation. There’s something clarifying about watching AI agents engage with infrastructure designed to let them act.