edwardca.dev
edwardca.dev
Overview
Después de las APIs

Systems Design Meditation · Edition 2

Después de las APIs

Por qué MCP señala una nueva capa de infraestructura

Edward Calderón

Edward Calderón

Arquitecto de Software

2 min de lectura
AIMCPDistributed SystemsSystems Architecture

Las APIs conectaron software. Los agentes introducen software que debe decidir con qué software conectarse.

Una integración tradicional comienza con conocimiento previo: una persona elige el endpoint, estudia el schema y escribe código determinista. Un agente puede necesitar descubrir capacidades, interpretar su descripción, seleccionar una y transportar contexto.

REST, RPC y los eventos siguen siendo esenciales. MCP no los reemplaza; propone una capa para presentar tools, resources y prompts a clientes guiados por modelos. La operación inferior todavía puede ser una API, una consulta o un proceso local.

El descubrimiento no es solamente un SDK más cómodo. La máquina necesita nombres y descripciones precisas, schemas que restrinjan entradas y límites de seguridad explícitos. Una descripción ambigua cambia la selección del agente y se convierte en un defecto arquitectónico.

Lo interesante no es asegurar que MCP será el protocolo final. Es observar que la interacción entre agentes y sistemas ya es importante para necesitar una capa de protocolo. El protocolo puede cambiar. La necesidad permanece.

Un ecosistema serio requiere catálogo, pero también gobierno: quién registró la herramienta, qué versión está activa, qué tenant puede verla, si descubrir implica autorización, cómo se identifica contenido no confiable y qué ocurre ante una falla parcial.

Son problemas de distributed systems. Los servicios fallan de forma independiente, los schemas evolucionan y un retry puede duplicar un efecto. La operación que el modelo percibe como atómica puede contener varias transacciones debajo.

Pensemos en un agente de operaciones con herramientas para leer telemetría, crear incidentes y cambiar capacidad. Puede descubrir las tres, pero no debe tener la misma autoridad. La lectura puede ser amplia. La creación debe ser idempotente. El cambio de capacidad necesita política más fuerte y límites numéricos. El protocolo describe; la plataforma aplica.

Los límites entre proveedores aumentan la necesidad. Una organización usará varios modelos y muchos servicios internos y externos. Los adapters únicos crean acoplamiento. Una interfaz compartida permite que cada lado evolucione con menos coordinación.

La estandarización no garantiza semántica compartida. Dos servidores pueden cumplir el protocolo y llamar `search` a operaciones completamente distintas. Procedencia, significado y confianza siguen siendo decisiones del sistema.

La arquitectura necesita capas: protocolos para descubrimiento e intercambio; identidad y política para autorización; contratos de dominio para significado; tracing y auditoría para responsabilidad; APIs y colas para ejecución confiable.

Los protocolos importan porque permiten que los sistemas evolucionen de manera independiente.