MCP para chatbots web: conectar herramientas con OAuth y permisos

MCP aumenta la capacidad de acción de los chatbots web, pero solo con límites claros

MCP para chatbots IA no es un enchufe mágico que otorga a un chatbot web acceso indiscriminado a cualquier sistema. El Model Context Protocol describe, más bien, una interfaz común a través de la cual un modelo puede descubrir e invocar herramientas: por ejemplo, una búsqueda en una base de conocimientos, una consulta de tickets, una lógica de reservas o una verificación interna de datos de productos. Esto resulta muy atractivo para los chatbots web, ya que muchas interacciones no terminan con una simple respuesta. Los visitantes preguntan por el estado del envío, precios, canales de contacto, formularios, disponibilidad o los siguientes pasos. Sin herramientas, el bot solo puede dar explicaciones. Con herramientas, puede obtener datos relevantes o iniciar acciones preparadas de forma controlada y transparente.

Por lo tanto, la pregunta crucial no es: ¿puede un chatbot utilizar herramientas? La pregunta es: ¿qué herramientas puede ver en cada contexto, con qué token se invocan, bajo qué autorización humana se ejecutan y con qué nivel de registro se pueden auditar después? La especificación definitiva de MCP del 28 de julio de 2026 endurece precisamente estos aspectos operativos. Define el núcleo como apátrida (stateless), requiere metadatos relevantes por cada solicitud y precisa cómo se relacionan la autorización HTTP remota, OAuth, los scopes y la vinculación del público (audience binding) del token.

Qué cambia en la especificación 2026-07-28 para los equipos web

El cambio de arquitectura más importante es el núcleo apátrida (stateless core). Un servidor MCP no debe asumir que las solicitudes anteriores en la misma conexión ya han establecido un contexto, capacidades del cliente o una sesión. Todo lo necesario para el procesamiento debe incluirse en la solicitud actual. Esto es muy práctico para infraestructuras web distribuidas: las solicitudes se pueden distribuir entre distintas instancias tras balanceadores de carga, puertas de enlace edge o plataformas de workers. Sin embargo, para las implementaciones también implica: nada de suposiciones ocultas sobre sesiones de transporte, nada de permisos silenciosos procedentes de una conexión previa y nada de tratar la conversación del chat como un límite de seguridad.

Cada consulta necesita los metadatos _meta requeridos. Entre ellos destacan la versión del protocolo y las capacidades del cliente; la información del cliente resulta útil para la visualización, el registro y la depuración, pero no sirve como prueba de seguridad. Si un sitio web atiende a varias instancias de bots, idiomas o áreas de clientes, esta capa de metadatos debe validarse y registrarse deliberadamente. No sustituye a la autorización funcional, pero garantiza que el servidor interprete las solicitudes de forma correcta.

Las listas de herramientas son dinámicas, pero no arbitrarias

tools/list en la especificación actual es paginada y almacenable en caché. Las respuestas pueden incluir indicaciones de caché como ttlMs y cacheScope. Al mismo tiempo, el orden debe seguir siendo determinista mientras no cambie el conjunto subyacente de herramientas. Esto es más que un simple retoque de rendimiento: cuando los catálogos de herramientas se ordenan de forma estable, los clientes pueden almacenarlos en caché con mayor fiabilidad y los contextos de los modelos se mantienen más estables.

El matiz en la autorización es fundamental. El conjunto de herramientas puede variar en cada solicitud según la autorización presentada; por ejemplo, porque un token solo otorgue derechos de lectura sobre datos de soporte, pero no de escritura en un CRM. Sin embargo, no debe oscilar de forma aleatoria como efecto secundario de solicitudes previas en la misma conexión. Para los chatbots web, esto establece un patrón claro: el catálogo de herramientas visible se genera a partir del rol, el scope, el inquilino (tenant), el idioma, el contexto y el nivel de riesgo de la solicitud actual.

Las descripciones de herramientas no constituyen una base de confianza

Las herramientas MCP describen su nombre, sus entradas y, de forma opcional, sus salidas y anotaciones. Estos metadatos ayudan al modelo y a la interfaz de usuario a comprender la función, pero no son un ancla de seguridad. La especificación establece claramente que los clientes deben tratar las anotaciones de las herramientas como no confiables, a menos que provengan de servidores de confianza. Una herramienta que se describa a sí misma como de solo lectura debe estar construida en el servidor de tal manera que no ejecute efectos secundarios de escritura.

Esto se aplica también a los resultados estructurados. Un outputSchema ayuda a validar respuestas en lugar de enviar únicamente texto libre al modelo. A pesar de ello, los servidores deben verificar las entradas, controlar el acceso, aplicar límites de frecuencia (rate limits) y limpiar las salidas. Un chatbot web no debe incorporar los resultados de las herramientas sin filtrar en sus respuestas visibles, especialmente cuando intervienen API externas, datos de clientes o contenidos próximos a HTML.

