La capa de capacidades: miles y miles de conectores y el fin de las integraciones a medida

Durante veinte años, la unidad de trabajo en integración fue el endpoint. Tenías una URL, un verbo, un formato en la red, un rate limit, un flujo OAuth, y escribías código pegamento para sostenerlo todo. La unidad está cambiando. Es la capacidad: una cosa que un agente puede hacer a un sistema. «Enviar la factura» es una capacidad. «Reembolsar el último pedido» es una capacidad. «Sacar los tickets abiertos» es una capacidad. El endpoint es un detalle de implementación debajo.

Por eso Vinkius entrega un catálogo de capacidades, y no un catálogo de wrappers de API. Hoy el catálogo tiene miles y miles de conectores gestionados y 61.738 capacidades, y el número que importa no es la cantidad de conectores. Es que cada capacidad es una unidad que puedes hospedar, versionar, autorizar, medir y auditar, igual que auditarías cualquier otro servicio de la pila.

Este post es la anatomía de esa capa. Qué es realmente una capacidad, cómo la atraviesa una llamada, las cinco formas en que una capacidad llega, y la matemática de planes y el modelo de seguridad debajo. Sin matemática de marketing: cada cifra de aquí es lo que el producto entrega.

El nombre no es casual. En el producto no buscas conectores; buscas «AI Capabilities». El catálogo, la barra de búsqueda y el pitch de upgrade hablan la misma unidad. Cuando un vendor vende una capa de la era de los agentes, la unidad de venta dice lo que cree estar vendiendo. Vinkius vende acciones, no endpoints.

La unidad de trabajo ya no es el endpoint

Un agente no envía un request HTTP a un servicio. Envía intención. En el modelo de ejecución de Vinkius, la intención tiene exactamente tres campos. La capacidad, que es la acción a completar. La entrada, que es el dato que la acción necesita. Y la identidad, que es el usuario que autoriza la acción. Todo lo demás, autenticación, permisos, mapeo hacia la operación correcta, reintento en fallo transitorio, es de la plataforma, y no del agente.

Después corren cuatro etapas. Authenticate conecta la cuenta del usuario correcta. Authorize aplica los permisos de la acción pedida. Resolve mapea la capacidad a la operación correcta del sistema. Execute corre la operación, reintenta cuando debe, y registra lo que pasó. El resultado vuelve estructurado: un status, una salida normalizada y una traza.

Fíjate en lo que el modelo nunca ve. El protocolo de la red. La política de reintento. La comprobación de permisos. Pidió un resultado y recibió un resultado.

Es ahí donde gran parte del sector sigue atascado. Los modelos son mejores tomando un resultado y razonando sobre él que cuidando una llamada fetch. La capa de capacidades es el lugar donde la intención deja de ser prompt y se vuelve transacción.

Hay otra parte de la anatomía que importa si corres flotas de agentes: quién actúa. Cada llamada de capacidad lleva una identidad, y la identidad es un usuario, no el modelo. El producto está construido sobre ese hecho. Puedes montar una aplicación para un número ilimitado de usuarios finales, y las conexiones y credenciales de cada uno quedan totalmente aisladas de las de cualquier otro y de la propia plataforma. El agente es la mano. La identidad es de quién es esa mano.

Lo que el catálogo entrega

Los números primero, porque anclan todo. Miles y miles de conectores. 61.738 capacidades. La mayoría de los conectores son oficiales, publicados y mantenidos por Vinkius, y el resto es de comunidad. Un número creciente de listados lleva la marca de nuevo. El contador del propio sitio se genera a partir de los datos del catálogo, no es una constante de marketing que alguien reescribe cada trimestre, y esa es la diferencia entre un número que puedes citar ante el consejo y uno que te halaga.

