Servidores MCP en accesibilidad digital: cómo conectar tu agente sin darle las llaves de todo
Con es post termino la trilogía que tenía en mente sobre este tema y que comencé cuando escribí Evaluar accesibilidad en 2026: decisiones estratégicas para combinar auditoría manual, automatización e IA, unos días después tocaba hablar de skills y publiqué Usar skills de IA en accesibilidad digital sin morir en el intento: protocolo para no delegar tu criterio y hoy termino hablando de servidores MCP, (y al final me ha quedado una trilogía que ni la de Nolan del caballero oscuro…)
Los servidores MCP se están convirtiendo en la nueva pieza de moda en el ecosistema de agentes de IA: permiten que el modelo hable con repositorios, navegadores, APIs y herramientas especializadas sin integraciones a medida y obviamente esto también se puede usar cuando estamos hablando de accesibilidad digital, además, es algo que tenemos que tomarnos como una buena noticia (podemos enchufar axe-core, Playwright o servidores de testing a11y directamente al agente), pero también abre un frente nuevo: ¿cómo conectamos nuestro agente sin darle, de facto, las llaves de todo el sistema?
Como ya decía en los otros post relacionados con el tema, no voy a decirte que no uses MCP, pero sí quiero darte un protocolo para que no conviertas tu auditoría de accesibilidad en un acto de fe.
Qué es el Model Context Protocol (MCP) y por qué importa en accesibilidad
El Model Context Protocol es un estándar que define cómo un modelo de lenguaje puede descubrir y utilizar herramientas externas (APIs, bases de datos, navegadores, etc.) de forma estructurada y segura, en lugar de integraciones rígidas, MCP permite que un agente descubra “servers” con herramientas declaradas (tools), sepa qué parámetros aceptan y pueda llamarlas cuando necesita datos o ejecutar acciones.
Esto tiene dos consecuencias clave para accesibilidad digital:
- Podemos exponer motores de testing de accesibilidad (axe, Playwright, simuladores de color, etc.) como herramientas MCP, de manera que el agente no se invente análisis, sino que llame a tests reales.
- Podemos traer los resultados de esas herramientas directamente al contexto del modelo para que ayude a interpretarlos, agruparlos, priorizarlos o documentarlos.
El problema es que, si no ponemos límites, ese mismo mecanismo puede permitir al agente leer o modificar cosas que no debería, ejecutar tests en entornos sensibles, o hacerlo sin dejar rastro de qué se ha hecho exactamente.
Servidores MCP en accesibilidad digital: qué existe hoy
Ya hay servidores MCP específicos orientados a accesibilidad web, además de integraciones genéricas de testing que se pueden usar con un enfoque a11y.
A11y MCP (Web Accessibility Testing MCP)
A11y MCP es un servidor MCP que da a los modelos acceso a APIs de testing de accesibilidad web, usando Deque axe-core por debajo.[mcpservers]
Permite que un agente analice páginas remotas, reciba resultados de axe-core (violaciones WCAG, severidad, selectores, etc.) y use esos datos para guiar correcciones o redactar informes más inteligentes.
Web Accessibility MCP Server
Otro ejemplo es Web Accessibility MCP Server, que proporciona herramientas como check_accessibility para analizar páginas y simulate_colorblind para simular determinados tipos de daltonismo, este tipo de servidor hace que un agente pueda comprobar no sólo si se cumplen reglas, sino también cómo se percibe el contenido para usuarios con ciertos tipos de visión reducida, sin tener que implementar toda la lógica desde cero.
Axe MCP Server y Playwright MCP
Deque está impulsando un Axe MCP Server que lleva su experiencia en testing de accesibilidad directamente al IDE o al agente de desarrollo: puedes pedirle a tu asistente que ejecute pruebas axe en el contexto del código que estás editando y devuelva hallazgos y recomendaciones.
En paralelo, hay Playwright MCP servers que permiten a agentes lanzar pruebas E2E (incluyendo checks de accesibilidad) contra aplicaciones web, combinando navegación real del navegador con validaciones automatizadas.
Juntos, estos ejemplos hacen algo muy potente: conectan el mundo de la accesibilidad digital basada en herramientas consolidadas con el mundo de la IA generativa y los agentes, sin depender sólo de la imaginación del modelo.
Dónde se tuerce la cosa: MCP como riesgo si no hay gobernanza
Justamente porque MCP abre puertas, hay que decidir a qué puertas y con qué llaves., la propia literatura sobre MCP y seguridad lo deja claro: sustituir integraciones rígidas por agentes dinámicos introduce nuevos riesgos de fuga de datos, acciones no deseadas o abuso de herramientas si no hay controles fuertes.
Distintos actores (proveedores cloud, fabricantes de seguridad, plataformas de MCP) están insistiendo en que la gobernanza MCP es el gran hueco que muchas organizaciones todavía no han cerrado.
Algunos problemas típicos:
- Shadow MCP: servidores instalados por equipos individuales sin inventario central ni revisión de seguridad, similares al viejo “shadow IT”.
- Permisos excesivos: MCP que pueden leer repositorios enteros, bases de datos o ejecutar comandos sensibles sin necesidad real.
- Falta de logs: no se registran prompts, herramientas llamadas ni resultados, de modo que es difícil reconstruir qué hizo un agente cuando algo sale mal.
- Entornos mezclados: tests de accesibilidad lanzados desde agentes contra producción con credenciales de alto privilegio, sin distinguir de dev/stage.
En accesibilidad digital esto no es sólo un tema de ciberseguridad, si un server MCP mal configurado ejecuta análisis sobre contenidos que no debería, o introduce cambios no deseados porque también tiene herramientas de escritura, el resultado puede ser a la vez inseguro y metodológicamente incorrecto.
Protocolo de gobernanza MCP para equipos de accesibilidad digital
Igual que con las skills, la idea no es dejar de usar MCP, sino no usarlos a ciegas. Un protocolo razonable puede apoyarse en cuatro pilares: inventario, permisos, trazabilidad y revisión periódica.
Inventario: saber qué MCP tienes y para qué
Guías de gobernanza MCP recomiendan mantener un registro central de todos los servidores MCP, qué herramientas exponen, quién los usa y para qué.
Para un equipo de accesibilidad, ese inventario podría incluir:
- Nombre del MCP (p.ej. “A11y MCP – axe-core testing”, “Web Accessibility MCP Server”).
- Función principal (testing de accesibilidad, simulación de color, navegación E2E, etc.).
- Entorno al que apunta (dev, stage, prod).
- Origen (proveedor oficial, repositorio open source, servidor interno).
- Responsable interno (quién lo propone, quién responde).
- Estado (en pruebas, aprobado, en retirada).
Sin este inventario, es muy fácil que un MCP se quede “pegado” a un flujo por inercia y nadie recuerde qué hace exactamente.
Permisos mínimos: no dar más de lo necesario
Los documentos de buenas prácticas de MCP insisten en aplicar el principio de mínimo privilegio: cada server debería tener sólo los permisos imprescindibles para su función.
Traducción práctica para accesibilidad digital:
- Un MCP que sólo necesita leer páginas para analizarlas no debería poder modificar contenido ni código.
- Si va a lanzar pruebas sobre entornos reales, mejor que lo haga sobre dev/stage, no sobre producción.
- Los tokens y claves que usa deberían estar aislados y gestionados como secretos, no incrustados en configs abiertas.
En otras palabras: trata a tu MCP de accesibilidad como tratarías a un scanner de seguridad o de cumplimiento, no como a un script de prueba rápida.
Trazabilidad: registrar qué hacen tus MCP
Los análisis de seguridad alrededor de MCP recomiendan registrar prompts, llamadas a herramientas y resultados al menos a nivel agregado, para poder hacer auditoría a posteriori.
En accesibilidad, esa trazabilidad sirve para dos cosas:
- Seguridad y cumplimiento: saber qué se ha analizado, desde dónde y con qué credenciales.
- Calidad metodológica: poder revisar qué tests se han ejecutado realmente, con qué parámetros y qué se hizo con los resultados.
Un enfoque práctico:
- Logear qué MCP se llamó, con qué herramienta (
check_accessibility,simulate_colorblind, etc.) y sobre qué URL o recurso.[mcpservers] - Guardar ejemplos de interacción donde el MCP devolvió resultados clave para un informe o decisión.
- Revisar estos logs cuando algo no encaja con la experiencia manual o con el feedback de usuarios.
Revisión periódica: MCP no es “instalar y olvidar”
Los textos sobre gobernanza MCP hablan de la necesidad de revisar periódicamente qué servers siguen siendo necesarios, cuáles se han quedado obsoletos o introducen riesgo innecesario.
Para un equipo de accesibilidad digital, eso puede traducirse en:
- Evaluar si el MCP sigue aportando valor (p.ej. si A11y MCP se actualiza con nuevas reglas o si otros flujos ya cubren mejor esas pruebas).
- Comprobar si ha introducido falsos positivos/negativos sistemáticos que estén sesgando las auditorías.
- Revisar si han aparecido alternativas más robustas o integraciones oficiales mejores.
Si un MCP deja de ser útil o se convierte en fuente de ruido y riesgo, debería tener un plan de retirada, igual que cualquier otro componente crítico.
Cómo usar MCP para accesibilidad sin desprofesionalizar la auditoría
Bien utilizados, los MCP pueden hacer que los agentes sean una interfaz mucho más cómoda hacia herramientas que ya conoces: axe-core, simulaciones de color, Playwright, etc.
Eso permite dedicar menos tiempo a lanzar comandos y más tiempo a interpretar resultados, priorizar barreras y diseñar remediaciones realistas.
Un patrón sano puede ser:
- Usar MCP para ejecutar las pruebas técnicas (contraste, roles, headings, ARIA, color, etc.).
- Dejar que el agente, con esos datos, te ayude a agrupar y explicar hallazgos.
- Mantener tú el control sobre:
- qué pruebas adicionales haces manualmente,
- qué importancia le das a cada hallazgo,
- cómo se refleja todo eso en el informe y en las decisiones posteriores.
El MCP te ahorra clicks, no responsabilidad.
Checklist rápido “MCP-friendly” para accesibilidad digital
Antes de enchufar un MCP a tu flujo de accesibilidad, puedes pasar por este mini‑checklist:
- ¿Sé exactamente qué hace este MCP y qué herramientas expone? (p.ej.
check_accessibility,simulate_colorblind,axe_scan). - ¿En qué entorno corre y con qué permisos? ¿Puede sólo leer, o también escribir/cambiar cosas?
- ¿Está registrado en algún inventario interno con responsable claro y propósito definido?
- ¿Estamos logeando llamadas y resultados de forma suficiente como para auditar su uso?
- ¿Hemos probado sus resultados frente a nuestros casos de referencia y nuestra experiencia manual?
- ¿Sabemos cómo retirarlo o limitarlo si deja de aportarnos valor o detectamos un problema?
Si la respuesta a varias de estas preguntas es “no lo tengo claro”, el problema no es el MCP en sí, sino la forma en que se está usando.
Recursos MCP útiles para accesibilidad digital
Para experimentar con MCP en accesibilidad, es mejor empezar por servidores y guías relativamente maduros y transparentes:
Perfecto, te dejo la lista con un único recurso por punto, tal como pides:
- Guía de Google Cloud – What is Model Context Protocol (MCP)?: Buena introducción general a MCP, casos de uso y beneficios en términos de acceso seguro a datos y herramientas.
- Security Best Practices – Model Context Protocol: Recomendaciones oficiales sobre autenticación, autorización, aislamiento y sanitización de datos en implementaciones MCP.
- MCP Server Governance Best Practices – Tyk: Guía de buenas prácticas de gobernanza MCP (inventario, políticas, control de acceso, gestión de riesgos) aplicable a cualquier dominio, incluido accesibilidad.
- The MCP Governance Gap – mcpmanager.ai: Análisis de problemas reales de “shadow MCP” y propuestas para control centralizado, monitorización y gobierno operativo.
- Web Accessibility Testing (A11y MCP) Server: MCP específico que usa Deque axe-core para dar a los modelos acceso a APIs de testing de accesibilidad web.
- Web Accessibility MCP Server: MCP con herramientas de análisis de accesibilidad y simulación de daltonismo, interesante para flujos de revisión centrados en percepción visual.
- Axe MCP Server y materiales asociados – Axe MCP Server: Digital accessibility expertise right in your AI agent: Recursos que explican cómo llevar la experiencia de testing axe al IDE y a agentes de desarrollo vía MCP.
Conectar tu agente sí, pero con contrato claro
MCP no es un lujo: es una pieza que va a estar cada vez más presente en cualquier entorno donde haya agentes y herramientas externas, incluida la accesibilidad digital, la cuestión no es si lo usas o no, sino si sabes exactamente qué está haciendo en tu nombre.
Igual que con las skills, la opción responsable no es prohibir ni abrazar sin pensar, es otra más incómoda: aceptar que necesitas MCP para que tu agente haga algo útil, pero exigirle un contrato claro. Qué puede hacer, qué no puede hacer, qué se registra, quién lo revisa y cómo se retira si deja de ser una buena idea.
Conectar tu agente a servidores MCP de accesibilidad puede ser una forma fantástica de integrar axe-core, simulaciones y pruebas E2E en tu día a día, siempre que recuerdes que, al final, la responsabilidad de lo que se hace con esos datos (y de cómo impactan en la vida de las personas que usan tus productos), sigue siendo tuya, no del protocolo.
En resumen y para terminar, no hay que probar las «cosas de IA» como pollos sin cabeza, si no pensamos en lo que estamos haciendo y planificamos el uso de estas y otras herramientas de IA, no estamos haciendo las cosas bien.
