The world has too many platforms.
Every startup wants to be a platform. Every open source project dreams of becoming one. The pattern is seductive: build something useful, then build a platform around it, then build an ecosystem around the platform. Platform companies get network effects, winner-take-all dynamics, exponential growth curves.
The reality is that most platforms shouldn’t exist. They all too often tend towards solutions looking for problems, abstractions built before anyone understood what needed abstracting—ask me how I know. Platform should never be the goal—solving real problems should be.
So why is Toolcog a platform?
The library instinct
Our core stack would make an excellent library. JSON Schema parsing, validation, type generation, tree-shaking—all in under 5MB with zero external dependencies. OpenAPI parsing, request construction, parameter encoding—clean interfaces, comprehensive coverage. These are library-shaped problems with library-shaped solutions.
If we’d shipped the schema infrastructure as a library, it would be useful. Developers could validate schemas, generate types, process specs. The code quality is there. The abstractions are clean.
But it wouldn’t solve the actual problem. The actual problem isn’t parsing schemas or generating types. It’s connecting AI to APIs at scale, with discovery, security, and no per-API integration work.
What doesn’t fit in a library
Libraries run in your process. That’s their strength and their limitation.
Vector search. Our standard catalog indexes over 100,000 operations across hundreds of APIs. Semantic search requires embedding vectors, similarity indices, ranking algorithms. This isn’t something you bundle into a library—it’s infrastructure.
Spec ingestion. OpenAPI specs exist across the web, in repositories, behind authentication. We crawl, parse, validate, transform, and index them continuously. A library could process specs you give it. A platform can maintain the catalog.
Credential management. The security architecture requires envelope encryption with keys derived from user sessions. The decryption happens in controlled infrastructure that doesn’t have access to its own keys. You can’t ship that model as a library.
Each capability that differentiates Toolcog from “just another OpenAPI tool” requires platform-level infrastructure. Discovery, security, coverage—these are service problems, not code problems.
The MCP ecosystem
MCP (Model Context Protocol) standardizes how AI connects to tools. It’s well-designed, actively developed, and gaining adoption. We built on it.
But MCP is a protocol, not a platform. It defines how connections work, not how to make them happen.
To use MCP with a specific service, someone needs to run an MCP server for that service. That server handles authentication, manages state, translates between MCP and the underlying API. For GitHub, a GitHub server. For Stripe, a Stripe server. For each service, another server.
The ecosystem has responded with open source servers for popular services. But many are weekend projects—unmaintained, incomplete, sometimes broken. The protocol is elegant; the ecosystem is still in its infancy.
Zero integration
Toolcog eliminates that friction. Add one MCP URL—mcp.toolcog.com—and you get access to every API we’ve indexed. No servers to deploy. No integrations to maintain. No per-service work.
This is only possible as a platform. The value isn’t in the code (though the code is good). The value is in the index, the credentials, the infrastructure that makes discovery instant and integration unnecessary.
A library would require you to build all of that yourself. The library would be a tool; the platform is the solution.
Platform as last resort
I’m not advocating for platforms. Most of the time, a library is better. Libraries compose. Libraries don’t require ongoing relationships. Libraries let you keep control.
Platforms should be last resorts—built only when the problem genuinely can’t be solved otherwise.
For Toolcog, the platform emerged from constraint, not ambition. We tried to build something smaller. The problem pushed back. Discovery requires infrastructure. Security requires architecture. Coverage requires operational investment.
The platform exists because the problem demanded it, not because we wanted to build a platform.
The honest position
If you want to run your own vector infrastructure, ingest your own specs, manage your own credential encryption—you can. Everything we built could theoretically be self-hosted. The code isn’t the moat.
What we’re offering is that you don’t have to. The infrastructure exists. The catalog is maintained. The security is architected. You can focus on what you’re actually trying to build.
That’s the honest pitch for any platform: we did the work so you don’t have to. Whether that’s valuable depends on what the work is and whether you’d want to do it yourself.
For connecting AI to every API, the work is substantial. The platform is the solution to that work existing.