Las notas forman parte de la superficie. Los conectores oficiales llevan A+, y los listados de comunidad llevan notas de letra que bajan hasta F, así que el que puntúa no está decorando. He visto vendors publicar scores de calidad que nadie puede reproducir. Las nuestras viven en los datos del catálogo, junto a cada listado, que es donde las quieres.

Publicar es el otro lado del libro mayor. Los listados oficiales los mantiene Vinkius, y los de comunidad, sus publishers. La distinción importa por una razón. Oficial quiere decir que Vinkius responde. En un listado de comunidad, el publisher responde. Los dos pasan por el mismo pipeline de verificación y caen en la misma búsqueda, y la insignia de confianza es un marcador de responsabilidad, no una categoría.

Lo que «gestionado» significa de verdad es la parte aburrida. Vinkius hospeda el conector, lo mantiene, lo actualiza y corre la autenticación. Cuando OpenAI o Salesforce cambia un endpoint, el trabajo es nuestro, y no tuyo. Cada conector del catálogo llega como una superficie verificada: lista para producción, con las garantías que trae la etiqueta. El control plane lo dice en una línea, MCP VERIFIED, PRODUCTION READY, VINKIUS GUARANTEED, y un clic activa el conector en tu cuenta.

Hospedar el conector de otro es absorber la responsabilidad. Cuando un tercero deprecia una tool, la corrección cae en el conector, y no en tu app. El catálogo es donde esa responsabilidad se queda, y donde tu factura de mantenimiento termina.

La amplitud se ve en la lista de nombres. OpenAI, Anthropic, Stripe, GitHub, Slack, Salesforce, Tesla, PayPal, Plaid, Datadog, Jira, Shopify, más la cola larga: Idealista, Semrush, ElevenLabs, Hugging Face. La página del catálogo lo resume todo en una frase. Una conexión, todas las herramientas que tu agente puede llamar.

Dos formas de navegar

Hay dos estantes, y responden a preguntas diferentes. El primero es editorial: doce categorías curadas a mano, Industry Titans, Superpower, Loved by Developers, AI Frontier, The Unthinkable, Money Moves, Ship It, Talk to Me, Growth Engine, Brain Trust, Fort Knox y Friends of MCP. Son juicios de gusto. Son la respuesta a «muéstrame lo que vale mi tiempo».

La segunda es orgánica: veintidós categorías pobladas automáticamente desde los manifests, de Productivity y Developer Tools hasta verticales de cola larga como Legal, Healthcare, Travel and Hospitality, y Real Estate. Es la respuesta a «qué puedo enchufar de verdad para este equipo, ahora».

En el producto no tienes que elegir estante. Discovery, Explore, Favorites, Activated y Library van lado a lado, y la búsqueda del catálogo es la misma que un agente usa cuando busca una tool a mitad de una tarea. Dentro de Explore, cuatro pestañas hacen el trabajo: Top Curated, Newest, Top Tags y Top Categories. Cada una es una respuesta distinta a la misma pregunta, cuál de los miles y miles es el mío.

El catálogo también navega sin cuenta. Discovery, tags, categorías y novedades son públicos, porque el catálogo es una superficie de descubrimiento, y el descubrimiento no debería quedarse tras un muro de login. La activación es donde cuenta la cuenta. Un clic, y el conector está vivo en tu control plane. La búsqueda trabaja sobre la tarea, y no solo sobre el nombre: describes lo que necesitas, y el catálogo encuentra las capacidades que lo alimentan.

Las cinco formas en que llega una capacidad

Una capacidad es un contrato sobre el transporte. Debajo, uno de cinco tipos de servidor la entrega.

El servidor de API es el caballo de tiro. Es un proxy REST: lo apuntas a una URL base, y la superficie convierte cualquier API en interfaz MCP sin que reconstruyas el lado del cliente. Si el vendor entrega una spec, la importas, y aparece el conjunto de capacidades.

