Gestionar modelos y herramientas en el nivel de AI Gateway (vista previa)

APLICABLE A: Nivel AI Gateway (versión preliminar)

Importante

El nivel AI Gateway se encuentra actualmente en versión preliminar pública. Durante la vista previa pública, el nivel de IA Gateway está disponible en las siguientes regiones:

  • Estados Unidos - Este de EE. UU. 2
  • Europa - Suecia Central

Utiliza el nivel de servicio AI Gateway (vista previa) para gestionar los modelos y herramientas a los que recurren las aplicaciones y los agentes. Importar modelos para proporcionar un único punto final gobernado para las solicitudes de modelo. Añadir servidores MCP para exponer herramientas aprobadas a través de un punto de conexión regido por el Protocolo de Contexto del Modelo (MCP). Las aplicaciones y agentes se autentican en la pasarela con claves de acceso en tiempo de ejecución. La pasarela utiliza la autenticación del backend que configuras para cada proveedor de modelos o backend de herramientas.

Prerequisites

  • Una instancia del nivel de puerta de enlace de IA.
  • Permiso para gestionar la instancia del nivel de AI Gateway.
  • Acceso al modelo de proveedor o backend que planeas añadir.
  • Para la autenticación del back-end mediante identidad administrada, permiso para asignar el rol necesario al recurso de back-end.

Importación de modelos

Utiliza el asistente Añadir modelos para conectar el nivel de AI Gateway a Microsoft Foundry, Azure OpenAI, AWS Bedrock, Google Vertex, OpenAI, Anthropic o endpoints personalizados. La pasarela sirve a cada modelo en los puntos de conexión que admite su back-end, bajo el prefijo https://<gateway>.azure-api.net/default/models. El siguiente segmento de ruta es el formato de la API del proveedor. Por ejemplo, los modelos compatibles con OpenAI se sirven en .../default/models/openai/v1 (como /chat/completions y /responses), y los modelos Anthropic en .../default/models/anthropic/v1/messages. Los campos de conexión que requiere el asistente varían según el proveedor.

Elige Importar desde Foundry cuando tu modelo se ejecute en un recurso de Microsoft Foundry, que incluye despliegues de Azure OpenAI y Azure AI Services — el asistente detecta automáticamente los despliegues del recurso. Elige Añadir un modelo personalizado para AWS Bedrock, Google Vertex, OpenAI, Anthropic u otro endpoint compatible, donde introduzcas tú mismo los nombres del endpoint y del modelo.

Use la identidad administrada cuando el proveedor admita la autenticación de back-end de Microsoft Entra ID, como Microsoft Foundry. Asigne a la identidad de la pasarela el rol necesario en el recurso de back-end antes de la importación. De lo contrario, proporciona la clave API o el secreto del proveedor durante la importación. La puerta de enlace almacena y protege la credencial.

Los clientes hacen referencia al modelo por su nombre de modelo en el campo model:

{
  "model": "gpt-5.6-sol",
  "messages": [
    {
      "role": "user",
      "content": "Summarize the incident report."
    }
  ]
}

El model valor es el nombre del modelo dado por el modelo importado.

Nota:

Actualmente, cada nombre de modelo en la pasarela debe ser único entre todos los proveedores. La pasarela dirige cada solicitud mediante una coincidencia exacta con el valor model.

Para añadir modelos, abre la página de Modelos y selecciona Añadir modelos. Elige cómo quieres conectar.

Importación desde Microsoft Foundry

  1. Selecciona Importar desde Foundry.
  2. En Seleccionar recurso, elige la suscripción y el recurso de Foundry. El asistente enumera las implementaciones de modelos en ese recurso.
  3. En los datos del proveedor, introduce un nombre y un nombre de usuario, añade una descripción opcional y elige el método de autenticación: Identidad gestionada (recomendada, cuando disponible) o Basada en clave.
  4. Selecciona Crear. La pasarela importa las implementaciones del recurso como modelos que los autores de las llamadas solicitan por su nombre.

Nota:

Para usar la identidad gestionada, la pasarela debe tener ya configurada una identidad gestionada, y debes tener permiso para asignar el rol de Usuario de Foundry a esa identidad en el recurso de Foundry. Cuando tienes permisos suficientes, el asistente de importación te asigna el rol.

Adición de un modelo personalizado

  1. Seleccione Agregar un modelo personalizado.
  2. En Proveedor, introduce un nombre de visualización y un nombre del proveedor, y una descripción opcional.
  3. En Endpoint, introduce la URL base del endpoint, el nombre del encabezado de autenticación (por ejemplo, Authorization) y la clave API.
  4. En Models, introduce el nombre de cada modelo y selecciona sus endpoints compatibles: completaciones de chats OpenAI, respuestas OpenAI, mensajes Anthropic u Other. Selecciona Añadir modelo para cada modelo que definas.
  5. Selecciona Crear.

No hay un paso de validación separado. La pasarela configura la conexión cuando creas el proveedor. Después de añadir un modelo, puedes actualizar su autenticación o políticas, o eliminarlo cuando ya no sea necesario.

