MCP vs function calling vs plugins: tres capas, no rivales

MCP, function calling y plugins aparecen seguido en la misma frase, como si fueran tres maneras de resolver lo mismo. No lo son. Function calling es una capacidad del modelo, los plugins son un complemento atado a un asistente puntual y MCP es un protocolo abierto que define de dónde salen las herramientas que el modelo usa. La guía que DocStar publicó este 13 de noviembre de 2026 en dev.to, republicada desde su propio blog, ordena esas capas y después muestra su propuesta: que la documentación de una API se convierta en un servidor MCP sin escribir código de servidor.

El interés práctico no es académico. Si tenés una API y querés que la usen los asistentes que tus usuarios ya tienen abiertos, la pregunta deja de ser cuál de los tres mecanismos es mejor y pasa a ser en qué capa estás trabajando. Ahí se entiende por qué no compiten entre sí.

En este artículo:

¿Cuál es la diferencia entre MCP y function calling?

Function calling es la capacidad de un modelo de pedirle a tu código que ejecute una función: definís las funciones con un JSON schema, el modelo responde cuál llamar y con qué argumentos, tu aplicación corre el código y le devuelve el resultado. MCP no reemplaza nada de eso: estandariza cómo se publican esas herramientas para que cualquier asistente compatible las descubra y las llame. Sobre eso hablamos en nuestra guía completa sobre Claude.

La documentación de OpenAI describe el tool calling, a noviembre de 2026, como una conversación de varios pasos entre la aplicación y el modelo. Funciona bien cuando sos dueño de la app y de la llamada al modelo. El problema aparece cuando un cliente quiere usar tu producto desde su propio Claude o su propio Cursor: tus funciones no están ahí, viven en tu código.

¿Qué es el Model Context Protocol y cómo funciona?

MCP es un estándar abierto para conectar aplicaciones de IA con sistemas externos. La analogía que usa el sitio oficial es la de un puerto USB-C para apps de IA: un servidor MCP lista sus herramientas y cualquier cliente compatible se conecta, las descubre y las llama. Arquitectónicamente es cliente-servidor: cada host abre un cliente por servidor, y el servidor expone tres primitivas: tools (funciones que el modelo invoca), resources (datos de contexto) y prompts (plantillas reutilizables).

Conviene una corrección de encuadre, porque muchas comparaciones arrastran un error. MCP nació en Anthropic en noviembre de 2024, pero el 9 de diciembre de 2025 fue donado a la Agentic AI Foundation, un fondo dirigido bajo la Linux Foundation cofundado por Anthropic, Block y OpenAI, con apoyo de Google, Microsoft, AWS, Cloudflare y Bloomberg. Describirlo en 2026 como “el protocolo de Anthropic” habla de una estructura de gobernanza que ya no existe. Más contexto en la comparativa entre Sonnet y Opus.

El transporte también ayuda a entender el despliegue: stdio cuando el servidor corre como proceso local, Streamable HTTP cuando corre remoto. Y las revisiones se identifican por fecha. La comparativa de julio de 2026 citaba la 2025-11-25; un análisis técnico previo, publicado en abril de 2026, describe la 2026-07-28, que elimina el handshake de inicialización y manda versión y capacidades en cada request, con un RPC server/discover obligatorio.

¿Los plugins de un asistente funcionan en otro asistente?

No. Un plugin o extensión empaqueta herramientas para un solo asistente, en el formato propio de ese asistente. Alcanza a sus usuarios, pero cada asistente nuevo implica otro build, otra revisión y otro mantenimiento. La consecuencia es la que suele subestimarse: la misma descripción de API termina escrita tres veces, como schema de función, como manifiesto de plugin y como servidor MCP.

Vale una distinción que se confunde seguido: los plugins no son lo mismo que las skills, el formato de instrucciones en Markdown publicado como estándar abierto en agentskills.io, que hoy leen clientes de distintos proveedores. Un plugin entrega herramientas; una skill entrega procedimiento. Relacionado: las diferencias entre API y MCP.

MCP, function calling y plugins: la comparación por capas

Function callingPluginsMCP
Qué esUna función del API de un modeloUn complemento de un asistenteUn protocolo abierto entre asistentes y herramientas
Quién lo cableaVos, en el código de tu appVos, en el formato de ese asistentePublicás un servidor una vez; cada cliente se conecta
Dónde corre la herramientaDentro de tu appDonde ese asistente lo espereEn tu servidor MCP
¿Funciona en otros asistentes?No, se rehace por appNo, está atado a un asistenteSí, en cualquier cliente compatible
Mejor usoUna función de IA dentro de tu productoLlegar a los usuarios de un asistente puntualQue el asistente de cada usuario use tu producto
MCP vs function calling diagrama explicativo

La lectura es simple: function calling te sirve para una función de IA dentro de tu producto; un plugin, para llegar a los usuarios de un asistente específico; MCP, para que el asistente de cada usuario use tu producto sin que vos rehagas la integración cada vez.

¿Cómo conecto Claude Code a un servidor MCP?

