Azure App Service incorpora MCP: convierte tu API REST en herramientas para agentes sin reescribirla

Una API empresarial puede llevar años atendiendo peticiones HTTP y nunca haber sido diseñada para agentes de inteligencia artificial. ¿Hay que reescribirla para que un asistente pueda consultar datos o ejecutar operaciones? Azure App Service incorpora una alternativa: generar un servidor Model Context Protocol (MCP) directamente a partir de la especificación OpenAPI de la API existente.

La función, disponible en versión preliminar (preview) a octubre de 2026, se encuentra en el apartado AI → MCP servers del portal de App Service. Su propuesta es concreta: convertir las operaciones REST en herramientas que descubre un cliente MCP, sin desarrollar ni desplegar un servidor MCP propio.

Eso no elimina el trabajo de seguridad. Publicar herramientas para agentes no equivale a otorgarles autorización para usarlas. Veamos cómo encaja la arquitectura, qué habilita realmente Microsoft y qué conviene comprobar antes de exponer un sistema de producción.

De HTTP y OpenAPI a MCP

Model Context Protocol define una forma estandarizada de conectar clientes de IA con herramientas y fuentes externas. En este caso, el agente no obtiene acceso directo a una base de datos: utiliza herramientas que terminan invocando las rutas HTTP de una aplicación existente.

El flujo simplificado es:

Cliente o agente compatible con MCP
           |
  MCP sobre Streamable HTTP
           |
  Azure App Service /mcp
    (descubre OpenAPI)
           |
    tools/list  ·  tools/call
           |
      API REST existente
           |
  Autorización y reglas del backend
           |
     Datos y operaciones

Si la especificación define GET /orders/{id} con operationId: get_order, Azure puede ofrecer una herramienta llamada get_order. El cliente descubre esa herramienta mediante tools/list y, cuando decide usarla, invoca tools/call. El servidor integrado traduce la llamada en una operación REST.

Esto no convierte una web sin API en una API, ni genera una interfaz conversacional dentro de la aplicación. Hace falta una API REST accesible, una descripción OpenAPI válida y un cliente MCP compatible. La compatibilidad con un cliente concreto, incluido ChatGPT, debe verificarse por separado: habilitar el endpoint no crea una conexión automática.

Requisitos: dos detalles que pueden bloquear el proyecto

Microsoft documenta los siguientes requisitos para el MCP integrado:

App Service en un plan dedicado Basic o superior. No se admite en Free, Shared, Consumption ni Flex Consumption.
OpenAPI 3.0.x en JSON o YAML. La especificación OpenAPI 3.1.x no está soportada en esta preview y puede dejar la lista de herramientas vacía.

ASP.NET Core, FastAPI, NestJS y otros frameworks suelen poder generar la especificación. Si la API ya publica un archivo OpenAPI, puede reutilizarse tras comprobar su versión y contenido.

Conviene revisar los operationId: nombres claros como list_orders o get_order facilitan entender qué permite hacer cada herramienta. Si faltan, Azure crea nombres derivados del método y la ruta, normalmente menos descriptivos.

Cómo habilitarlo desde el portal de Azure

El recorrido documentado es breve:

Abrir el App Service que aloja la API.
Entrar en AI (preview) y seleccionar MCP servers.
Pulsar Create MCP server.
Indicar el identificador, la ruta del endpoint (por ejemplo, /mcp/orders), la descripción y el archivo OpenAPI 3.0.x.
Configurar y verificar la autenticación antes de permitir clientes reales; guardar y revisar las herramientas expuestas.

La especificación se guarda en el sistema de archivos de la aplicación. La ruta predeterminada es /home/data/.ai/apispec.json. Microsoft advierte que los archivos subidos desde el portal de más de 15 KB pueden truncarse si no está habilitado el acceso al sitio Kudu; para especificaciones grandes, conviene elegir un mecanismo de despliegue apropiado y validar el archivo final.

Tras la configuración, el endpoint tiene una forma semejante a:

https://mi-api.azurewebsites.net/mcp/orders

El ejemplo es ficticio; no corresponde a ningún recurso real. Además del portal, Microsoft permite configurar la propiedad aiIntegration del recurso Microsoft.Web/sites mediante Azure CLI (az rest) o Bicep. Esto ayuda a mantener la configuración en infraestructura como código.

Ejemplo de cliente: VS Code y GitHub Copilot

Un cliente que soporte servidores MCP remotos por HTTP puede configurarse con un archivo similar a .vscode/mcp.json:

{
  "servers": {
    "orders": {
      "type": "http",
      "url": "https://mi-api.azurewebsites.net/mcp/orders"
    }
  }
}