OAuth: El servidor MCP es un recurso protegido

En MCP mediante HTTP remoto, la distribución de roles es determinante. Un servidor MCP protegido actúa como servidor de recursos OAuth (Resource Server). El cliente MCP actúa en nombre de un propietario del recurso (Resource Owner), que suele ser un usuario o una organización. El servidor de autorización (Authorization Server) interactúa con el usuario si es necesario y emite Access Tokens. El servidor MCP debe proporcionar sus Protected Resource Metadata para que los clientes puedan descubrir el Authorization Server adecuado. El Authorization Server debe ofrecer al menos uno de los métodos de descubrimiento: OAuth Authorization Server Metadata o OpenID Connect Discovery; el cliente MCP debe admitir ambos.

Para los equipos de producto, esto significa que el chatbot no debe gestionar por sí mismo contraseñas, claves de API ni tokens externos cuando se contemple un flujo OAuth. Debe guiar al usuario hacia un permiso claro, utilizar después un Access Token específico y limitar de forma visible las herramientas autorizadas con él. Para el registro de clientes se prefieren los Client ID Metadata Documents; el Dynamic Client Registration solo se mantiene por compatibilidad hacia atrás y está obsoleto (deprecated). Esta separación es especialmente importante en integraciones como calendarios, CRM, mesas de ayuda, gestores documentales o sistemas de e-commerce, donde una misma conversación suele alternar entre consultas públicas y acciones vinculadas a una cuenta.

Los tokens deben estar vinculados al recurso de destino

La especificación de autorización actual exige Resource Indicators según el RFC 8707. El cliente debe establecer el parámetro resource en las solicitudes de autorización y de token, indicando el URI canónico del servidor MCP al que está destinado el token. El servidor MCP debe comprobar que el Access Token haya sido emitido exactamente para su recurso. Los tokens no deben transmitirse mediante query strings; deben incluirse en el encabezado Authorization.

Esta vinculación del público (audience binding) evita un atajo peligroso: un token destinado al servicio A no puede aceptarse ni reenviarse al servicio B. Por ello, los chatbots web necesitan un límite de token limpio por cada servidor MCP y por cada entorno. Las fases de vista previa (preview), pruebas (staging) y producción no deben compartir el mismo público si representan recursos distintos. Del mismo modo, un agregador que combine varios servidores MCP antes de presentarlos a un modelo no debe mezclar tokens.

Los scopes son un contrato de UX y seguridad

Los scopes deben empezar siendo reducidos. La especificación recomienda utilizar los avisos de scope de los desafíos WWW-Authenticate y permitir un flujo de elevación de permisos (step-up flow) cuando falten derechos. En la práctica, esto significa que un visitante puede empezar a trabajar con herramientas de solo lectura. Solo cuando una acción requiera más permisos —como crear un ticket, escribir un archivo o preparar un pedido— el sistema solicitará de forma específica la autorización adicional.

Un buen diseño de consentimiento no solo indica el nombre de la integración, sino también su impacto: ¿qué datos se leen?, ¿qué acción se está preparando?, ¿se va a guardar, enviar o modificar algo de forma permanente en un sistema externo? Para operaciones sensibles, el usuario debe ver una confirmación explícita y tener la opción de denegarla. Esto no constituye un asesoramiento jurídico individual, sino una regla de diseño técnico: los permisos deben ser comprensibles para los humanos, aplicables por los servidores y auditables en los registros.

Una arquitectura sólida para chatbots web con MCP

Una arquitectura robusta separa el modelo, la fachada de herramientas y los sistemas de destino. El chatbot web no se comunica directamente con cada proveedor externo, sino con un cliente MCP o gateway que controla la versión del protocolo, las capacidades del cliente, el estado de autenticación, los límites de frecuencia y la observabilidad. Detrás se ubican los servidores MCP para integraciones específicas o áreas funcionales. Cada servidor declara únicamente las herramientas permitidas para la solicitud actual y vuelve a validar cada llamada.

La fachada de herramientas debe emplear nombres estables, esquemas de entrada estrictos y esquemas de salida claros. Los nombres de las herramientas deben ser lo suficientemente unívocos, especialmente cuando varios servidores ofrecen funciones similares como search, create o lookup. Al agregar herramientas, resulta útil utilizar espacios de nombres o prefijos. Los parámetros deben diseñarse para que el modelo no tenga que inventar datos confidenciales en bruto. Si un proceso abarca varias solicitudes, el servidor debe devolver un identificador (handle) explícito y de corta duración, y reautorizarlo en cada llamada posterior.

Un segundo elemento fundamental es la interfaz de usuario. Los visitantes deben ver cuando se invoca una herramienta, qué datos de entrada se envían y cuándo es necesaria una autorización. Para accesos de solo lectura suele bastar con un estado transparente. Para acciones de escritura, de pago, externas o con datos personales se requiere una confirmación más consciente. Aunque la especificación deja abiertos los patrones de interfaz, exige de forma clara que las aplicaciones permitan el control humano sobre las llamadas a las herramientas.

