MCP ya es una aptitud certificable: el examen MCPA y lo que señala su peso del 24 % en Seguridad y Gobernanza

Conclusiones clave

• El Model Context Protocol Associate (MCPA) se lanzó el 14 de septiembre de 2026 — la primera credencial oficial de MCP, un examen supervisado de 120 minutos con cinco dominios y Seguridad y Gobernanza con el segundo mayor peso, un 24 % — anunciado por la Agentic AI Foundation bajo The Linux Foundation.
• Los SDK de Nivel 1 de MCP se acercan a los 500 millones de descargas mensuales, y los SDK de TypeScript y Python superan cada uno los 1.000 millones de descargas totales — una escala que, según AAIF, hizo necesario un punto de referencia compartido de competencias.
• Las llamadas a herramientas MCP de los usuarios de ChatGPT alcanzaron 98 veces su nivel de enero en agosto, y Resend superó el millón de llamadas MCP en un solo mes — el uso del protocolo crece tan rápido como las descargas.
• Enterprise-Managed Authorization (EMA), una extensión de autorización MCP estable construida sobre el borrador ID-JAG de IETF, llegó a Keycloak como función experimental en la versión 26.7 — la primera implementación de código abierto de una política de acceso MCP centralizada.
• La certificación está alineada con la especificación MCP 2026-07-28, el mismo protocolo sin estado que ejecutan los despliegues B2B en producción — una credencial, una extensión de autorización y una especificación son ahora tres capas de la misma disciplina profesional.

El trabajo de integración MCP acaba de convertirse en algo que un responsable de contratación puede verificar. El 14 de septiembre de 2026, la Agentic AI Foundation — el hogar dentro de The Linux Foundation de MCP, A2A, AGENTS.md, goose, agentgateway y Agent Router — abrió la inscripción para el Model Context Protocol Associate (MCPA), la primera certificación oficial del protocolo. Un examen de 120 minutos, supervisado y de opción múltiple, separa ahora «ha leído la documentación de MCP» de «puede razonar sobre hosts, clientes, servidores, límites de confianza y controles de riesgo». Las propias cifras del protocolo explican por qué llegó una credencial cuando lo hizo: las descargas mensuales de los SDK de Nivel 1 se acercan a los 500 millones, los SDK de TypeScript y Python superan cada uno los 1.000 millones de descargas totales, y las llamadas a herramientas MCP de los usuarios de ChatGPT alcanzaron 98 veces su nivel de enero en agosto. Este artículo cubre qué evalúa el examen, por qué la ponderación de dominios importa más que la credencial en sí, y qué cambia para los equipos que contratan — y operan — sistemas de agentes conectados vía MCP.

Qué certifica realmente el MCPA

El MCPA es un examen de 120 minutos, en línea, supervisado y de opción múltiple, organizado en cinco dominios, alineado con la especificación 2026-07-28 — el mismo protocolo final sin estado analizado en nuestro análisis de despliegues B2B. Los pesos de los dominios:

Dominio	Peso
Interacciones y ejecución	26 %
Seguridad y Gobernanza	24 %
Casos de uso y ecosistema	20 %
Fundamentos de MCP	16 %
Arquitectura y componentes	14 %

Dos hechos estructurales destacan. Primero, los dos dominios más pesados — Interacciones y ejecución (26 %) y Seguridad y Gobernanza (24 %) — suman la mitad del examen. Se evalúa a los candidatos en límites de confianza, permisos y controles de riesgo, no solo en primitivas del protocolo. Segundo, la distribución de pesos trata la seguridad como una disciplina de primera clase y no como un epílogo del último capítulo. David Soria Parra, cocreador de MCP y mantenedor principal, enmarcó el objetivo en el anuncio de lanzamiento: la certificación «formalizará una comprensión compartida de cómo funciona el protocolo». Angie Jones, VP de Experiencia de Desarrolladores de AAIF, añadió el enfoque desde el lado del empleador: un «punto de referencia compartido para evaluar las competencias que exige el desarrollo de software moderno».

Para contextualizar la escala: esta es la primera certificación lanzada por AAIF. La fundación podría haber credenciado cualquiera de sus seis proyectos fundadores. Eligió MCP primero.

