Qué es MCP y en qué se diferencia de una API

MCP vs API es una comparación que se hace mucho y que no termina de sostenerse, porque no son cosas que compitan. Una API expone una capacidad. El Model Context Protocol describe capacidades de forma que un modelo de lenguaje pueda descubrirlas y usarlas por su cuenta. La mayoría de servidores MCP llaman a APIs normales por debajo.

Aun así, la pregunta de fondo es buena: qué es MCP en términos prácticos, qué cambia para tu equipo y si tenéis que construir algo. Esta es la respuesta sin evangelismo de protocolo.

Qué es MCP en una línea#

Una API está escrita para una persona que programa. Documentación, autenticación, endpoints. Alguien la lee, escribe código, y ese código se ejecuta siempre igual.

Un servidor MCP está escrito para un modelo. Anuncia sus propias herramientas, sus argumentos y lo que devuelven, para que un agente decida en tiempo de ejecución cuál llamar. Nadie programó de antemano esa secuencia concreta.

Ese descubrimiento en tiempo de ejecución es el punto entero. Es lo que permite pedirle a un asistente "saca las ventas del mes pasado de la base de datos y redacta el resumen para el consejo" sin que nadie haya construido una función de ventas-a-resumen.

Lado a lado#

Por qué ha cuajado#

Antes de MCP, cada asistente necesitaba su propia integración para cada herramienta. Cinco herramientas y tres asistentes eran quince integraciones, mantenidas por separado. Con un protocolo, cinco servidores sirven a los tres clientes, y al siguiente también.

Es una victoria aburrida de infraestructura, que es justo por lo que se ha extendido. La especificación es abierta, y el soporte abarca asistentes de escritorio, agentes de terminal como Claude Code y herramientas de IDE.

Qué significa si no programas#

Tres cosas prácticas.

Puedes conectar tus sistemas a un asistente sin montar un proyecto. Si existe un servidor para tu CRM, tu analítica o tu almacén de archivos, conectarlo es configuración, no ingeniería.

Tus prompts se acortan y tus resultados ganan precisión, porque el modelo lee datos reales en vez de lo que pegaste. Pedir "los números de este trimestre" gana a mantener una hoja de números pegados.

Cambia el modo de fallo. En lugar de "el modelo se lo inventó" obtienes "el modelo consultó lo que no era". Eso es más fácil de detectar y mucho más fácil de arreglar, pero exige que compruebes qué consultó.

Cuándo construir tu propio servidor#

Constrúyelo cuando se cumplan tres cosas a la vez:

1. Un agente necesita de verdad alcanzar un sistema interno de forma regular.
2. No existe ya un servidor que lo cubra.
3. Alguien será su dueño después del lanzamiento.

Si falla alguna, no construyas. Una exportación programada a un archivo que el agente pueda leer resuelve más problemas de los que la gente espera, y falla de forma segura.

Cuando lo construyas, mantén pequeña la superficie de herramientas. Cinco herramientas bien nombradas con descripciones claras ganan a treinta ambiguas: el modelo elige leyendo esas descripciones, así que nombrar mal produce llamadas equivocadas.

Seguridad: la parte que la gente se salta#

Un servidor MCP tiene exactamente los permisos que le diste, y los agentes los usarán. Tres reglas que aplico en cada proyecto de cliente:

Solo lectura por defecto. Todo lo que escriba, envíe o gaste necesita una razón explícita y un paso de confirmación humana.

Credenciales estrechas. Un token con alcance a un proyecto, no una clave de cuenta entera. Si el agente se ve comprometido o confundido, el radio del daño es ese alcance.

Trata como no fiables los datos devueltos. El contenido que vuelve de un servidor (una página web, un ticket, un correo) puede contener texto diseñado para dar instrucciones al modelo. Eso es inyección de prompts, y es la vía de ataque real contra agentes. Nunca dejes que un agente actúe según instrucciones encontradas en datos sin un humano en medio.

Si te llevas una sola cosa de este artículo, llévate la tercera regla.

MCP, Skills y subagentes: qué hace cada uno#

La gente los confunde constantemente:

• MCP da al agente acceso a sistemas.
• Las Claude Skills le dan procedimiento: cómo hace tu empresa una tarea.
• Los subagentes le dan paralelismo: contextos separados para trabajos separados.

Un montaje completo usa los tres: la Skill dice cómo escribir el informe semanal, MCP trae los números reales y un subagente se encarga de la investigación mientras el agente principal redacta.

Un camino de adopción sensato#

1. Conecta un servidor de solo lectura a tu asistente: analítica o tu almacén de archivos.
2. Úsalo dos semanas con preguntas reales y anota cuándo trae lo que no era.
3. Escribe una Skill que codifique el procedimiento correcto para tu petición más frecuente.
4. Solo entonces valora un servidor con escritura, con pasos de confirmación.
5. Documenta qué está conectado y quién es el dueño. Las integraciones sin documentar se convierten en riesgo sin documentar.

Veredicto#

MCP no es un sustituto de las APIs, ni un lenguaje nuevo, ni una razón para reconstruir nada. Es un adaptador estándar que convierte los sistemas que ya tienes en herramientas que un agente puede usar, y elimina el pegamento a medida que convertía cada integración en un proyecto.

Si tu equipo va hacia los agentes, la habilidad práctica no es el protocolo: es saber qué sistemas exponer, con cuánto alcance y dónde poner la comprobación humana. Eso es lo que cubre mi curso de Claude Code, y agentes de IA para empresas plantea el proceso de diseño.