APIs para agentes de IA: de MCP a endpoints personalizados

Cuando los LLM aprendieron a llamar funciones

En la era de GPT-3, interactuar con un LLM significaba darle un prompt y recibir texto como respuesta. El conocimiento del modelo era amplio, pero estático, congelado en lo que contenían los datos de entrenamiento. Podías pedirle que explicara la computación cuántica o redactara un correo electrónico, y producía texto plausible. Pero no podía consultar el clima de hoy, hacer una consulta a una base de datos ni ejecutar ninguna acción en el mundo real.

La funcionalidad que cambió esto recibe sorprendentemente poco reconocimiento. Le dio al modelo una opción entre generar texto y llamar una función. En lugar de producir siempre el siguiente token, el modelo ahora podía generar un objeto JSON estructurado que especificaba el nombre de una función y sus argumentos. El runtime ejecutaba esa función, devolvía el resultado al modelo y el modelo continuaba desde ahí. El artículo ReAct (Yao et al., 2022) formalizó esto como el bucle Thought-Action-Observation. El modelo razona sobre qué hacer, toma una acción (llama una herramienta), observa el resultado y repite. Todo agente de IA serio en 2026 funciona sobre alguna versión de este patrón.

El bucle

Claude Code, OpenClaw, Codex, Devin y decenas de otros sistemas agénticos funcionan de la misma manera. Llamar una herramienta, observar el resultado, decidir qué hacer a continuación, repetir. Simon Willison lo expresó bien: “Un agente LLM ejecuta herramientas en un bucle para alcanzar un objetivo.”

Claude Code, por ejemplo, usa un bucle maestro de un solo hilo, sin enjambre multiagente ni grafo de orquestación complejo: while(tool_call) -> execute -> feed results -> repeat.

La investigación de Anthropic sobre autonomía de agentes muestra que la duración de los turnos en Claude Code casi se duplicó en tres meses, de 25 a más de 45 minutos. Los usuarios confían cada vez más en que el bucle se ejecute por sí solo. Los datos muestran que los usuarios experimentados interrumpen con más frecuencia (pasando de la aprobación por acción al monitoreo estratégico), mientras que el propio agente pide aclaraciones más del doble de veces que los usuarios lo interrumpen.

Este patrón de bucle aparece en todas partes, tanto en agentes de programación como en bots de soporte al cliente y controladores de robótica.

Qué cuenta como una herramienta

Los LLM nos dan una libertad considerable para decidir en qué nivel de abstracción debe operar una herramienta. En un extremo, tienes endpoints de API muy específicos: “crear un contacto de HubSpot con estos 12 campos.” En el otro, tienes herramientas como “ejecutar este comando bash” o “ejecutar este código Python”, que esencialmente significan “haz lo que quieras.”

Devin funciona con tres herramientas: shell, editor de código, navegador. La herramienta principal de Claude Code también es una shell. OpenClaw usa un sistema dinámico de plugins de habilidades. La tendencia en herramientas agénticas de programación ha sido avanzar hacia menos herramientas, más generales, en lugar de muchas específicas.

Simon Willison observó que MCP “inicialmente explotó, pero luego se sintió menos central” para los agentes de programación porque bash es la herramienta universal. Los archivos y scripts son una primitiva con menos sobrecarga que las implementaciones completas de servidores MCP. Si el agente puede escribir y ejecutar código, puede hacer casi cualquier cosa sin necesitar una definición de herramienta dedicada.

Pero las herramientas de propósito general funcionan para agentes de propósito general. Para agentes de IA específicos de dominio (soporte al cliente, ventas, operaciones internas), necesitas herramientas específicas de dominio. Tu agente de soporte no debería estar escribiendo Python para consultar el estado de un pedido. Debería llamar un endpoint de API bien definido, con parámetros claros y respuestas predecibles. El diseño de tu conjunto de herramientas se convierte en una decisión de producto.

Qué significa ahora un endpoint de API

Para agentes de IA, un endpoint de API funciona como una declaración de capacidad. Publicar uno dice que tú (o tu agente de IA) ahora puedes hacer algo que antes no era posible.

