¿Qué es MCP (Model Context Protocol)?

MCP es un estándar abierto que permite a las aplicaciones de IA conectarse a herramientas y datos externos con un solo protocolo, sin integraciones a medida. Presentado por Anthropic en noviembre de 2024 y estándar de la industria en menos de un año, hace por los agentes de IA más o menos lo que un puerto común hizo por los periféricos — la frase “el USB-C de la IA” a la que todo explicador termina recurriendo. El encuadre más afilado para quien desarrolla backend: un servidor MCP es un adaptador de API. Tu backend ya sabe responder solicitudes; MCP es la forma de hacerlo descubrible e invocable por un modelo de IA, en lugar de por código de cliente escrito a mano.

Puntos clave

Un servidor MCP envolviendo un backend que ya tienes

// JavaScript / Node.js — an MCP server wrapping an existing backend API
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';

const server = new McpServer({ name: 'tasks', version: '1.0.0' });

// A tool is a described, discoverable wrapper over the API you already have
server.tool('query_tasks', { status: z.string() }, async ({ status }) => {
  const res = await fetch(`${BASE}/classes/Task?where=${q({ status })}`, {
    headers: { 'X-Parse-Application-Id': APP_ID, 'X-Parse-REST-API-Key': KEY },
  });
  return { content: [{ type: 'text', text: await res.text() }] };
});
// The agent discovers this tool at runtime and decides when to call it —
// same backend, same ACLs and rate limits; just a new kind of client.

// Flutter / Dart — Back4app Flutter SDK
// One backend, two kinds of consumers: your app via the SDK…
final tasks =
    await QueryBuilder<ParseObject>(ParseObject('Task')).query();
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

// iOS / Swift — Back4app Swift SDK
// One backend, two kinds of consumers: your app via the SDK…
let tasks = try await Task_.query().find()
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

// Android / Kotlin — Back4app Android SDK
// One backend, two kinds of consumers: your app via the SDK…
val tasks = ParseQuery.getQuery<ParseObject>("Task").find()
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

La pestaña de JavaScript es la idea completa en quince líneas: una tool query_tasks es un wrapper descrito y descubrible sobre una llamada REST que el backend ya sirve. El agente lee la descripción en tiempo de ejecución, decide cuándo la tool encaja y la llama — golpeando los mismos endpoints, ACLs y rate limits que tu app. Un nuevo tipo de cliente, no un nuevo backend.

Cómo MCP resuelve el problema de integración N×M

Antes de MCP, conectar N clientes de IA con M herramientas significaba hasta N × M integraciones a medida. Un protocolo compartido colapsa eso a N + M: cada client y cada servidor implementa MCP una vez. La arquitectura oficial nombra tres roles — el host es la aplicación de IA; crea un client por conexión; cada server aporta capacidad — sobre JSON-RPC, con stdio para servidores locales en la misma máquina y Streamable HTTP para los remotos (el transporte original HTTP+SSE ya está deprecado).

Los tres primitivos

Un único servidor de base de datos típicamente expone los tres: una tool query, un resource schema y un prompt few-shot para las solicitudes comunes — “esto es lo que sé hacer, lo que sé y cómo preguntarme”.

MCP vs. API vs. function calling

Las dos comparaciones se resuelven limpiamente. Frente a una API: MCP no la reemplaza — la envuelve, agregando descubrimiento en runtime para que el modelo elija la llamada en lugar del código de tu aplicación. Frente al function calling: el function calling es el modelo emitiendo una solicitud estructurada; MCP estandariza cómo esa solicitud se descubre y se ejecuta entre apps y proveedores. MCP agrega estandarización y portabilidad, no capacidad — todo lo que MCP hace, el function calling a medida podría hacerlo para una integración; MCP lo hace funcionar en todas partes sin reescribir.

La superficie de seguridad, con honestidad