Este archivo solo indica dónde conectarse. No sustituye la autenticación, la concesión de permisos ni la validación del servidor. Cuando corresponde, el cliente debe completar el flujo OAuth y enviar un token válido.

Seguridad: el botón de MCP no crea una frontera de autorización

Este es el punto más importante para cualquier API empresarial.

1. Evita publicar todas las operaciones por defecto. La configuración ToolList usa ["*"] de forma predeterminada: todas las operaciones documentadas pueden quedar disponibles como herramientas. Una lista explícita, como ["get_order", "list_orders"], reduce la superficie expuesta y evita que nuevas rutas aparezcan automáticamente al actualizar OpenAPI. Seleccionar herramientas no equivale, por sí solo, a aplicar permisos por usuario.

2. Autentica el endpoint MCP. Microsoft recomienda App Service Authentication con un proveedor de identidad compatible, por ejemplo Microsoft Entra. Para un servidor MCP protegido se configuran la audiencia, los scopes y los metadatos de recurso protegido necesarios. El mecanismo integrado no emite tokens ni es, por sí mismo, un servidor de autorización.

3. Autoriza cada ruta REST en el backend. La documentación distingue explícitamente entre autenticar una conexión MCP y validar el token y aplicar autorización en las rutas HTTP subyacentes. Un usuario autorizado para consultar pedidos no debería poder modificarlos por haber descubierto una herramienta. No basta con comprobar que tools/list responde.

4. Diseña una primera exposición de solo lectura. Es razonable comenzar con operaciones GET seleccionadas, pero el método HTTP no demuestra por sí solo que una ruta carezca de efectos secundarios. Verifica la implementación, el aislamiento por cliente o tenant, los parámetros, la información sensible devuelta y el principio de mínimo privilegio.

5. Trata al agente y sus entradas como no confiables. Un prompt malicioso o información contaminada puede inducir llamadas indebidas. Mantén controles del lado del servidor, límites de uso, auditoría y aprobación humana antes de acciones de impacto (cancelar pedidos, emitir reembolsos o modificar precios). No coloques secretos en las descripciones OpenAPI ni en los logs.

Una mini-matriz de decisiones aclara los límites:

Control	Lo facilita Azure	Sigue bajo tu responsabilidad
Descubrimiento de herramientas	Traducción OpenAPI → MCP	Elegir qué operaciones publicar
Acceso al endpoint	Integración con App Service Authentication	Configurar identidad, OAuth, audiencia y scopes
Permisos del negocio	No resueltos por `ToolList`	Validación de tokens, roles, tenant y rutas REST
Operaciones sensibles	Se pueden filtrar	Aprobaciones, auditoría y límites
Actualizaciones de API	Recarga de especificación	Revisar cambios de contrato y nueva superficie expuesta

Límites actuales y cuándo preferir un MCP propio

Esta preview admite un servidor MCP por App Service y transporte Streamable HTTP. Genera herramientas basadas en operaciones OpenAPI; si necesitas recursos MCP, prompts MCP, flujos que combinen varias operaciones o lógica de herramientas independiente de rutas HTTP, Microsoft recomienda implementar un servidor con un SDK MCP.

También hay una distinción económica: el requisito Basic o superior implica un plan de App Service compatible, pero no permite inferir un precio total mensual ni que el consumo adicional sea gratuito. Antes de adoptar la funcionalidad, verifica el plan, el tráfico y los costos de tu despliegue.

Checklist antes de ponerlo frente a un agente

Confirmar que la API REST existe y OpenAPI es 3.0.x.
Revisar el plan de App Service y el alcance de la preview.
Mantener una lista explícita de herramientas permitidas.
Configurar autenticación, registro de cliente, audiencia y scopes.
Probar autorización real de cada ruta con identidades de distinto privilegio.
Comenzar con consultas de bajo riesgo y datos de prueba.
Verificar logs sin secretos, límites de uso, monitoreo y reversión.
Comprobar que el cliente MCP elegido realmente puede autenticarse y conectarse.

Conclusión

El MCP integrado de Azure App Service reduce la fricción de conectar APIs existentes con agentes: OpenAPI describe las operaciones, Azure publica las herramientas y un cliente compatible las utiliza. Su valor es evitar una capa de integración personalizada cuando cada herramienta equivale a una llamada REST.

La arquitectura, sin embargo, conserva una responsabilidad esencial: la API debe decidir quién puede hacer qué. Antes de pulsar «Create MCP server» en producción, vale más construir una pequeña lista segura de herramientas y probar su autorización que publicar toda la especificación por comodidad.