Esto funciona en ambas direcciones. Un proveedor de software publica una API para que otros puedan integrarse con su producto. Pero un agente de IA también puede descubrir endpoints por su cuenta buscando documentación, leyendo especificaciones OpenAPI o literalmente buscando en Google cómo lograr una tarea.

Un servidor MCP es un paquete curado de endpoints de API con una idea preconcebida de cómo deben usarse. El creador del MCP ya tomó decisiones sobre qué endpoints exponer, cómo nombrarlos, qué parámetros mostrar y, de forma implícita, qué flujos de trabajo admitir. Esa curaduría es tanto la fortaleza (comodidad, estandarización) como la debilidad (rigidez, alcance sesgado). El servidor de Notion es un ejemplo concreto: publica 28 herramientas, y un agente de centro de ayuda necesita cuatro de ellas, divididas en dos conexiones.

Los MCP intercambian control por facilidad de uso. En 2026, la IA escribe la mayor parte del código de integración. Si un agente puede leer documentación de API y escribir la integración por sí mismo, el argumento de “facilidad de uso” a favor de MCP se debilita. La capa MCP puede importar más durante el período de transición, mientras las herramientas aún no se han puesto al día con la capacidad del modelo. La guía de Anthropic sobre patrones de diseño para el uso de herramientas es una referencia práctica para estructurar esquemas de herramientas, independientemente de si usas MCP o endpoints individuales.

Un desarrollo relacionado: llms.txt es un estándar propuesto en el que los sitios web publican un archivo /llms.txt para orientar a los modelos de IA hacia recursos de alto valor. Anthropic, Cloudflare, Docker y Stripe lo han adoptado. MCP estandariza la invocación de herramientas; llms.txt estandariza el descubrimiento de documentación. Ambos intentan hacer que la web sea más legible para las máquinas, desde ángulos distintos.

Qué es un endpoint de API en el contexto de los agentes de IA?

Un endpoint de API es una URL específica que acepta entrada estructurada y devuelve salida estructurada. Para los agentes de IA, cada endpoint representa una capacidad discreta, algo que el agente puede hacer en el mundo real. La descripción del endpoint, las definiciones de parámetros y las respuestas de error funcionan como el manual de instrucciones del agente. Cuanto mejor documentado esté el endpoint, más confiablemente podrá usarlo un agente.

A diferencia de los desarrolladores humanos, que pueden leer tutoriales y depurar de forma iterativa, un agente depende del esquema y la descripción del endpoint para hacer una sola llamada correcta. Por eso la documentación de API diseñada para el consumo por IA importa más que nunca. Solo el 24% de los desarrolladores diseña actualmente APIs pensando en agentes de IA, a pesar de que el 89% usa IA en su flujo de trabajo.

Qué es MCP (Model Context Protocol)?

MCP es un protocolo abierto introducido por Anthropic que estandariza cómo los agentes de IA se conectan a herramientas externas y fuentes de datos. Piensa en él como USB-C para IA. Un conector único que cualquier proveedor de herramientas puede implementar y cualquier agente de IA puede consumir. Un servidor MCP expone un conjunto de herramientas (esencialmente endpoints de API) con esquemas estandarizados, y un cliente MCP (el agente) puede descubrirlas y llamarlas sin código de integración personalizado. Para una explicación técnica más profunda, consulta nuestra publicación MCP explicado. Para un relato práctico de MCP en producción, consulta nuestro análisis de los desafíos reales al construir sobre el MCP de Shopify.

El espectro de control en Quickchat AI

Quickchat AI te da tres formas de equipar a un AI Agent con herramientas externas. Se ubican en un espectro que va de lo más automatizado a lo más controlado. Cada enfoque hace un intercambio distinto entre velocidad de configuración y precisión de comportamiento.

Remote MCP: conecta y empieza

Remote MCP es la forma más rápida de conectar un AI Agent a funcionalidad externa. Proporcionas una URL de servidor MCP, Quickchat AI se conecta, descubre todas las herramientas disponibles y te permite seleccionar cuáles debe usar tu agente.

