A camada de capacidades: milhares e milhares de conectores e o fim das integrações caseiras

Durante vinte anos, a unidade de trabalho em integração foi o endpoint. Você tinha uma URL, um verbo, um formato de transporte, um rate limit, um fluxo OAuth, e escrevia código cola para segurar tudo isso. A unidade está mudando. É a capacidade: uma coisa que um agente consegue fazer em um sistema. "Enviar a fatura" é uma capacidade. "Estornear o último pedido" é uma capacidade. "Puxar os chamados abertos" é uma capacidade. O endpoint é um detalhe de implementação embaixo disso.

Só por isso o Vinkius entrega um catálogo de capacidades, e não um catálogo de wrappers de API. Hoje o catálogo tem milhares e milhares de conectores gerenciados e 61.738 capacidades, e o número que importa não é a quantidade de conectores. É que cada capacidade é uma unidade que você hospeda, versiona, autoriza, mede e audita, do mesmo jeito que auditaria qualquer outro serviço do seu stack.

Este post é a anatomia dessa camada. O que uma capacidade é de fato, como uma chamada passa por ela, as cinco formas como uma capacidade chega, e a matemática de planos e o modelo de segurança embaixo. Sem matemática de marketing: todos os números aqui são o que o produto entrega.

O nome não é por acaso. No produto, você não busca conectores, busca "AI Capabilities". O catálogo, a barra de busca e o pitch de upgrade falam a mesma unidade. Quando um vendor vende uma camada da era dos agentes, a unidade de venda diz o que ele acredita estar vendendo. O Vinkius vende ações, e não endpoints.

A unidade de trabalho deixou de ser o endpoint

Um agente não manda um request HTTP para um serviço. Ele manda intenção. No modelo de execução do Vinkius, a intenção tem exatamente três campos. A capacidade, que é a ação a completar. A entrada, que é o dado que a ação precisa. E a identidade, que é o usuário que autoriza a ação. Todo o resto, autenticação, permissões, mapeamento para a operação correta, retry em falha transitória, é da plataforma, e não do agente.

Depois, quatro estágios rodam. O Authenticate conecta a conta do usuário certa. O Authorize aplica as permissões da ação pedida. O Resolve mapeia a capacidade para a operação correta do sistema. O Execute roda a operação, faz o retry quando deve, e registra o que aconteceu. O resultado volta estruturado: um status, um output normalizado e uma trilha.

Repare no que o modelo nunca vê. O protocolo de transporte. A política de retry. A checagem de permissão. Ele pediu um resultado e recebeu um resultado.

É nesse ponto que grande parte do setor ainda trava. Modelos são melhores pegando um resultado e raciocinando sobre ele do que babando fetch call. A camada de capacidades é o lugar onde a intenção deixa de ser prompt e vira transação.

Tem mais uma parte da anatomia que importa para quem roda frotas de agentes: quem está agindo. Toda chamada de capacidade carrega uma identidade, e a identidade é um usuário, não o modelo. O produto é construído em cima disso. Você monta um aplicativo para um número ilimitado de usuários finais, e as conexões e credenciais de cada um ficam totalmente isoladas das de qualquer outro e da própria plataforma. O agente é a mão. A identidade é de quem essa mão pertence.

O que o catálogo entrega

Os números primeiro, porque eles ancoram tudo. Milhares e milhares de conectores. 61.738 capacidades. A maioria dos conectores é oficial, publicada e mantida pelo Vinkius, e a parte restante é de comunidade. Um número crescente de listagens carrega a marca de novo. O contador do próprio site é gerado a partir dos dados do catálogo, e não é uma constante de marketing que alguém reescreve todo trimestre. Essa é a diferença entre um número que você pode citar para o board e um número que te agrada.

As notas fazem parte da superfície. Os conectores oficiais carregam A+, e as listagens de comunidade levam notas de letra que descem até F, então o classificador não é decorativo. Já vi vendors publicarem score de qualidade que ninguém consegue reproduzir. As nossas moram nos dados do catálogo, ao lado de cada listagem, que é onde você quer que estejam.

Publicar é o outro lado do ledger. As listagens oficiais são mantidas pelo Vinkius, e as de comunidade, pelos seus publishers. A distinção importa por um motivo. Oficial quer dizer que o Vinkius responde. Em listagem de comunidade, o publisher responde. Essas duas passam pelo mesmo pipeline de verificação e chegam na mesma busca, e o selo de confiança é um marcador de responsabilidade, e não uma categoria.

O que "gerenciado" significa de verdade é a parte chata. O Vinkius hospeda o conector, mantém, atualiza e roda a autenticação. Quando a OpenAI ou a Salesforce muda um endpoint, o trabalho é nosso, e não seu. Cada conector do catálogo chega como uma superfície verificada: pronta para produção, com as garantias que o rótulo traz. O control plane diz em uma linha: MCP VERIFIED, PRODUCTION READY, VINKIUS GUARANTEED, e um clique ativa o conector na sua conta.

Hospedar o conector de alguém é assumir a responsabilidade. Quando um terceiro deprecia uma tool, a correção cai no conector, e não no seu app. O catálogo é onde essa responsabilidade fica, e onde a sua conta de manutenção termina.

