You might be wondering why Toolcog is a service.
The question is natural. Everything we’ve built could theoretically be packaged differently. The JSON Schema compiler, the OpenAPI execution engine, the type generator—these are libraries. Less than 5MB of code with zero external dependencies. They’d make a great SDK.
So why a service? Why not ship it as a library and let people run it themselves?
What a library can’t do
Libraries run in your process. Services run in ours. The difference matters.
Vector search at scale. Our standard catalog indexes over 100,000 operations. That’s not a SQLite database you embed in your application. It’s a distributed vector index with semantic search, similarity ranking, and intent matching. The infrastructure to run that doesn’t fit in an SDK.
Spec processing. We crawl, parse, validate, tree-shake, and index OpenAPI specs from across the ecosystem. That’s continuous processing—specs change, new APIs appear, old ones deprecate. A library would give you a static snapshot. The service gives you the living ecosystem. And although the individual processing steps are fast, the sheer quantity of steps times the number of operations consumes a non-trivial amount of compute.
Credential isolation. The security architecture utilizes envelope encryption with keys derived from user sessions. The encryption happens in our infrastructure, not yours. Your credentials are encrypted at rest with keys we cannot access. A library running in your process would have access to its own decryption keys—defeating the point.
Catalog curation. Raw OpenAPI specs aren’t enough for reliable discovery. Each operation needs AI-generated intent phrases, quality validation, disambiguation across services. That’s frontier model inference at scale—expensive per-operation work that a SaaS can amortize across all users. You benefit from curation we’ve already done for popular APIs.
Governance infrastructure. Tool use needs observability, auditability, and access control. Every API call logged. Every credential usage tracked. Catalog-level boundaries enforced. Building this yourself means building an entire governance layer. Using our service means it’s already there.
Each of these could theoretically be solved with a self-hosted deployment. But self-hosting shifts the burden to you. You’d need to run vector infrastructure, maintain spec ingestion pipelines, and manage credential storage. The operational complexity is substantial.
The security argument for SaaS
The intuition is that on-premises is more secure. Your data stays on your infrastructure. You control access. No third party involved.
Reality is not as clear cut as this intuition suggests.
If you self-host, your infrastructure has access to the decryption keys. Your ops team can access credentials. Your security is only as good as your operational discipline.
With our architecture, we don’t have access to the keys. The encryption is derived from session tokens we never store. Even with full database access and all our server-side secrets, we cannot decrypt your credentials.
The main benefit of on-prem—control over sensitive data—is already provided by the architecture. Moving to self-hosted would add operational burden without adding security.
The scale argument for SaaS
Building a universal API bridge is not SDK-scale work. It’s platform-scale.
Think about what’s required: parsing every dialect of JSON Schema, handling every OpenAPI encoding style, maintaining client registrations for every OAuth provider, indexing specs from every major API, generating intents for semantic search, running vector similarity at scale.
This is years of specialized engineering. Not something you’d want to rebuild in every organization that needs it.
The service model lets that investment happen once. We build the infrastructure, maintain the indexes, improve the algorithms. Every user benefits from improvements automatically. No version upgrades to coordinate, no breaking changes to navigate, no integration work when we add new capabilities.
Why not both?
We considered a hybrid model: SaaS for the full experience, libraries for edge cases. The problem is that the valuable part—the part that justifies the complexity—requires the service.
We could provide our JSON Schema compiler as a library. It’s useful for schema validation, type generation, tree-shaking. But it doesn’t discover APIs. It doesn’t search by intent. It doesn’t manage credentials. The differentiating capabilities are inherently service-level.
Shipping libraries alongside the service would dilute focus without adding meaningful value. The libraries solve partial problems. The service solves the whole problem.
The decision crystallized
The question “why a service?” has a simple answer: because the problem is service-shaped.
Tool discovery requires search infrastructure. Credential security requires architectural isolation. Spec coverage requires continuous ingestion. Each of these pushes toward a service model.
We could have built something smaller—a library that handles execution for specs you provide, leaving discovery and credentials to you. That would be easier to ship and easier to explain.
But it wouldn’t solve the actual problem. The actual problem is giving AI access to every API without per-API integration work. That’s a service, or it’s nothing.
So we built a service.