La sección que las páginas neutrales se saltan y los vendedores de seguridad exageran. El protocolo no es la amenaza; el modelo de confianza lo es. El prompt injection entra por las salidas de las tools — un documento devuelto por una tool puede contener instrucciones que el modelo luego sigue. El tool poisoning esconde instrucciones maliciosas en la descripción de una tool, que el modelo lee antes de que cualquier humano la vea — ya catalogado por OWASP. Rug pulls: un servidor aprobado una vez puede cambiar sus definiciones de tools después. Y el riesgo silencioso: la cadena de suministro de los servidores comunitarios — existen miles, e instalar uno le concede un punto de apoyo en el contexto de tu agente. Las mitigaciones son disciplina común de seguridad aplicada a una superficie nueva: alcances de mínimo privilegio por servidor, aprobación humana para las llamadas a tools que actúan, fijar versión y mantener allow-list de los servidores confiables, autenticación de verdad en los servidores remotos y nunca entregarle a un servidor MCP credenciales más amplias de lo que la tarea exige.

La especificación hoy

MCP evoluciona rápido, y la mayoría de los explicadores se congeló a mediados de 2025 — una nota de actualidad que vale la pena mantener al día. El transporte se consolidó en Streamable HTTP (HTTP+SSE deprecado); los servidores remotos estandarizaron autenticación al estilo OAuth; revisiones recientes de la especificación avanzaron hacia un protocolo stateless, con metadatos por solicitud y descubrimiento de capacidades del lado del servidor, y deprecaron un par de funciones tempranas del client. La gobernanza es la señal mayor: a fines de 2025 el protocolo fue donado a una fundación open-source neutral — el marcador estructural de un estándar de verdad, y no de la convención de un solo proveedor. La lección práctica para quien construye: fija una versión de la spec, lee el changelog antes de actualizar y trata “MCP” como un blanco en movimiento con un núcleo estable.

Casos de uso comunes

• Agentes de código — asistentes de IDE alcanzando tu repositorio, base de datos e issue tracker mediante servidores, en vez de plugins a medida.
• Chat sobre datos corporativos — un asistente consultando sistemas internos, cada uno envuelto como un servidor MCP con permisos.
• Exposición del backend — convertir una API REST/GraphQL existente en tools invocables por agentes, sin reconstruirla.
• Automatización de escritorio y de flujos de trabajo — servidores stdio locales tendiendo el puente entre el modelo y los archivos y aplicaciones de una máquina.
• Portabilidad entre proveedores — un servidor atendiendo a cualquier host que hable MCP, para que la integración sobreviva a cualquier elección de modelo.

¿Deberías usar MCP? Matriz de decisión

Limitaciones y trade-offs

• Es un estándar en movimiento. La evolución rápida de la spec exige fijar versiones y vigilar el changelog; “soporta MCP” es una afirmación con fecha de vencimiento.
• El modelo de confianza es nuevo. Las descripciones y salidas de las tools son superficie de ataque; agentes actuando sobre servidores sin auditar son el curl \| bash de la era actual.
• Overhead por debajo del punto de cruce. Para una sola integración, MCP agrega un protocolo y un proceso de servidor donde bastaría una llamada de función.
• El descubrimiento transfiere control al modelo. La selección de tools en runtime es poderosa y menos predecible que las llamadas fijas — la auditoría y la aprobación importan más, no menos.
• Envuelve, no arregla. Un servidor MCP sobre una API mal protegida solo expone esa API a los agentes más rápido; los permisos subyacentes siguen haciendo el trabajo de verdad.

MCP en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. El encuadre del adaptador de API cae aquí con naturalidad: una app de Back4app ya expone la superficie que un servidor MCP envuelve — REST y GraphQL sobre cada clase, más funciones de Cloud Code — así que hacerla accesible a agentes es cuestión de mapear find objects, run function y read schema a definiciones de tools, como esbozan las pestañas de código. La sección de seguridad se vuelve guía concreta: dale al servidor MCP una clave con alcance limitado, nunca la master key; deja que las ACLs y los permisos a nivel de clase de la plataforma restrinjan lo que las llamadas de un agente pueden tocar, exactamente como restringen las de tu app; y pon las acciones irreversibles detrás de Cloud Functions con sus propias verificaciones, en vez de acceso crudo a las tablas. El agente se vuelve un cliente más de un backend que ya sabe decir que no.