MCP Se Está Comiendo la Economía de las APIs

Model Context Protocol está haciendo con la integración de APIs lo que REST hizo con SOAP: reemplazar la capa de integración escrita a mano por algo que un agente puede descubrir y usar por su cuenta.

La primera vez que la mayoría de ingenieros senior ve un servidor MCP, lo descartan como un wrapper alrededor de JSON-RPC. Lo es. También lo era REST sobre HTTP en 2005.

La pregunta que MCP realmente responde es la misma que REST respondió mal durante veinte años: ¿cómo expone una pieza de software sus capacidades a otra que nunca la ha visto? La respuesta de REST era "lee la documentación y escribe un cliente." Esa respuesta solo funciona si el lector es un desarrollador humano.

Las APIs REST se construyeron para humanos escribiendo código cliente. Endpoints, docs, llamadas fetch a mano en el orden correcto con los parámetros correctos. Cada integración es a medida.

Eso funciona cuando el consumidor es un desarrollador humano. Se rompe cuando el consumidor es un LLM. Un LLM no lee tu archivo Swagger y decide cuáles tres de doce endpoints encadenar. Necesita la capacidad descrita en su entrada: nombre de la herramienta, qué hace, schema de entrada, schema de salida, efectos secundarios.

MCP da exactamente esa forma. Una llamada a `tools/list` devuelve cada capacidad con un schema JSON sobre el que el modelo puede razonar en tiempo de inferencia. Sin SDK, sin generación de código, sin ticket de onboarding.

Lo que hace transformador a MCP no es ninguna característica individual. Es la composición en tiempo de ejecución.

Cuando cada servicio se expone como herramientas MCP, un agente puede descubrirlas y encadenarlas en tiempo de inferencia. Un agente de soporte lee del CRM, consulta el servicio de facturación, redacta un mensaje de Slack y abre un ticket — usando herramientas de las que se enteró hace treinta segundos. Sin integraciones hardcodeadas. Sin middleware específico del proveedor.

Esta es la filosofía Unix aplicada a los agentes. Herramientas pequeñas y enfocadas que se componen. El compositor ya no es un script de shell; es un modelo que puede razonar sobre qué herramientas combinar y en qué orden.

Hacer trivialmente fácil conectar agentes a herramientas arbitrarias también hace trivialmente fácil conectarlos a herramientas maliciosas. El envenenamiento de herramientas — cuando la descripción promete un comportamiento y la implementación hace otro — es la inyección SQL de la era MCP.

La mayoría de equipos que envían servidores MCP hoy no lo están pensando. Están enfocados en que las cosas funcionen. Cada gran crisis de seguridad en la historia de la web empezó igual.

Los equipos que ganen en la economía MCP no serán los más rápidos en enviar. Serán los que resolvieron la procedencia de herramientas, el saneamiento de salida y el sandboxing antes de tener que aprenderlo por las malas.

Si construyes software que otro software consume, ya deberías estar enviando una interfaz MCP. La economía lo obliga.

Una integración REST le cuesta a un desarrollador días. Una herramienta MCP cuesta minutos. Cuando la integración se vuelve 100 veces más barata, no obtienes 100 veces más integraciones iguales — obtienes categorías enteras de integración que antes no valían la pena. Stripe ya publica un servidor MCP. Linear también. Supabase también.

Cada SaaS eventualmente expondrá herramientas MCP. Cada servicio interno tendrá una interfaz MCP. La única pregunta real es si envías una antes que tu competidor.