Qué es MCP - y cuándo un negocio pequeño lo necesita de verdad

Ahora se dice «necesitamos MCP» como hace dos años se decía «necesitamos un chatbot». Las letras significan Model Context Protocol. La frase útil es más corta: es cómo se le permite a un agente tocar sus herramientas sin inventar la API de un artículo de 2024.

Un chatbot produce texto. Un agente elige una herramienta y la ejecuta. MCP es el enchufe entre ambos: nombres, esquemas de argumentos, resultados. Ya escribí por qué no hay que entregar la caja al modelo. Aquí falta el enchufe: cuándo esa lista de herramientas debe hablar MCP, y cuándo basta una función tipada en su propio servidor.

1. USB, no una personalidad

No se «instala MCP» como se instala ChatGPT. Se exponen herramientas por un zócalo estándar. Cualquier agente compatible - Cursor, Claude, un bot en su app Next.js - puede listar esas herramientas y llamarlas.

Ese es todo el truco. Antes cada proveedor tenía su forma de entregar una función al modelo. Ahora el zócalo es compartido. Los zócalos compartidos crían ecosistemas: registros, comandos de instalación y una oleada de productos que le venden un «gateway» antes de que tenga una sola herramienta que merezca enchufar.

2. Qué ocurre de verdad en una llamada

Tres pasos. Después puede dejar de leer los diagramas del proveedor.

• El agente pregunta al servidor qué herramientas hay. Recibe nombres y esquemas JSON. Ejemplo: create_invoice, con importe, moneda, id de cliente.
• Llama a una herramienta con argumentos que encajan en el esquema. No un párrafo. No SQL inventado.
• El servidor ejecuta su código. El modelo nunca ve la clave de Stripe. El resultado vuelve como datos que la interfaz puede mostrar.

Si eso suena a una API

Es una API, escrita para un modelo al que no se le puede confiar una shell. El protocolo es fontanería. La seguridad sigue viviendo en qué herramientas expone y cuáles esperan a una persona. Poner MCP en un servidor no hace el producto seguro. Esa frase sobre agentes la escribí este mes. Aquí vale sin una religión nueva.

3. Por qué suena tanto este agosto

Next.js 16.3 salió en estable el 3 de agosto de 2026, con un endpoint MCP en el servidor de desarrollo. Un agente de código puede leer errores, rutas y logs en vivo en vez de adivinar su App Router con la documentación del año pasado. Figma expone archivos, componentes y variables como herramientas: esa es la línea «Figma-to-code via MCP» en mi sitio, no una captura y una oración. Los registros ya tratan los servidores MCP como paquetes. Los proveedores venden gateways: un sitio para autenticar, auditar y vigilar toda una «flota» de agentes.

En una empresa de diez personas casi toda esa flota no existe. La parte útil del ruido es el zócalo. La parte cara es comprar gobierno para empleados que no ha contratado.

4. Cuándo lo necesita de verdad este mes

Cablee MCP cuando el agente deba ver un sistema vivo que ya tiene, y un prompt no lo sustituye.

• Un agente de código en un sitio Next.js: debe leer la documentación de esta versión y los errores de este proceso, no inventar APIs de caché de 2024. Qué haría en un sitio existente tras 16.3, ya lo escribí.
• De Figma a la UI en producción: el archivo es la fuente. El agente debe consultar el archivo, no un PNG del archivo.
• Varias herramientas, un agente de producto: reservas, CRM, FAQ con retrieval. Un esquema por herramienta gana a un adaptador nuevo por cada proveedor de chat.
• Ya tiene una lista blanca y un botón de confirmación. MCP no los sustituye. Impide que el modelo invente los nombres de las funciones.

5. Cuándo no debería

Un bot de FAQ con retrieval no necesita MCP. Una server action que crea una reserva desde un formulario no necesita MCP. «En la keynote dijeron que todo producto será agent-native» no es una especificación.

No compre un gateway, un registro y un navegador para agentes porque un resumen llamó a esto el momento npm. Necesita un gateway cuando hay muchos agentes, mucha gente y un auditor que preguntará quién llamó a refund a las 02:14. Hasta entonces el servidor que guarda las claves es el gateway.

No sustituya un formulario que funciona por un agente que habla MCP. El dinero debería seguir moviéndose por un formulario. Dejo al agente en el borrador y el extracto. Una persona pulsa enviar.

6. Cómo lo cablearía

Tres zócalos, no una plataforma.

• MCP de Figma en el repo que me contrataron para construir. Sigo leyendo el diff. El píxel a píxel es un estándar humano. El protocolo solo impide que el modelo invente márgenes desde una captura.
• next-devtools-mcp contra la app Next.js en marcha, para que el agente vea rutas reales y errores reales. AGENTS.md apunta a la documentación en node_modules. Ese lanzamiento ya lo cubrí.
• En el producto: una lista corta de herramientas como funciones de servidor tipadas. MCP delante si quien llama es un agente externo: Cursor, una app de escritorio, un segundo modelo. Una función normal si quien llama es su propia ruta Next.js. La misma lista blanca, la misma confirmación, el mismo registro de auditoría en ambos casos.

Las claves se quedan en el servidor

El modelo nunca sostiene Stripe. Claves de idempotencia en cobro y reserva. Un registro que pueda leer alguien que no es ingeniero: quién preguntó, qué herramienta, qué id, quién confirmó. MCP no escribe ese registro por usted. Lo escribe usted.

Conclusión: compre el zócalo, sáltese la flota

MCP es un zócalo. Se volvió ruidoso porque los zócalos crían ecosistemas, y los ecosistemas crían facturas. Un negocio pequeño lo necesita cuando un agente debe hablar con Figma, con una app Next.js en marcha o con una lista corta de sus herramientas sin inventar la API. No lo necesita como personalidad, como mejora de chatbot ni como gateway para una flota de uno.

Cableo el zócalo donde ahorra una semana y lo salto donde un formulario ya funciona. Escriba por el formulario qué sistema debe ver el agente - Figma, el sitio en marcha, el calendario de reservas - y qué acción no debe correr nunca sin una persona. No empezaremos comprándole un gateway. :)