La señal del 24 %: la seguridad ya es un criterio de contratación, no un parche

Que el dominio de Seguridad y Gobernanza lleve el segundo mayor peso es el dato para el que existe este artículo. Cuando un organismo de estándares pone el 24 % de su primera credencial en un tema, le está diciendo al mercado qué incluye la operación competente del protocolo. El historial de seguridad de MCP en 2026 hizo inevitable esa ponderación: Trend Micro encontró 1.467 servidores MCP públicamente accesibles sin autenticación, la ola de CVEs de julio dejó tres CVEs en el propio SDK oficial de MCP para Python, y CISA añadió CVE-2026-59822 — un bypass de autenticación en el endpoint MCP de LiteLLM — al catálogo de Vulnerabilidades Explotadas Conocidas con fecha límite de remediación el 16 de septiembre. Nuestra Lista de verificación de endurecimiento de MCP organiza los controles detrás de ese historial en doce capas verificables; el MCPA ahora certifica que se espera que los profesionales los conozcan.

Para un Head of Engineering que construye un programa de agentes, la consecuencia práctica es concreta: el examen proporciona un instrumento de selección. La pregunta «¿ha obtenido su equipo el MCPA?» sustituye a «¿cuán bien conocen MCP?» — y la respuesta es verificable, porque la credencial es supervisada y neutral respecto a proveedores. La misma lógica aplica a la evaluación de proveedores y contratistas: un socio que vende servicios de integración MCP puede señalar ahora una credencial que verifica que su gente entiende el alcance de permisos y los límites de confianza al nivel que exige la especificación.

Los pesos de los dominios y los datos de adopción detrás de la credencial, en una sola vista:

La otra mitad de la profesionalización: quién custodia las llaves

Una credencial certifica a las personas. Las empresas también necesitan la capa organizativa: quién autoriza a un agente a tocar un servidor MCP, y cómo se revoca ese acceso cuando el empleado que lo aprobó cambia de rol. La capa de protocolo respondió a eso el 9 de septiembre, cuando AAIF publicó una implementación de Enterprise-Managed Authorization en Keycloak. EMA es una extensión de autorización MCP estable construida sobre ID-JAG — Identity Assertion JWT Authorization Grant, un borrador de IETF — que convierte al proveedor de identidad empresarial en la puerta de políticas para el acceso MCP.

El problema que resuelve es concreto. En el modelo de autorización MCP estándar, cada servidor puede mantener su propio silo OAuth. La publicación de AAIF nombra los tres modos de fallo empresariales: la sobrecarga administrativa de rastrear el acceso de agentes por servidor, la «dispersión OAuth» de usuarios que autorizan herramientas por su cuenta, y la fatiga de consentimiento — usuarios aprobando a ciegas solicitudes de acceso, lo que la publicación llama «un grave riesgo de seguridad sistémico». ID-JAG invierte el flujo: el proveedor de identidad emite una afirmación firmada para un servidor de autorización MCP específico, el cliente la presenta, y el servidor valida y emite un token de acceso con alcance. La política de autorización puede evaluarse en ambos extremos. El PR #46048 de Keycloak (soporte de consumidor) se fusionó como función experimental en Keycloak 26.7; el PR #49998 (soporte de emisor) está en revisión.

Esto importa para el trabajo de conectores que publicamos — NetSuite, HubSpot, Shopify — porque el OAuth por servidor es exactamente lo que produce a escala un despliegue de agentes multi-sistema. Un distribuidor que conecta un agente de cotización RFQ a NetSuite, BigCommerce y tres catálogos de proveedores no quiere tres silos de autorización independientes y un prompt de aprobación por herramienta. EMA le da al IdP el rol que ya desempeña para el acceso humano, extendido a los agentes — el acceso sigue al rol y a la pertenencia a grupos a través de la incorporación, el traslado y la salida, sin prompts por servidor.

Leyendo la curva de adopción con honestidad