En Claude Code se agrega un servidor MCP desde el directorio de conectores del cliente si está listado, o como servidor MCP remoto con su URL si no lo está. No hay que compilar nada: el host abre una conexión por servidor y el modelo ve las herramientas disponibles. En el caso de DocStar la URL es https://mcp.docstar.io/mcp, y el primer uso pide iniciar sesión en el navegador en lugar de copiar una API key.

Claude Code, además, permite que un subagente declare en su frontmatter dos cosas a la vez: las skills que precarga y los servidores MCP que puede usar. Es la forma más concreta de ver que las piezas se combinan. Una skill aporta el criterio, el servidor aporta el acceso y el subagente aporta aislamiento de contexto. También vale saber que en Claude Code los comandos personalizados se fusionaron con las skills: si una skill y un comando comparten nombre, gana la skill. En la comparativa de orquestación de modelos profundizamos sobre esto.

¿Cómo hago para que mi API la puedan usar los asistentes de IA?

La vía que evita reescribir la integración por cada asistente es publicar la API como servidor MCP. Con DocStar no se escribe el servidor: se documenta la API en una colección y esa colección genera su propio servidor MCP. La guía lo plantea en cuatro pasos, pensados para que el agente de código haga el trabajo pesado y la persona se quede con la decisión.

  1. Conectar el agente (Claude Code, Cursor, Codex) a DocStar, por el directorio de conectores o como servidor remoto. El asistente trabaja con los mismos workspaces y permisos de tu cuenta.
  2. Pegar un prompt que lo mande a leer https://docstar.io/mcp/quickstart.md y a documentar cada endpoint desde el código actual, no desde un OpenAPI viejo, con descripción y un body JSON que incluya todos los campos aceptados.
  3. Dejar que el agente documente, obtenga la URL del conector, elija hasta 20 endpoints con tool propia (por ejemplo create_payment), escriba la skill y agregue instructions de menos de 2.000 caracteres. Pregunta antes de cambiar o publicar y guarda todo como borrador.
  4. Revisar: qué endpoints se publican, los nombres y descripciones de las tools, los safety hints (read-only, destructive, idempotent, open-world) y el OAuth si tu API pide usuario logueado.

El tipo de colección define qué puede hacer el asistente. En una colección de docs o blog, busca y lee páginas publicadas. En una de API docs, además lee la referencia y llama la API. Solo el contenido publicado llega al servidor: los borradores nunca se exponen. La URL final queda con la forma https://mcp.docstar.io/connector/tu_coleccion y se puede servir en un dominio propio, del tipo mcp.tuempresa.com.

El OAuth es el único paso que el agente no puede automatizar: hay que cargar authorization URL, token URL, client ID, secret y token validation URL del lado de DocStar, y sumar los redirect URIs que el panel muestra en tu app de OAuth. Todo el flujo conviene leerlo como la propuesta de un proveedor que vende ese servicio, no como una evaluación independiente.

Los límites que conviene mirar antes de decidir

  • Solo 20 endpoints tienen tool con nombre propio. El resto queda accesible por una tool general que busca en la documentación y llama. En una API grande, eso cambia bastante la calidad del uso.
  • El servidor lo hospeda un tercero. La disponibilidad y el modelo de negocio de ese proveedor pasan a ser parte de tu integración, aunque el dominio sea tuyo.
  • Un servidor MCP es tan bueno como la documentación que tiene atrás. El trabajo difícil no es el código: es que cada tool tenga nombre claro, descripción de cuándo usarla, todos los parámetros explicados y un body de ejemplo real.
  • El costo de contexto no es cero. Las definiciones de tools se cargan al inicio de la conversación y cada servidor extra grava cada conversación. El caso que cita Anthropic, de 150.000 a 2.000 tokens, es un escenario ilustrativo con muchísimas herramientas y no un benchmark: sirve por la dirección, no por el número.

¿Cómo se mantiene actualizado cuando cambia la API?

La guía propone dos caminos. El primero es GitHub Sync: los archivos OpenAPI en api-docs/ y el Markdown en docs/, con una GitHub Action que manda los cambios a DocStar en cada push, más una línea en AGENTS.md que obliga al agente a actualizar api-docs/ leyendo docstar.md en el mismo cambio de código. El segundo es pedírselo al agente después de cada modificación. Como la skill y las tools con descripción vacía siguen a la documentación, actualizar los docs actualiza lo que ven los asistentes apenas publicás.

Un criterio para verificar antes de publicar

Propuesta de esta nota, no una prueba que hayamos corrido: antes de compartir la URL, llamá un endpoint publicado desde un cliente distinto al que usaste para armar el servidor. Revisá la lista de tools expuestas y confirmá que no haya endpoints internos. Probá el OAuth con una cuenta de prueba y no con la tuya. Y anotá cada aclaración que el asistente tuvo que pedir: casi siempre es un campo que falta en el body de ejemplo.

Para decidir cuando las dudas se mezclan, sirve el test de borrar la pieza y ver qué se rompe. Si el agente directamente no puede actuar, faltaba MCP. Si actúa, pero en el orden equivocado o con un formato distinto cada vez, faltaba know-how. Y si el problema es que arrastra miles de líneas a la conversación principal, no faltaba ninguno de los dos: faltaba aislar el contexto.

Fuentes

Desplazarse hacia arriba