A amplitude aparece na lista de nomes. OpenAI, Anthropic, Stripe, GitHub, Slack, Salesforce, Tesla, PayPal, Plaid, Datadog, Jira, Shopify, mais a cauda longa: Idealista, Semrush, ElevenLabs, Hugging Face. A página do catálogo resume tudo em uma frase. Uma conexão, todas as ferramentas que o seu agente consegue chamar.

Duas formas de navegar

Existem duas prateleiras, e elas respondem a perguntas diferentes. A primeira é editorial: doze categorias curadas à mão, Industry Titans, Superpower, Loved by Developers, AI Frontier, The Unthinkable, Money Moves, Ship It, Talk to Me, Growth Engine, Brain Trust, Fort Knox e Friends of MCP. São juízos de gosto. São a resposta para "me mostra o que vale o meu tempo".

A segunda é orgânica: vinte e duas categorias preenchidas automaticamente a partir dos manifests, de Productivity e Developer Tools até verticais de cauda longa como Legal, Healthcare, Travel e Hospitality, e Real Estate. É a resposta para "o que eu consigo plugar para essa equipe agora".

No produto, você não precisa escolher prateleira. Discovery, Explore, Favorites, Activated e Library ficam lado a lado, e a busca do catálogo é a mesma busca que um agente usa quando procura uma tool no meio de uma tarefa. Dentro do Explore, quatro abas fazem o trabalho: Top Curated, Newest, Top Tags e Top Categories. Cada uma é uma resposta diferente para a mesma pergunta, qual dos milhares e milhares é o que eu preciso.

O catálogo também navega sem conta. Discovery, tags, categorias e novidades são públicos, porque o catálogo é uma superfície de descoberta, e descoberta não deve ficar atrás de um muro de login. Ativação é onde a conta importa. Um clique, e o conector está vivo no seu control plane. A busca trabalha sobre a tarefa, e não só sobre o nome: você descreve o que precisa, e o catálogo encontra as capacidades que alimentam isso.

As cinco formas como uma capacidade chega

Uma capacidade é um contrato sobre o transporte. Embaixo, um de cinco tipos de servidor a entrega.

O servidor de API é o cavalo de trabalho. É um proxy REST: você aponta para uma URL base, e a superfície transforma qualquer API em interface MCP sem você reconstruir o lado do cliente. Se o vendor entrega uma spec, você importa, e o conjunto de capacidades aparece.

O servidor de Agent Skills é diferente de propósito. Ele expõe arquivos de skill que o modelo lê sob demanda, num padrão chamado disclosure progressivo: o modelo vê o que existe, e só puxa o detalhe quando escolhe aquele caminho. É a forma de capacidade que casa com codebase e base de conhecimento onde a descrição completa da tool não caberia no contexto.

O servidor de MCP Server Deploy é o seu próprio código. Você embala, envia para a edge, e ele roda dentro do runtime de isolates V8 que eu escrevi a fundo aqui. A história do runtime é onde os números de custo e latência moram.

O servidor YAML é o declarativo. Um manifest em YAML, compilado na hora do deploy. É a forma de capacidade que times querem guardar em git e revisar como infraestrutura.

A autenticação mora embaixo de tudo, em quatro formas. Nenhuma, quando a superfície é pública. Bearer, para serviços tokenizados. Basic, para o canto legado. E um header customizado, para os vendors que se recusam a caber em qualquer outra das três. O ponto da taxonomia é que o modelo não vê nada disso. O modelo vê uma capacidade; o transporte, a forma de auth e a política de retry são problema da plataforma.

Do lado do usuário, autenticação não é muro. Cada conector mostra o estado dele de cara: setup pendente, conectado, pronto. Não tem página de login escondida, não tem "deve estar funcionando". Tem mais uma unidade que vale nomear antes da matemática de planos: o capability set. Todo conector entrega o conjunto completo dele, as ações exatas que a sua IA pode escolher quando você pede que trabalhe com aquele conector. O agente não vê o catálogo inteiro de uma vez, vê as tools que ele realmente tem. Isso não é detalhe de produto. É como o catálogo mantém o contexto do modelo honesto.

A matemática dos planos

O acesso a capacidades é gated por plano em um lugar só: a tier grátis. Ela roda cem requests por ciclo de 30 dias, um token de conexão, duas instalações de catálogo, e os dashboards dela vêm rotulados com dados de amostra, para ninguém confundir demo com sistema vivo. A partir das tiers pagas, o catálogo não tem teto de instalação, e os tetos de request são os números de planejamento de verdade: 5 mil por ciclo na Lite, 25 mil na Starter, 100 mil na Pro e 500 mil na Business.

Os tetos não são decoração. É a camada de medição. Uma capacidade que consegue estornear um pedido é uma capacidade que pode rodar em loop, e um loop que queima mil dólares por noite é um problema de governança antes de ser um problema de engenharia. O KPI próprio do produto, Cost Saved, mede os bytes que um teto de custo remove do caminho de saída, então o número no dashboard é um número que você consegue defender numa reunião de orçamento.

