Servidores MCP vs Function Calling: Elige Tu Arma

Es tentador. De verdad que lo es.

Cada proveedor de LLM tiene function calling ahora. OpenAI lo tiene. Anthropic lo tiene. Google lo tiene. Eliges tu favorito, lees la documentación veinte minutos, defines tus funciones como esquemas JSON y lo lanzas. Funciona. Tu demo se ve genial. Tus inversores están impresionados.

El problema es que "funciona" y "funciona a escala con múltiples proveedores" son dos declaraciones completamente distintas. La primera es una tarde de martes. La segunda es un trabajo de tiempo completo.

Cuando conectas function calling directamente a un solo proveedor, no solo estás eligiendo un vendor. Estás eligiendo su formato de esquema, sus convenciones de parámetros, su semántica de manejo de errores y su calendario de releases. Estás escribiendo código pegamento que, por definición, no es portable. Y lo haces en la capa donde la portabilidad más importa — la frontera entre tu aplicación y la inteligencia de la que depende.

La mayoría no se da cuenta hasta que necesita soportar un segundo LLM. Para entonces, el código pegamento ya hizo metástasis.

Haz este ejercicio. Ve a tu código base y cuenta las líneas que existen únicamente para traducir entre tus definiciones internas de herramientas y el formato de function calling de un proveedor específico.

¿Una integración? Quizá cien líneas. Manejable. ¿Dos integraciones? Empiezas a notar que OpenAI y Anthropic tienen opiniones sutilmente distintas sobre cómo expresar parámetros opcionales. ¿Tres? Estás manteniendo una matriz de compatibilidad. ¿Cinco? Accidentalmente construiste un framework.

Y los frameworks nunca dejan de crecer. Cada proveedor actualiza su API cada trimestre. A veces agregan funciones. A veces deprecan cosas. A veces "mejoran" el formato de esquema de maneras que rompen tus definiciones existentes en producción a las 2 AM de un sábado.

El impuesto de mantenimiento en function calling multi-proveedor no es lineal. Es combinatorio. Cada nuevo proveedor multiplica la superficie. Cada cambio de API se propaga por cada integración. Tu capa "simple" de function calling se convierte en la parte más frágil de tu stack — el archivo que todos tienen miedo de tocar.

Nadie incluye este costo en el documento de arquitectura. Nadie lo estima en la planificación del sprint. Solo... se acumula en silencio, hasta que un día te das cuenta de que la mitad de tu tiempo de ingeniería se va en mantener integraciones vivas en lugar de construir funcionalidades.

MCP no es un producto. No es la API de una startup. Es un protocolo. Esa distinción importa más de lo que la gente cree.

Cuando escribes un servidor MCP, describes tus herramientas una vez. Un esquema. Un conjunto de descripciones. Un formato de errores. Eso es todo. Cada LLM que habla MCP puede descubrir y usar tus herramientas sin que escribas una sola línea de código específico del proveedor.

Sin adaptadores. Sin matrices de versiones. Sin "if openai then formato A, elif anthropic then formato B". El protocolo es el contrato, y cualquier cliente que implementa el protocolo obtiene tus herramientas gratis.

Es el mismo patrón que hizo exitoso a HTTP. Nadie escribe una API distinta para Chrome, Firefox y Safari. Implementas el protocolo y cada cliente que lo cumple funciona. MCP hace por la integración de herramientas de IA lo que HTTP hizo por la entrega de contenido web — hace aburrida la capa de transporte para que puedas enfocarte en la capa de aplicación.

El resultado práctico es que tus definiciones de herramientas se convierten en activos en lugar de pasivos. Las escribes una vez, las pruebas una vez, las documentas una vez. Cuando aparece un nuevo proveedor de LLM, no reescribes nada. Solo lo apuntas a tu servidor MCP y funciona.

Sería deshonesto si no reconociera esto: a veces function calling es la decisión correcta.

Si estás construyendo una aplicación que solo usará un LLM, y sabes cuál, y no te estás engañando al respecto — function calling directo es más simple. Menos abstracción. Menos piezas móviles. Cambias portabilidad por inmediatez, y a veces ese intercambio vale la pena.

Si necesitas funciones específicas del proveedor que aún no tienen equivalente MCP — piensa en modos de salida estructurada, APIs de uso de computadora o comportamientos de streaming específicos — la integración directa tiene sentido. No puedes acceder a lo que el protocolo no expone.

Y si estás prototipando, si estás en la fase de "haz que funcione", function calling te lleva más rápido. MCP tiene costos de configuración inicial. Para un hackathon de fin de semana, ese costo es real.

Pero esta es la pregunta que tienes que responder con honestidad: ¿"un solo proveedor para siempre" realmente describe tu futuro? Porque en mi experiencia, las empresas que dicen "solo usaremos OpenAI" son las mismas que frenéticamente agregan soporte para Claude seis meses después cuando sus usuarios empiezan a pedirlo. Las que dicen "solo estamos prototipando" son las mismas que siguen corriendo ese prototipo en producción dos años después.

El costo de migrar de function calling a MCP sube cada día que esperas. El costo de empezar con MCP se mantiene más o menos constante.

Esto es lo que creo que la mayoría no ve: MCP y function calling no son enemigos. Son capas en el mismo stack.

Las herramientas MCP se pueden exponer como funciones a cualquier LLM que soporte function calling. El protocolo es la fuente de verdad — la descripción canónica de qué hacen tus herramientas, qué aceptan y qué devuelven. Los adaptadores de function calling se generan, no se escriben a mano. Tu servidor MCP es la fuente única; los formatos específicos de cada proveedor son proyecciones.

Esto significa que no tienes que elegir. Puedes tener MCP como tu capa de definición de herramientas y seguir usando function calling como mecanismo de entrega a cada LLM. La diferencia es que con MCP, esas definiciones de funciones se derivan de una fuente única en lugar de mantenerse independientemente por proveedor.

Aquí es hacia donde se dirige la industria, lo sepa o no. El patrón de "una descripción canónica, muchos formatos derivados" ha ganado en todos los demás dominios — esquemas de bases de datos, especificaciones de API, sistemas de tipos. La integración de herramientas de IA convergerá en el mismo patrón porque la alternativa es una carga de mantenimiento que crece más rápido que el equipo de ingeniería de cualquiera.

Las empresas que entienden esto ahora dedicarán su tiempo a construir mejores herramientas. Las que lo entiendan después dedicarán su tiempo a reescribir código pegamento. Ambos grupos terminarán en el mismo lugar. La única pregunta es cuánto tiempo desperdician llegando ahí.