Después de añadir el modelo, envía una solicitud de prueba a través del punto final de la pasarela:

curl "https://<gateway>.azure-api.net/default/models/openai/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -H "api-key: <runtime-access-key>" \
  -d '{
    "model": "gpt-5.6-sol",
    "messages": [
      { "role": "user", "content": "Write a one-sentence status update." }
    ]
  }'

Si aún no has creado una clave de acceso en tiempo de ejecución, crea una desde la página de Llaves . Las solicitudes no necesitan credenciales directas del proveedor. Utiliza las vistas de monitorización para revisar el volumen de solicitudes, la latencia, el uso de tokens y los errores por nombre de modelo.

Paso a través de la API Anthropic Messages

Los distintos proveedores exponen diferentes formatos de API, y la puerta de enlace sirve cada uno en su propia ruta de acceso en /default/models. Los modelos Anthropic utilizan la API de Anthropic Messages en modo de paso: la pasarela conserva el formato nativo de solicitud y respuesta de Anthropic Messages y reenvía las llamadas a Anthropic en /default/models/anthropic/v1/messages. Úsalo cuando las aplicaciones ya usen el SDK de Anthropic o /v1/messages.

Para añadir un modelo Anthropic, usa Añadir modelos>Añadir un modelo personalizado:

  1. En Provider, introduzca un nombre para mostrar y el nombre del proveedor de Anthropic.
  2. En Endpoint, establece la URL base del endpoint en https://api.anthropic.com, establece el nombre del encabezado de autenticación en x-api-key, e introduce la clave API de Anthropic. El gateway almacena la clave y la inyecta en llamadas de backend.
  3. En Modelos, introduce el nombre del modelo de Anthropic que envían los clientes (como claude-fable-5) y selecciona el endpoint Mensajes de Anthropic.
  4. Selecciona Crear. La puerta de enlace sirve el paso a través de Anthropic Messages en /default/models/anthropic/v1/messages.

Los clientes llaman a la ruta de acceso de la puerta de enlace. La pasarela almacena la credencial, inyecta el x-api-key del back-end y reenvía el encabezado anthropic-version del autor de la llamada a Anthropic.

curl -X POST "https://<gateway>.azure-api.net/default/models/anthropic/v1/messages" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -H "api-key: <runtime-access-key>" \
  -d '{"model":"claude-fable-5","max_tokens":256,"messages":[{"role":"user","content":"Write a product description for a trail running backpack."}]}'

El SDK de Python de Anthropic funciona cuando hace que base_url apunte a la ruta de la pasarela. Por defecto, el SDK predeterminado envía la credencial en la cabecera x-api-key, así que pasa la clave de acceso del entorno de ejecución de la pasarela en la cabecera api-key mediante default_headers. El api_key="unused" valor solo satisface el argumento requerido del SDK; la pasarela lo ignora e inyecta la clave Anthropic almacenada del backend. Establezca model en el nombre del modelo de Anthropic.

from anthropic import Anthropic

client = Anthropic(api_key="unused", base_url="https://<gateway>.azure-api.net/default/models/anthropic", default_headers={"api-key": "<runtime-access-key>"})
message = client.messages.create(model="claude-fable-5", max_tokens=256, messages=[{"role":"user","content":"Hello"}])
print(message.content[0].text)

Valide los tiempos de espera y el control de respuestas antes de pasar a producción, especialmente si las directivas inspeccionan los cuerpos.

Agregar servidores MCP

El nivel AI Gateway permite a los equipos de plataforma publicar servidores MCP detrás de un punto de conexión MCP gobernado. El flujo de trabajo de configuración es: crear un servidor MCP, conectar uno o más backends y exponer capacidades backend seleccionadas como herramientas. Un único servidor MCP puede combinar tres tipos de backends: servidores MCP remotos (por URL), herramientas generadas a partir de una especificación OpenAPI y conectores integrados para aplicaciones SaaS comunes (más de 1.000 integraciones prediseñadas, sin servidor que alojar).

Utiliza servidores MCP cuando los agentes necesiten llamar a sistemas empresariales, herramientas para desarrolladores, almacenes de conocimiento o APIs internas. Los agentes se autentican una vez en la pasarela y no necesitan credenciales separadas para cada backend. Para cada backend, eliges cómo se autentica el gateway: ninguno, clave API, OAuth 2.0 o identidad gestionada.

Un solo servidor MCP federa uno o más backends. Cada back-end aporta herramientas, y la puerta de enlace asigna espacios de nombres a las herramientas de cada back-end con el nombre del back-end para que las herramientas con el mismo nombre de distintos back-ends no colisionen. Por ejemplo, una herramienta create_issue de un back-end llamado github se expone a los agentes bajo el espacio de nombres github, distinto de una herramienta create_issue en otro back-end.