Passado o teto, a cobrança de overage acontece em soft limit, sem parar a chamada de vez, e isso é de propósito. Um stop duro em produção é fila de suporte. Um overage medido é uma linha na conta. Essa é a filosofia inteira dos tetos: eles são número para planejar, e não parede para bater.

Os tokens de conexão sobem na escada: três na Lite e na Starter, dez na Pro e vinte e cinco na Business. O histórico de atividade vai de três dias nas tiers pagas de entrada para sete na Pro e trinta na Business, e a trilha de auditoria da tier de cima é a imutável. É lá que a organização mora: times, papéis, escopo por projeto, service accounts e provisionamento de chave de API, SSO, trilha de auditoria imutável de trinta dias, revogação instantânea de token, e kill switch com disjuntor de circuito.

A camada de segurança que o CISO vai perguntar

Cada conector roda num sandbox selado próprio. Trinta e quatro regras ou mais são aplicadas em todo request, e elas cobrem limites de memória, limites de CPU, proteção contra SSRF, bloqueio de rede privada, proteção contra arquivo malicioso e isolamento de credencial. Eventos de segurança chegam em tempo real no Datadog, no Splunk ou num webhook. A trilha de auditoria é assinada e encadeada, assinaturas Ed25519 sobre blocos SHA-256, então registro adulterado não some em silêncio sem quebrar a cadeia.

O tratamento de credencial segue uma regra só. Escopada, sob controle do usuário, revogável a qualquer hora, e a plataforma nunca treina com os seus dados. O FAQ do próprio produto diz a metade que vem, para você poder citá-lo de volta: "Vinkius nunca treina com os seus dados, e você revoga o acesso a qualquer hora." As credenciais de usuário final são guardadas com segurança, nunca voltam a aparecer depois do save, e as conexões de cada usuário ficam totalmente isoladas das de qualquer outro e da plataforma. A superfície de auditoria de deploy exporta um PDF, que é o formato que um regulador ou um comitê de diretoria realmente lê.

Há anos eu peço para vendors escreverem essas duas frases na página deles. O catálogo as escreve.

Por que gerenciado ganha de costurado

Toda integração caseira é uma promessa que você tem que manter para sempre. O vendor muda um campo. Você reescreve o parser. O fluxo de auth se move. Você corre atrás. Uma integração que ninguém olhou há um ano é um passivo vestindo fantasia de feature. O catálogo inverte o modelo de manutenção. Hospedagem, autenticação, execução, monitoramento, atualizações: a plataforma faz, e uma capacidade vira uma linha num manifest, em vez de um codebase de código cola que alguém precisa babar.

A matemática dessa inversão é o argumento. Diga que o seu stack precisa de cem conectores. Cem integrações caseiras são cem promessas de manutenção, cada uma com parser que pode apodrecer, fluxo de auth que pode quebrar, versão que pode mudar embaixo de você. Cem conectores de catálogo são cem superfícies mantidas, e o custo de manutenção fica no lado da plataforma da conta. É a diferença entre comprar uma ferramenta e ser dono de uma.

Tem também o argumento do primeiro dia. O seu aplicativo de IA começa com milhares de conectores no catálogo, e isso é uma diferença real para o time que gasta o primeiro trimestre conectando as duas integrações que a demo precisava. O catálogo é o motivo pelo qual o primeiro commit de um app de agente pode ser o produtivo.

Do lado do cliente, a mesma forma. As superfícies do catálogo falam MCP, o que significa que o mesmo conector funciona do ChatGPT, do Claude e do Gemini, do Cursor, do Cline e do VS Code, e do Vercel AI SDK dentro do seu app. Você mantém o conjunto de capacidades uma vez, e todo cliente que fala o protocolo consegue chamá-lo.

Onde isso se encaixa

O catálogo é a camada de capacidades. O control plane é as regras para as chamadas: identidade, enforcement no caminho, gasto limitado, isolamento de segredo, ledger contra adulteração, continuidade de trilha, um portão humano e um off switch, e overhead medido. As oito regras eu escrevi no post do control plane. O runtime de isolates V8 tem o próprio post. O catálogo é onde essas regras têm algo para governar.

Três posts, um stack. O post do control plane cobre as regras das chamadas. O post do V8 cobre onde o código roda. Este cobre a unidade que torna os outros dois válidos. Sem catálogo, o control plane governa nada, e o runtime de isolates não tem nada para rodar. O catálogo é o lado do fornecimento da economia de agentes. Ele decide quais ações existem, quem as mantém, quanto custam, e o que acontece quando falham.

Quando um agente pede o mundo, a camada de capacidades é a porta, e o control plane é a fechadura. O trabalho do catálogo é deixar a porta larga o suficiente para que um agente nunca precise construir uma porta sozinho. A régua que eu vou segurar o catálogo, e qualquer catálogo que reclame o mesmo espaço: superfícies verificadas, notas que você consegue reproduzir, medição que um time financeiro consegue defender, e trilha de auditoria que não dá para editar em silêncio. O resto é diretório, não camada.