MCP vs API: cuándo convertir una API en herramienta para agentes de IA

MCP vs API no es una elección excluyente. Una API es el contrato operativo que aplicaciones, servicios y SDKs usan para leer o cambiar datos. MCP es una capa de contrato, descubrimiento y transporte que presenta capacidades seleccionadas a hosts y agentes de IA. La API sigue siendo el backend; MCP es un adaptador controlado hacia él.

La API define cómo se ejecuta una operación; MCP define cómo una capacidad puede descubrirse y usarse en un flujo agentic. La identidad, política y acceso a datos deben vivir en capas confiables fuera del prompt.

Por qué conviven API y MCP

Reutilizar el cliente de dominio evita duplicar reglas. El servidor MCP valida argumentos, obtiene identidad del contexto confiable y llama a un servicio existente. Ese servicio comprueba tenant, permisos, estado y consistencia. Si cambia la API interna, el adaptador absorbe el cambio.

Una API puede tener cientos de endpoints genéricos; MCP puede publicar tres tools de alto nivel que un modelo seleccione mejor. Mantén ambos contratos: el de API protege consumidores deterministas y el de MCP protege discovery y exposición gradual.

No uses MCP como gateway universal ni como API administrativa para el modelo. Diseña una superficie pequeña de intenciones, con versión, owner y resultados validables.

Arquitectura de referencia

El flujo recomendado es host/agente → cliente MCP → servidor MCP → servicio de dominio → cliente API o repositorio → backend. En el borde MCP filtras tools, validas esquemas, aplicas límites y conectas identidad. En dominio compruebas tenant, autorización, estado y reglas.

Ejemplo TypeScript

Este ejemplo registra una tool real. El host crea el servidor con un TrustedContext cerrado por sesión; el modelo solo aporta los argumentos declarados. La identidad, tenant y capacidades no entran por el schema.

import { z } from "zod";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

const Input = {
  orderId: z.string().uuid(),
  includeLines: z.boolean().default(false),
};
type TrustedContext = Readonly<{
  subject: string; tenantId: string; capabilities: ReadonlySet<string>;
}>;

export function createServer(ctx: TrustedContext) {
  const server = new McpServer({ name: "orders", version: "1.0.0" });
  server.registerTool("read_order", {
    description: "Lee el resumen de un pedido del tenant autenticado",
    inputSchema: Input,
  }, async ({ orderId, includeLines }) => {
    if (!ctx.capabilities.has("orders:read"))
      throw new Error("capability_denied");
    const result = await ordersApi.getSummary({
      orderId, tenantId: ctx.tenantId, includeLines,
    });
    const structuredContent = {
      orderId: result.id, status: result.status, total: result.total,
      lines: includeLines ? result.lines : undefined,
    };
    return {
      structuredContent,
      content: [{ type: "text", text: JSON.stringify(structuredContent) }],
    };
  });
  return server;
}

El adaptador de sesión autentica al host y pasa un contexto cerrado; no acepta tenant, subject, scopes ni tokens del modelo. Para una tool mutante añade idempotencia ligada a la intención, política independiente y aprobación humana.

Pruebas y operación

Prueba listado de tools, schemas inválidos, campos desconocidos, capability denied, tenant incorrecto, resource inexistente y resultados parciales. Ejecuta también la API directa para demostrar las mismas reglas.

Mide latencia por capa, validaciones, denegaciones, tamaño, reintentos y timeouts. Conserva trace_id, tenant redactado, tool/version, hash de argumentos y política; nunca tokens.

Evalúa trayectorias: tool elegida, argumentos, aprobación, allowlist y manejo de errores. Versiona schemas y descripciones porque una descripción puede cambiar la selección. Usa MCP Inspector en manual y CI en casos críticos.