Las estadísticas de uso del anuncio son grandes, y los números grandes merecen contexto. Que los SDK de TypeScript y Python superen cada uno los 1.000 millones de descargas totales mide la adopción acumulada desde el lanzamiento — una señal de crecimiento, no de profundidad en producción. Los puntos de datos más agudos son los de comportamiento: las llamadas a herramientas MCP de los usuarios de ChatGPT alcanzaron 98 veces su nivel de enero en agosto, y Resend procesó 1 millón de llamadas MCP en un solo mes. El volumen de llamadas a herramientas se acerca más a la realidad de producción que los recuentos de descargas, porque refleja agentes invocando herramientas realmente, no desarrolladores instalando SDK.

La advertencia honesta: la adopción a esta velocidad es también la razón por la que el dominio de seguridad pondera un 24 %. La misma ausencia de fricción que produjo mil millones de descargas produjo 1.467 servidores expuestos sin autenticación. El MCPA certifica la conciencia de esa brecha; no la cierra. La lista de verificación de endurecimiento y los patrones de módulos gobernados siguen siendo la capa operativa entre un profesional certificado y un despliegue seguro. Una credencial en la pared más un servidor sin endurecer en producción es el modo de fallo exacto que el dominio del 24 % existe para prevenir.

Qué debería hacer un equipo mediano con esto

Para una empresa B2B de 100 a 2.000 empleados con un grupo de plataforma reducido, el MCPA cambia tres prácticas concretas:

1. Contratación: añada la familiaridad con MCP — MCPA o experiencia demostrada equivalente — a los requisitos de quien posea las integraciones de agentes. La credencial da a los entrevistadores un vocabulario compartido y una base verificable para la arquitectura sin estado de la especificación 2026-07-28.
2. Arquitectura de autorización: si los agentes se conectan a más de un servidor MCP, evalúe EMA ahora. La implementación de Keycloak es experimental, pero la extensión EMA está marcada como estable, y la autorización empresarial gestionada de Claude muestra que las grandes plataformas convergen en el mismo patrón. Los silos OAuth por servidor no sobreviven al contacto con una segunda integración.
3. La ponderación de seguridad como estándar de revisión: use la lista de dominios del examen como lista de verificación de alcance. Si su despliegue MCP no tiene respuesta para los límites de confianza, los permisos y los controles de riesgo que componen el 24 % de la credencial, esa brecha — no la fontanería del protocolo — es donde empezará un auditor.

Nada de esto exige reemplazar su framework de agentes. Exige tratar la experiencia en MCP como una aptitud con nombre y un estándar verificable, y tratar la autorización MCP como una preocupación empresarial en lugar de un prompt por herramienta.

Lecturas relacionadas

• Tutorial de MCP: de cero a servidor de producción con la especificación 2026-07-28 — el compañero práctico: el examen certifica el conocimiento del protocolo; este tutorial recorre la construcción de producción a la que debería corresponder
• Checklist de endurecimiento de seguridad MCP: 1.467 servidores expuestos y los controles que los cierran — los doce controles detrás del dominio de Seguridad y Gobernanza del 24 %, organizados en cinco capas
• MCP 2026-07-28: lo que el protocolo sin estado significa para los despliegues B2B de agentes — la especificación con la que el MCPA está alineado, y qué cambia la ausencia de estado para la auditoría y el escalado

Viñeta representativa de implementación

Un distribuidor industrial de 500 empleados contrató a un ingeniero de plataforma para conectar un agente de cotización RFQ a NetSuite y BigCommerce mediante dos módulos MCP. La primera integración llevó cinco semanas — flujos OAuth por servidor construidos por separado, un prompt de aprobación por herramienta, ninguna revocación central cuando el ingeniero cambió de rol. Cuando un segundo agente de cotización necesitó los mismos sistemas, el equipo desplegó el patrón EMA con su proveedor de identidad existente: un flujo de afirmación firmada, acceso MCP limitado al rol y a la pertenencia a grupos, y un único punto de revocación aplicado a cada servidor que el agente podía alcanzar. La segunda integración llevó nueve días, y la revisión de seguridad que había estancado el primer despliegue tomó una reunión — la política de autorización era legible en el IdP, no reconstruida a partir de tres paneles OAuth.

Request a scoped build

One-week discovery. You get a system inventory, workflow map, and fixed scope — whether or not you build with us.