Lista de verificación para el despliegue de MCP en chatbots IA

1. Crear un inventario de herramientas: ¿qué sistemas se van a conectar?, ¿qué herramientas son solo de lectura?, ¿cuáles modifican datos y cuáles requieren confirmación humana?
2. Definir los scopes: segmentar los permisos según las acciones, no según los equipos internos. Una herramienta para consultar estados requiere scopes distintos a los de una herramienta para crear, modificar o enviar.
3. Verificar el descubrimiento OAuth: probar en cada entorno las Protected Resource Metadata, Authorization Server Metadata, el registro de clientes y las URI de redirección.
4. Forzar la vinculación del público: aceptar tokens únicamente para el URI canónico del servidor MCP; no reenviarlos nunca a recursos incorrectos ni incluirlos en las URL.
5. Hacer determinista tools/list: probar de forma conjunta el ordenamiento estable, la paginación, las indicaciones de caché y los filtros de autorización.
6. Mantener esquemas estrictos: validar las entradas, utilizar salidas estructuradas y desactivar por defecto la carga automática por red de referencias externas $ref; de forma opcional, permitirla solo mediante listas blancas, límites de tiempo, restricciones de tamaño y registro.
7. Diseñar las autorizaciones en la UI: hacer visibles el nombre de la herramienta, su propósito, las entradas, el sistema de destino, la elevación de scope y la opción de denegar.
8. Integrar la observabilidad: registrar el ID de solicitud, el nombre de la herramienta, el scope, la decisión, los errores, la latencia y el tipo de resultado, sin almacenar contenidos confidenciales innecesarios.
9. Practicar las rutas de error: gestionar los códigos 401, 403, tokens caducados, falta de scopes, identificadores desconocidos, tiempos de espera y permisos rechazados como estados normales del producto.
10. Comenzar poco a poco: desplegar primero una o dos herramientas de lectura de bajo riesgo y, posteriormente, añadir de forma gradual la elevación de permisos, acciones de escritura y más integraciones.

Errores típicos durante la implementación

El error más común es emitir un primer token demasiado amplio. Si un chatbot web obtiene permisos de escritura completos tras el primer inicio de sesión, cada decisión del modelo se vuelve más arriesgada. Es preferible optar por un scope inicial mínimo con elevación puntual (step-up). El segundo error consiste en diseñar un catálogo de herramientas basado en nombres de sistemas internos en lugar de intenciones del usuario. Un modelo funciona con mayor fiabilidad mediante acciones claras y bien acotadas que con endpoints genéricos multitarea.

El tercer error es no separar la confianza en el modelo de la confianza en el servidor. El modelo puede proponer una acción, pero corresponde al servidor decidir si las entradas son válidas, si el token es adecuado y si se cuenta con la autorización requerida. El cuarto error es la falta de trazabilidad. Si más adelante no está claro qué herramienta leyó o modificó qué datos con qué scope, resulta imposible gestionar el soporte o la seguridad con rigor.

Lecturas complementarias

Este artículo abarca la capa de integración de MCP: núcleo apátrida, tools/list y OAuth HTTP. Los siguientes artículos profundizan en la seguridad genérica de herramientas y su operación: Para el modelo de permisos, consulta Chatbots IA: uso seguro de herramientas con permisos y confirmaciones. Para el diseño de llamadas concretas, resulta útil Cómo diseñar llamadas a herramientas seguras en chatbots IA. Si necesitas que los resultados sigan siendo legibles por máquinas, lee Validación de respuestas estructuradas en chatbots IA. Para la supervisión y depuración en producción, la continuación técnica es Observabilidad en chatbots IA para trazas, retrieval y herramientas.

Fuentes oficiales

La base técnica procede de la especificación final de MCP 2026-07-28: la página sobre MCP Tools, la MCP Authorization, la publicación oficial The 2026-07-28 Specification y la Base Protocol Overview.

Conclusión

MCP para chatbots IA aporta un valor real cuando los equipos web no lo contemplan como una caja de herramientas abierta, sino como una capa de integración controlada. La especificación 2026-07-28 encaja perfectamente con la infraestructura web moderna: solicitudes apátridas, listas almacenables en caché, encabezados HTTP enrutables y autorización explícita por recurso. Al mismo tiempo, delimita las responsabilidades de forma clara. La oferta de herramientas debe ajustarse al token actual, las operaciones sensibles requieren control humano y cada llamada debe validarse en el servidor.

El camino más pragmático es empezar poco a poco: una herramienta de lectura, un scope acotado, un texto de consentimiento claro, una detección determinista de herramientas y registros detallados. A partir de ahí se pueden conectar nuevas herramientas sin convertir el chatbot en una caja negra. De este modo, el chatbot web no se convierte en un agente descontrolado, sino en un asistente transparente que solo utiliza los sistemas autorizados para el usuario y la tarea actuales.