El servidor de Agent Skills es distinto a propósito. Expone archivos de skill que el modelo lee bajo demanda, en un patrón llamado disclosure progresivo: el modelo ve lo que hay, y solo tira del detalle cuando elige ese camino. Es la forma de capacidad que encaja en codebases y bases de conocimiento donde la descripción completa de la tool no cabría en el contexto.

El servidor de MCP Server Deploy es tu propio código. Lo empacas, lo envías a la edge, y corre dentro del runtime de isolates V8 de lo que escribí a fondo aquí. La historia del runtime es donde viven los números de coste y latencia.

El servidor YAML es el declarativo. Un manifest en YAML, compilado en el momento del deploy. Es la forma de capacidad que los equipos quieren en git, revisada como infraestructura.

La autenticación vive debajo de todo, en cuatro formas. Ninguna, cuando la superficie es pública. Bearer, para servicios tokenizados. Basic, para el rincón legacy. Y un header a medida, para los vendors que se niegan a caber en cualquiera de las otras tres. El punto de la taxonomía es que el modelo no ve nada de eso. El modelo ve una capacidad; el transporte, la forma de auth y la política de reintento son problema de la plataforma.

Del lado del usuario, la autenticación no es muro. Cada conector muestra su estado de un vistazo: configuración pendiente, conectado, listo. No hay página de login escondida, no hay «debe funcionar». Hay otra unidad que vale la pena nombrar antes de la matemática de planes: el capability set. Cada conector entrega su conjunto completo, las acciones exactas que tu IA puede elegir cuando le pides que trabaje con ese conector. El agente no ve el catálogo entero de golpe; ve las tools que realmente tiene. Eso no es un detalle de producto. Es como el catálogo mantiene honesto el contexto del modelo.

La matemática de los planes

El acceso a capacidades está gated por plan en un único lugar: la tier gratis. Corre cien requests por ciclo de 30 días, un token de conexión, dos instalaciones de catálogo, y sus dashboards vienen etiquetados con datos de muestra, para que nadie confunda una demo con un sistema vivo. A partir de las tiers de pago, el catálogo no tiene tope de instalación, y los topes de request son los números de planificación reales: 5.000 por ciclo en Lite, 25.000 en Starter, 100.000 en Pro y 500.000 en Business.

Los topes no son decoración. Es la capa de medición. Una capacidad que puede reembolsar un pedido es una capacidad que puede correr en bucle, y un bucle que quema mil dólares por noche es un problema de gobernanza antes que uno de ingeniería. El KPI propio del producto, Cost Saved, mide los bytes que un tope de coste saca del camino de salida, así que el número en el dashboard es un número que puedes defender en una reunión de presupuesto.

Pasado el tope, el overage se cobra en soft limit, sin cortar la llamada de golpe, y eso es deliberado. Un corte duro en producción es cola de soporte. Un overage medido es una línea en la cuenta. Esa es la filosofía entera de los topes: son números para planificar, no muros para estrellarse.

Los tokens de conexión suben por la escalera: tres en Lite y en Starter, diez en Pro, veinticinco en Business. El historial de actividad va de tres días en las tiers de pago de entrada a siete en Pro y treinta en Business, y la traza de auditoría de la tier de arriba es la inmutable. Ahí es donde vive la organización: equipos, roles, ámbito por proyecto, service accounts y aprovisionamiento de clave de API, SSO, traza de auditoría inmutable de treinta días, revocación instantánea de token, y kill switch con disyuntor.

La capa de seguridad que va a pedir tu CISO

Cada conector corre en su propia sandbox sellada. Treinta y cuatro reglas o más se aplican en cada request, y cubren límites de memoria, límites de CPU, protección contra SSRF, bloqueo de red privada, protección contra archivo malicioso y aislamiento de credencial. Los eventos de seguridad llegan en tiempo real a Datadog, a Splunk o a un webhook. La traza de auditoría está firmada y encadenada, firmas Ed25519 sobre bloques SHA-256, así que un registro adulterado no puede caer en silencio sin romper la cadena.

