The Capability Layer: Thousands and Thousands of Connectors and the End of Custom Integrations

For twenty years, the unit of integration work was the endpoint. You had a URL, a verb, a wire format, a rate limit, and an OAuth flow, and you wrote glue code to hold it all together. The unit is changing. It is the capability: one thing an agent can do to one system. "Send the invoice" is a capability. "Refund the last order" is a capability. "Pull the open tickets" is a capability. The endpoint is an implementation detail underneath it.

That is why Vinkius ships a catalog of capabilities rather than a catalog of API wrappers. Today the catalog holds thousands and thousands of managed connectors and 61,738 capabilities, and the number that matters is not the number of connectors. It is that each capability is a unit you can host, version, authorize, meter, and audit, the same way you would audit any other service in the stack.

This post is an anatomy of that layer. What a capability actually is, how one request flows through it, the five ways a capability gets shipped, and the plan math and security model underneath. No marketing math: every figure in here is what the product ships.

The naming is not accidental. In the product, you do not search for connectors; you search for "AI Capabilities." The catalog, the search bar, and the upgrade pitch all speak in the same unit. When a vendor sells a layer of the agent era, the unit of sale tells you what they believe they are selling. Vinkius sells actions, not endpoints.

The unit of work is no longer the endpoint

An agent does not send an HTTP request to a service. It sends intent. In the Vinkius execution model the intent has exactly three fields. The capability, which is the action to complete. The input, which is the data the action needs. And the identity, which is the user authorizing the action. Everything else, authentication, permissions, mapping to the right operation, retrying on a transient failure, belongs to the platform, not to the agent.

Then four stages run. Authenticate connects the correct user account. Authorize enforces the permissions for the requested action. Resolve maps the capability to the correct system operation. Execute runs the operation, retries it when it should, and records what happened. The result comes back structured: a status, a normalized output, and a trace.

Notice what the model never sees. The wire protocol. The retry policy. The permission check. It asked for an outcome and got an outcome.

That is where most of the industry is still stuck. Models are better at taking an outcome and reasoning about it than at babysitting a fetch call. The capability layer is the place where intent stops being a prompt and becomes a transaction.

One more part of the anatomy matters if you run fleets of agents: who is acting. Every capability call carries an identity, and the identity is a user, not the model. The product is built around that fact. You can build one application for an unlimited number of end users, and each user's connections and credentials stay fully isolated from every other user's and from the platform itself. The agent is the hand. The identity is who the hand belongs to.

What the catalog ships

The numbers first, because they anchor everything. Thousands and thousands of connectors. 61,738 capabilities. Most of the connectors are official, published and maintained by Vinkius, and the community share is published by its owners. A growing number of listings carry the new marker. The site's own counter is generated from the catalog data, not a marketing constant someone retypes every quarter, which is the difference between a number you can quote to a board and a number that flatters you.

Grades are part of the surface. The official connectors carry an A+, and the community listings carry letter grades that go all the way down to F, so the grader is not decorative. I have watched vendors publish quality scores that nobody can reproduce. Ours sit in the catalog data next to each listing, which is where you want them.

Publishing is the other side of the ledger. The official listings are maintained by Vinkius, and the community listings are maintained by their publishers. The distinction matters for one reason. Official means Vinkius is on the hook. For a community listing, the publisher is on the hook. Both go through the same verification pipeline and land in the same search, and the trust badge is a liability marker, not a category.

What managed actually means is the boring part. Vinkius hosts the connector, maintains it, updates it, and runs the authentication. When OpenAI or Salesforce changes an endpoint, that is our job, not yours. Every connector in the catalog lands as a verified surface: production ready, with the guarantees that go with that label. The control plane says it in one line, MCP VERIFIED, PRODUCTION READY, VINKIUS GUARANTEED, and a single click activates the connector in your account.

Hosting somebody else's connector is a liability you absorb. When a third party deprecates a tool, the fix lands in the connector, not in your app. The catalog is where that liability sits, and where your maintenance bill ends.