Tipo de backend Se utiliza cuando Input Resultado de la pasarela
Servidor MCP Ya alojas un endpoint MCP remoto Dirección URL del punto de conexión MCP (SSE o HTTP transmisible) Las herramientas del servidor remoto, federadas a través del endpoint gobernado
Especificación OpenAPI Tienes una API REST que los agentes deberían llamar como herramientas Documento OpenAPI (subir, URL o pegar en línea) Herramientas MCP generadas a partir de las operaciones que selecciones
Conector integrado Necesitas una app SaaS común sin alojar un servidor Selección de conectores y configuración de conexiones Las acciones del conector, expuestas como herramientas MCP

Cada fuente aporta herramientas de forma diferente:

  • Servidor MCP — federa las herramientas desde un punto final MCP remoto que ya alojas.
  • Especificación OpenAPI — convierte las operaciones de API que seleccionas en herramientas; El resumen o descripción de la operación se convierte en la descripción de la herramienta.
  • Conector incorporado — utiliza una conexión gestionada a una aplicación SaaS como Office 365, SharePoint, GitHub o Salesforce. Los conectores OAuth solicitan consentimiento cuando configuras la conexión.

Nota:

Durante la vista previa pública, los transportes soportados, las opciones de alojamiento y los límites pueden variar según la región. Consulte los detalles de registro de la versión preliminar de su suscripción antes de mover el tráfico de producción.

Para crear un servidor MCP:

  1. En el portal de niveles de AI Gateway, selecciona servidores MCP.
  2. Selecciona Añadir servidor MCP.
  3. En Source, elige un tipo de backend para empezar: servidor MCP, especificación OpenAPI o conector integrado. Puedes añadir más servidores de backend más adelante.
  4. Dale un nombre único al backend. La puerta de enlace prefija las herramientas de ese backend con el nombre en el servidor MCP combinado.
  5. Configura el backend y elige cómo se autentica el gateway a él: Ninguno, Clave API, OAuth 2.0 o Identidad gestionada. Para Clave de API, introduzca el nombre y el valor del encabezado; los valores se cifran en reposo.
  6. Para federar más servicios detrás del mismo endpoint, añadir otro backend y repetir.
  7. Selecciona Confirmar y luego Crear.

No hay un paso separado para la prueba de conectividad. La pasarela configura y revisa cada backend cuando creas el servidor.

El gateway crea un punto final MCP que federa todos los backends seleccionados. Los clientes llaman al endpoint gobernado y se autentican con una clave de acceso en tiempo de ejecución.

Nota:

Autenticación de back-end de OAuth 2.0 (limitación de la vista previa). Para un backend que usa OAuth 2.0, se realiza un inicio de sesión interactivo para autorizar la pasarela a ese backend. La puerta de enlace no comunica al portal un estado de autorización verificado, por lo que, después de que la ventana de inicio de sesión indique que el proceso ha finalizado, confirme el resultado en el portal cuando se le solicite. El estado mostrado para el backend es autodeclarado—verifica que las herramientas del backend aparezcan en el servidor MCP y vuelve a conectarte para iniciar sesión de nuevo si no aparecen.

Los agentes llaman al servidor MCP en:

https://<gateway>.azure-api.net/default/toolservers/<server-name>/mcp

Envía la clave de acceso en tiempo de ejecución en el encabezado api-key. Apunta cualquier framework de cliente o agente compatible con MCP a esta URL. Por ejemplo, enumera las herramientas disponibles con una petición JSON-RPC tools/list :

curl "https://<gateway>.azure-api.net/default/toolservers/<server-name>/mcp" \
  -H "Content-Type: application/json" \
  -H "api-key: <runtime-access-key>" \
  -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }'

Si un sistema tiene una API REST pero no un servidor MCP, importa su descripción de OpenAPI. Selecciona las operaciones para exponer como herramientas, edita nombres y descripciones de herramientas, configura un método de autenticación backend compatible y crea el activo MCP. La puerta de enlace asigna las llamadas a herramientas a operaciones REST.

Utiliza la pasarela para los servidores MCP y centraliza:

  • Discovery — proporciona un catálogo de servidores MCP aprobados para desarrolladores y agentes.
  • Autenticación — los clientes se autentican en la pasarela. La pasarela almacena las credenciales del backend, por lo que la configuración del cliente no contiene secretos aguas arriba.
  • Exposición a herramientas — elige qué operaciones backend publica cada servidor como herramientas. En la versión preliminar, cada clave de acceso del entorno de ejecución puede acceder a todos los recursos publicados en la puerta de enlace.
  • Observabilidad — la pasarela emite métricas de uso de tokens OpenTelemetry (OTLP) para el tráfico del modelo, que puedes enviar a Application Insights u otro destino OTLP. El monitoreo del tráfico de la herramienta MCP (volumen de solicitudes, latencia y errores) está disponible en el portal cuando se utiliza Application Insights; La exportación de OpenTelemetry (OTLP) para tráfico de la herramienta MCP aún no está disponible.
  • Gobernanza — aplica las mismas políticas al tráfico MCP que usas para los modelos, como los límites de tasa y la seguridad del contenido.

Después de crear el servidor, configura el acceso en tiempo de ejecución antes de compartirlo. Añade políticas como seguridad del contenido, filtros de IP y límites de velocidad de tokens y solicitudes, aplicadas al gateway o a activos publicados específicos.