El tratamiento de credenciales sigue una regla. Con alcance, bajo control del usuario, revocable a cualquier hora, y la plataforma nunca entrena con tus datos. El FAQ del propio producto lo dice en voz alta, para que puedas citarlo de vuelta: «Vinkius nunca entrena con tus datos, y puedes revocar el acceso a cualquier hora.» Las credenciales de usuario final se guardan con seguridad, nunca vuelven a aparecer después del save, y las conexiones de cada usuario quedan totalmente aisladas de las de cualquier otro y de la plataforma. La superficie de auditoría de deploy exporta un PDF, que es el formato que un regulador o un comité de dirección de hecho lee.

Llevo años pidiendo a los vendors que escriban esas dos frases en su página. El catálogo las escribe.

Por qué lo gestionado gana al cosido

Cada integración a medida es una promesa que tienes que mantener para siempre. El vendor cambia un campo. Reescribes el parser. El flujo de auth se mueve. Tú lo persigues. Una integración que nadie mira desde hace un año es una deuda disfrazada de funcionalidad. El catálogo invierte el modelo de mantenimiento. Hospedaje, autenticación, ejecución, monitorización, actualizaciones: la plataforma las hace, y una capacidad se vuelve una línea en un manifest, en vez de un codebase de código pegamento que alguien tiene que mimar.

La cuenta de ese cambio de modelo es el argumento. Digamos que tu stack necesita cien conectores. Cien integraciones a medida son cien promesas de mantenimiento, cada una con un parser que puede podrirse, un flujo de auth que puede romperse, una versión que puede cambiarte debajo. Cien conectores de catálogo son cien superficies mantenidas, y el coste de mantenimiento queda en el lado plataforma de la cuenta. Esa es la diferencia entre comprar una herramienta y ser dueño de una.

También hay argumento del primer día. Tu aplicación de IA arranca con miles de conectores en el catálogo, y eso es una diferencia real frente al equipo que se pasa el primer trimestre cableando las dos integraciones que la demo necesitaba. El catálogo es la razón por la que el primer commit de una app de agentes puede ser el productivo.

Del lado del cliente, la misma forma. Las superficies del catálogo hablan MCP, lo que significa que el mismo conector funciona desde ChatGPT, Claude y Gemini, desde Cursor, Cline y VS Code, y desde el Vercel AI SDK dentro de tu propia app. Mantienes el conjunto de capacidades una vez, y todo cliente que hable el protocolo puede llamarlo.

Dónde se ubica

El catálogo es la capa de capacidades. El control plane son las reglas de las llamadas: identidad, enforcement en el camino, gasto acotado, aislamiento de secreto, ledger contra adulteración, continuidad de traza, una puerta humana y un off switch, y overhead medido. Las ocho reglas las escribí en el post del control plane. El runtime de isolates V8 tiene su propio post. El catálogo es donde esas reglas tienen algo que gobernar.

Tres posts, un stack. El post del control plane cubre las reglas de las llamadas. El del V8 cubre dónde corre el código. Este cubre la unidad que hace que los otros dos valgan la pena. Sin catálogo, el control plane no gobierna nada, y el runtime de isolates no tiene nada que correr. El catálogo es el lado del suministro de la economía de agentes. Decide qué acciones existen, quién las mantiene, cuánto cuestan, y qué pasa cuando fallan.

Cuando un agente pide el mundo, la capa de capacidades es la puerta, y el control plane es la cerradura. El trabajo del catálogo es dejar la puerta lo bastante ancha para que a un agente nunca le toque construir una puerta solo. La barra que le voy a exigir al catálogo, y a cualquier catálogo que reclame el mismo espacio: superficies verificadas, notas que puedes reproducir, medición que un equipo financiero puede defender, y traza de auditoría que no da para editar en silencio. Lo demás es un directorio, no una capa.