The breadth shows up in the name list. OpenAI, Anthropic, Stripe, GitHub, Slack, Salesforce, Tesla, PayPal, Plaid, Datadog, Jira, Shopify, plus the long tail: Idealista, Semrush, ElevenLabs, Hugging Face. The catalog page reduces the whole thing to one sentence. One connection, every tool your agent can call.

Two ways to browse

There are two shelves, and they answer different questions. The first is editorial: twelve hand-curated categories, Industry Titans, Superpower, Loved by Developers, AI Frontier, The Unthinkable, Money Moves, Ship It, Talk to Me, Growth Engine, Brain Trust, Fort Knox, and Friends of MCP. Those are taste judgments. They are the answer to the question, "show me what is worth my time."

The second is organic: twenty-two categories populated automatically from the manifests, from Productivity and Developer Tools down to long-tail verticals like Legal, Healthcare, Travel and Hospitality, and Real Estate. They are the answer to the question, "what can I actually plug in for this team, right now."

You do not have to pick a shelf in the product. Discovery, Explore, Favorites, Activated, and Library sit side by side, and the catalog search is the same search an agent uses when it is looking for a tool mid-task. Inside Explore, four tabs do the work: Top Curated, Newest, Top Tags, and Top Categories. Each is a different answer to the same question, which one of the thousands and thousands is the one I need.

The catalog also browses without an account. Discovery, tags, categories, and new arrivals are public, because the catalog is a discovery surface, and discovery should not sit behind a sign-in wall. Activation is where the account matters. One click, and the connector is live in your control plane. The search works on the job, not just the name: you describe what you need, and the catalog finds the capabilities that power it.

The five ways a capability arrives

A capability is a contract on top of the transport. Underneath it, one of five server types ships it.

The API server is the workhorse. It is a REST proxy: you point it at a base URL, and the surface turns any API into an MCP interface without you rebuilding the client side. If the vendor ships a spec, you import it, and the capability set appears.

The Agent Skills server is different on purpose. It exposes skill files the model reads on demand, in a pattern called progressive disclosure: the model sees what is available, then pulls the details only when it chooses that path. It is the shape of capability that fits codebases and knowledge bases where the full tool description would not fit in context.

The MCP Server Deploy server is your own code. You bundle it, ship it to the edge, and it runs inside the V8 isolate runtime that I wrote about in depth here. The runtime story is where the cost and latency numbers live.

The YAML server is the declarative one. A manifest in YAML, compiled at deploy time. It is the shape of capability that teams want in git, reviewed like infrastructure.

Authentication rides underneath all of it in four shapes. None, when the surface is public. Bearer, for token-based services. Basic, for the legacy corner. And a custom header, for the vendors who refuse to fit any of the other three. The point of the taxonomy is that the model does not see any of it. The model sees a capability; the transport, the auth shape, and the retry policy are the platform's problem.

From the user's side, authentication is not a wall. Each connector shows its state at a glance: setup required, connected, ready. No hidden login page, no "it should work." There is one more unit worth naming before the plan math: the capability set. Every connector ships its complete set, the exact actions your AI can choose when you ask it to work with that connector. The agent does not see the entire catalog at once; it sees the tools it actually has. That is not a product detail. It is how the catalog keeps the model's context honest.

The plan math

Capability access is plan-gated in one place only: the free tier. It runs a hundred requests per 30-day cycle, one connection token, two catalog installs, and its dashboards are labeled with sample data, so nobody mistakes a demo for a live system. From the paid tiers up, the catalog has no install cap, and the request ceilings are the real planning numbers: 5,000 per cycle on Lite, 25,000 on Starter, 100,000 on Pro, and 500,000 on Business.

The ceilings are not decoration. They are the metering layer. A capability that can refund an order is a capability that can run in a loop, and a loop that burns a thousand dollars a night is a governance problem before it is an engineering one. The product's own KPI, Cost Saved, measures the bytes a cost ceiling removes from the outbound path, so the number on the dashboard is a number you can defend in a budget meeting.