Cómo configurarlo:

1. Ve a AI Actions en el dashboard de Quickchat AI
2. Haz clic en “Add Remote MCP”
3. Pega la URL de tu servidor MCP (por ejemplo, https://mcp.example.com/sse)
4. Opcionalmente, agrega un token de autenticación o headers personalizados (ambos son mutuamente excluyentes)
5. Haz clic en “Connect.” Quickchat AI descubre todas las herramientas disponibles y muestra sus nombres
6. Activa o desactiva herramientas individuales para controlar cuáles puede usar tu agente
7. Configura la marca “default tool is active” para controlar si las herramientas recién descubiertas se habilitan o deshabilitan automáticamente

Qué ocurre internamente:

Cuando haces clic en Connect, Quickchat AI autodetecta el protocolo de transporte a partir de la URL. Si la URL contiene sse, se usa transporte SSE; de lo contrario, streamable_http es el valor predeterminado. Cuando proporcionas un token de autenticación, se envía como token Bearer en el header Authorization.

El filtrado de herramientas funciona mediante un sistema de tres niveles. Cada herramienta del servidor MCP se comprueba contra dos conjuntos: las herramientas habilitadas explícitamente siempre se incluyen, las herramientas deshabilitadas explícitamente siempre se excluyen, y cualquier herramienta que no esté en ninguno de los dos conjuntos vuelve a la configuración “default tool is active” que elegiste. Esto significa que, cuando un servidor MCP agrega herramientas nuevas, tú controlas si están disponibles automáticamente para tu agente o si requieren activación explícita.

En tiempo de ejecución, cuando comienza una conversación, se cargan todas las conexiones Remote MCP activas del agente. Las herramientas se obtienen y filtran según la configuración de cada conexión, y se verifica que los nombres de herramientas sean únicos en todas las fuentes (con una advertencia si se encuentran duplicados).

El intercambio: obtienes acceso inmediato a todo lo que expone el MCP, pero tienes control limitado sobre las descripciones de herramientas, las definiciones de parámetros o cómo decide el agente usarlas. Como descubrimos al construir un AI Agent sobre el MCP de Shopify, pasar de una demo a producción requiere un ajuste cuidadoso que el enfoque empaquetado de MCP puede dificultar.

Consulta también: conecta tu agente a un servidor MCP remoto, Cómo lanzar tu Quickchat AI MCP, consideraciones de seguridad de MCP, documentación de Quickchat AI: canal MCP.

AI Actions (HTTP Request): un endpoint, control total

Una AI Action en Quickchat AI es un único endpoint de API HTTP que configuras individualmente para tu AI Agent. Mientras MCP importa un paquete de herramientas de una sola vez, cada AI Action te da control total sobre una capacidad específica. Para ver un ejemplo completo desarrollado, cuatro acciones que crean y enriquecen contactos, registran oportunidades y abren tickets en un CRM, consulta el tutorial de HubSpot AI Actions.

Configurar una AI Action:

1. Name (máx. 64 caracteres): esto se convierte en el nombre de herramienta que ve el LLM. Se normaliza a un identificador válido (por ejemplo, “Check Order Status” se convierte en Check_Order_Status)
2. Description (máx. 1,000 caracteres): este es el campo más importante. La descripción le indica al LLM cuándo usar esta herramienta. Las buenas descripciones especifican en qué circunstancias conversacionales llamarla, qué información recopilar primero del usuario y cómo se deben comunicar los resultados de vuelta
3. HTTP method: GET, POST, PATCH, DELETE o PUT
4. URL (máx. 10,000 caracteres): puede contener placeholders {{parameter_name}} para valores dinámicos
5. Headers: pares clave-valor para autenticación y tipo de contenido
6. Body items / Body JSON: cuerpo de la solicitud con inyección de parámetros
7. Query parameters: valores de la cadena de consulta de la URL
8. Parameters (máx. 10): cada uno con nombre, descripción (máx. 500 caracteres), tipo (str, int, float, bool o custom), una marca de requerido y un valor predeterminado opcional

Los placeholders {{parameter_name}} son el mecanismo clave. Cuando el LLM llama la herramienta, proporciona valores para cada parámetro basándose en el contexto de la conversación. Quickchat AI luego inyecta esos valores en las plantillas de URL, headers, cuerpo y cadena de consulta antes de hacer la solicitud HTTP. También hay cuatro variables integradas que pueden inyectarse de esta manera: scenario_id, conversation_id, conversation_channel y conversation_url.

Una AI Action configurada para consultar el estado de un pedido, con una plantilla de URL que muestra un placeholder de parámetro, headers y definiciones de parámetros.

Internamente: Quickchat AI construye dinámicamente un esquema tipado a partir de tus definiciones de parámetros para cada AI Action. Los cinco tipos admitidos (str, int, float, bool, custom) se asignan a sus equivalentes nativos, y este esquema se usa para validar las entradas del LLM antes de hacer la solicitud HTTP.

Un ejemplo de AI Action para consultar el estado de un pedido:

{
  "name": "check_order_status",
  "description": "Cuando el usuario pregunte por el estado de su pedido y haya proporcionado un número de pedido, llama este endpoint para recuperar el estado actual. Informa al usuario el estado, la fecha estimada de entrega y el número de seguimiento (si está disponible).",
  "method": "GET",
  "url": "https://api.example.com/orders/{{order_id}}",
  "headers": [
    { "name": "Authorization", "value": "Bearer YOUR_API_KEY" },
    { "name": "Content-Type", "value": "application/json" }
  ],
  "parameters": [
    {
      "name": "order_id",
      "description": "El ID de pedido proporcionado por el usuario (por ejemplo, ORD-12345)",
      "type": "str",
      "is_required": true
    }
  ]
}

Pruebas: El dashboard tiene un botón “Test” que te permite proporcionar valores de parámetros de ejemplo y ver la solicitud HTTP real (incluido un comando curl generado) y la respuesta antes de desplegar.

Consejos para escribir descripciones eficaces de AI Actions:

• Sé específico sobre cuándo debe llamarla el agente: “Cuando el usuario pregunte por el estado de su pedido y proporcione un número de pedido, llama este endpoint”
• Menciona qué información recopilar primero: “Antes de llamar, asegúrate de tener la dirección de correo electrónico del usuario y el ID del pedido”
• Describe cómo manejar la respuesta: “Si el estado es ‘shipped’, dile al usuario el número de seguimiento de la respuesta”
• Para flujos de trabajo de varios pasos, describe la secuencia en el prompt principal del sistema del agente en lugar de hacerlo en las descripciones de acciones individuales, y para pasar un valor entre acciones y condicionar la escritura a ese valor, usa Save to memory más una condición de ejecución

Un ejemplo desarrollado: para una AI Action paso a paso que registra leads, preguntas sin responder y solicitudes de demo directamente en una hoja de cálculo, consulta cómo conectar un agente de IA a Google Sheets.

Generate from Text: deja que la IA lo resuelva

La tercera opción es para usuarios que saben qué quieren que haga su agente, pero no saben qué endpoint de API (o incluso qué servicio) usar.

Cómo funciona:

1. Escribes una descripción en lenguaje natural de lo que quieres, por ejemplo, “Quiero que mi AI Agent pueda encender el Tesla de un usuario cuando lo pida”
2. Quickchat AI envía esto a un LLM con la herramienta web_search habilitada
3. El modelo investiga la web para encontrar la API adecuada, lee la documentación oficial y genera una especificación completa de AI Action, incluidos URL, método, headers, parámetros y requisitos de autenticación
4. El resultado vuelve con la configuración completa de la acción, citas a la documentación usada y un mensaje explicativo que señala supuestos y vacíos
5. Tú revisas, completas tus credenciales y activas

Ingreso de una descripción en lenguaje natural de la capacidad deseada.

La configuración de AI Action generada, con citas a la documentación de API usada.

La generación automatizada de AI Actions se estructura alrededor de tres prioridades:

• Prioridad 1: entender la intención. Identificar la capacidad exacta que quiere el desarrollador y el endpoint de API específico que la proporciona
• Prioridad 2: fundamentar en documentación. Usar búsqueda web para encontrar documentación oficial del proveedor, no suposiciones
• Prioridad 3: diseñar semántica orientada primero a la conversación. El nombre y la descripción generados deben tratar sobre cuándo en una conversación se usa esta herramienta, no solo sobre lo que hace técnicamente la API

El prompt usa dos convenciones de placeholders. {{param}} marca parámetros de tiempo de ejecución que el LLM completa desde el contexto de la conversación. [[secret_name]] (corchetes dobles) marca constantes del desarrollador, como claves de API e IDs de cuenta, que deben configurarse manualmente antes de la activación. Cada nombre de parámetro debe aparecer como un placeholder {{that_exact_name}} en algún lugar de la definición de la solicitud, y no se permiten placeholders huérfanos.

El sistema usa una política fail-closed. Si el modelo no puede confirmar una pieza crítica de información a partir de la documentación (el método HTTP, la URL, el esquema de autenticación o la estructura de payload requerida), no se crea ninguna acción. En su lugar, el sistema devuelve una explicación concisa de lo que falta en vez de adivinar.

Aquí es donde el punto filosófico sobre agentes de IA que descubren APIs se conecta con una funcionalidad concreta del producto. La funcionalidad Generate from Text es literalmente un agente de IA (un LLM con búsqueda web) construyendo una definición de herramienta para otro agente de IA (el agente de Quickchat AI que la usará en conversaciones).

Un ejemplo desarrollado: para el tutorial completo que convierte dos frases escritas en dos acciones activas y probadas (una consulta del clima sin clave y una de NASA con clave, incluida la negativa fail-closed), consulta cómo conectar tu agente de IA a cualquier API en inglés simple.

En tiempo de ejecución, todos estos tipos de herramientas se ensamblan juntos. Quickchat AI recopila herramientas AI Action de solicitud HTTP, herramientas Shopify MCP, herramientas de base de conocimiento, herramientas Remote MCP, herramientas Discord y otras herramientas personalizadas en una colección para presentarla al LLM. El modelo no ve ninguna distinción entre ellas. Una herramienta Remote MCP y una AI Action configurada manualmente se ven idénticas una vez que están en la lista de herramientas.

APIs abiertas como el nuevo SEO

Si los agentes de IA van a descubrir y usar APIs de forma autónoma, entonces tener una API bien documentada y fácil de usar se convierte en un activo de distribución. Gartner predice que más del 30% del aumento de la demanda de APIs provendrá de agentes de IA para 2026.

Las empresas que tienen APIs abiertas con barreras mínimas de credenciales pueden descubrir que sus APIs se convierten en su mejor canal de adquisición. En lugar de impresiones de búsqueda de Google, las “impresiones” son agentes de IA que eligen usar tu servicio en lugar del de un competidor.

La misma lógica aplica un nivel más arriba. Un agente de IA que responde desde tu documentación puede ser expuesto como un servidor MCP que ChatGPT, Claude y Cursor llaman como herramienta, lo que hace que tu conocimiento, no solo tu API, sea descubrible por la web agéntica.

La calidad de tu documentación de API determina si un agente de IA puede integrarse correctamente contigo en un solo intento. Las descripciones de parámetros, los mensajes de error y las respuestas de ejemplo cumplen la misma función que las meta descripciones y los datos estructurados en el SEO tradicional. Una respuesta de error confusa o un campo requerido no documentado significa que un agente fallará, y no hay un humano del otro lado para depurarlo.

Las empresas cuyas APIs no estén documentadas o estén bloqueadas detrás de requisitos pesados de credenciales pueden volverse invisibles para la web agéntica, del mismo modo en que las empresas sin sitios web se volvieron invisibles para Google en la década de 2000.

Uso de computadora frente a APIs

Hay una inversión significativa en enseñar a los modelos de IA “uso de computadora” (hacer clic en botones, completar formularios, navegar interfaces). Anthropic, OpenAI (Operator) y proyectos de código abierto como Browser Use ofrecen versiones de esto.

Pero el uso del navegador es una solución alternativa para una API ausente. Una llamada POST /orders toma milisegundos y devuelve datos estructurados. Un agente de navegador que navega por un flujo de checkout toma minutos y puede romperse cuando un botón se mueve tres píxeles a la izquierda. Las APIs son más rápidas, más deterministas y más baratas de ejecutar.

El contraargumento es real: no existen APIs para todo. Sistemas legacy, software empresarial sin superficie de API, dispositivos físicos controlados mediante GUI. El uso de computadora cubre una brecha real en esos casos.

La mejor respuesta a largo plazo a “no tenemos una API para esto” probablemente sea construir la API en lugar de enseñar a la IA a usar la GUI. A medida que más software se escribe por agentes de IA para agentes de IA, baja el costo de construir y mantener APIs. El cálculo económico que hacía más barato scrapear una UI que construir una API está cambiando.

También hay un ángulo de seguridad. La “tríada letal” de Simon Willison describe la combinación peligrosa de acceso a datos privados + exposición a contenido no confiable + comunicación externa. Esto aplica a ambos enfoques, pero las herramientas basadas en API son más fáciles de auditar y restringir. Puedes registrar cada llamada de API, validar cada parámetro y limitar la tasa de cada endpoint. Hacer el equivalente para un agente de navegador que puede hacer clic en cualquier cosa es mucho más difícil.

Herramientas para el mundo físico

Todo lo discutido hasta ahora trata sobre software. El mismo patrón aparece en el mundo físico.

RT-2 y Gemini Robotics de Google DeepMind usan la misma arquitectura, salvo que las herramientas despachan a actuadores en lugar de APIs. El marco SPCA (Sense-Plan-Code-Act) formaliza esto para robótica: escanear el entorno, planificar el enfoque, generar código ejecutable, ejecutarlo, observar los resultados.

No existe una API para “mueve la planta de mi escritorio hacia la derecha.” Pero un robot con una cámara podría definir move_object(object_id="plant_01", direction="right", distance_cm=15) como una herramienta sobre la marcha y luego llamarla. La definición de la herramienta funciona como la interfaz entre la capa de razonamiento y la capa de ejecución física, el mismo rol que cumplen los endpoints de API en software.

La arquitectura LLM + herramientas + bucle es de propósito general. Hoy resulta más fácil implementarla en software, pero la robótica se está poniendo al día.

APIs escritas por IA, para IA

En aproximadamente dos años (2024 a 2026), hemos pasado de que la mayoría del código fuera escrito por humanos a que la mayoría del código sea escrito por IA. Es un buen momento para reconsiderar qué es un endpoint de API. Cada vez más, un endpoint es una declaración de capacidad diseñada para ser descubierta y ejecutada por máquinas, no una interfaz técnica sobre la que desarrolladores humanos leen documentación y luego integran manualmente.

Los MCP son una capa de estandarización útil, pero también son una capa de curaduría que introduce sesgo. El creador del MCP decide qué herramientas exponer y cómo enmarcarlas. Para agentes de IA en producción, ese encuadre puede no coincidir con lo que realmente necesitas. (Escribimos sobre esto en detalle al analizar los desafíos con el MCP de Shopify.)

El espectro que recorrimos en Quickchat AI Agents refleja un punto más amplio. El nivel de control adecuado depende de tu caso de uso. Remote MCP funciona bien para prototipado rápido. AI Actions individuales te dan control detallado para agentes de producción orientados al cliente. Generate from Text permite que la IA investigue la API y construya por ti la definición de la herramienta cuando todavía estás explorando.

Y en todos los niveles, el patrón subyacente es el mismo. Un LLM, un conjunto de herramientas, un bucle. Ya sean comandos bash, endpoints de API, servidores MCP o actuadores robóticos, todo son herramientas hasta el fondo.