Past the ceiling, overage bills on a soft limit rather than hard-stopping the call, and that is deliberate. A hard stop in production is a support queue. A metered overage is a line item. That is the whole philosophy of the ceilings: they are numbers to plan against, not walls to hit.

Connection tokens climb the ladder: three on Lite and Starter, ten on Pro, twenty-five on Business. Activity history goes from three days on the entry paid tiers to seven on Pro and thirty on Business, and the audit trail on the top tier is the immutable one. That tier is where organizations live. Teams, roles, project scoping, service accounts and API key provisioning, SSO, a thirty-day immutable audit trail, instant token revocation, and a kill switch with circuit breaker.

The security layer your CISO will ask about

Each connector runs in its own sealed sandbox. Thirty-four rules or more are enforced on every request, and they cover memory limits, CPU limits, SSRF protection, private-network blocking, malicious-file protection, and credential isolation. Security events stream in real time to Datadog, Splunk, or a webhook. The audit trail is signed and chained, Ed25519 signatures over SHA-256 blocks, so a tampered record cannot be quietly dropped without the chain breaking.

Credential handling follows one rule. Scoped, user-controlled, revocable at any time, and the platform never trains on your data. The product's own FAQ says the second half out loud, so you can quote it back: "Vinkius never trains on your data, and you can revoke access at any time." End-user credentials are stored securely and never shown again after save, and each user's connections stay fully isolated from every other user's and from the platform. The deploy audit surface exports a PDF, which is the format a regulator or a board committee actually reads.

I have been asking vendors for years to write those two sentences on their page. The catalog writes them.

Why managed beats bolted on

Every custom integration is a promise you have to keep forever. The vendor changes a field. You rewrite the parser. The auth flow moves. You chase it. An integration nobody has looked at in a year is a liability wearing the costume of a feature. The catalog inverts the maintenance model. Hosting, authentication, execution, monitoring, updates: the platform does them, and a capability becomes one line in a manifest instead of a codebase of glue that someone has to babysit.

The math of that inversion is the argument. Say your stack needs a hundred connectors. A hundred custom integrations means a hundred maintenance promises, each one a parser that can rot, an auth flow that can break, a version that can change underneath you. A hundred catalog connectors mean a hundred maintained surfaces, and the maintenance cost sits on the platform side of the bill. That is the difference between buying a tool and owning one.

There is also a day one argument. Your AI application starts with thousands of connectors in the catalog, and that is a real difference from the team that spends its first quarter wiring the two integrations the demo needed. The catalog is the reason the first commit of an agent app can be the productive one.

The client side is the same shape. The catalog's surfaces speak MCP, which means the same connector works from ChatGPT, Claude, and Gemini, from Cursor, Cline, and VS Code, and from the Vercel AI SDK inside your own app. You maintain the capability set once, and every client that speaks the protocol can call it.

Where this sits

The catalog is the capability layer. The control plane is the rules of the calls: identity, on-path enforcement, bounded spend, secret isolation, a tamper-evident ledger, trace continuity, a human gate and an off-switch, and a measured overhead. I wrote the eight rules in the control plane post. The V8 isolate runtime has its own post. The catalog is where those rules have something to govern.

Three posts, one stack. The control plane post covers the rules of the calls. The V8 post covers where the code runs. This one covers the unit that makes the two worth writing. Without a catalog, the control plane governs nothing, and the isolate runtime has nothing to run. The catalog is the supply side of the agent economy. It decides which actions exist, who maintains them, what they cost, and what happens when they fail.

When an agent asks for the world, the capability layer is the door, and the control plane is the lock. The job of the catalog is to make the door wide enough that an agent never has to build one itself. The bar I will hold the catalog to, and any catalog claiming the same space: verified surfaces, grades you can reproduce, metering a finance team can defend, and an audit trail that cannot be quietly edited. Everything else is a directory, not a layer.