Servidores MCP: Cómo se Conectan los Agentes de IA a Herramientas y Datos Reales

MCP sigue una arquitectura cliente-servidor. Un host MCP — una aplicación de IA como Claude Code o Claude Desktop — crea un cliente MCP dedicado para cada servidor MCP con el que habla. Un servidor que corre en tu máquina y lee archivos locales suele servir a un solo cliente por stdio, entrada y salida estándar conectadas directamente entre dos procesos. Un servidor que corre en la nube y atiende a muchos usuarios a la vez habla Streamable HTTP en cambio, así puede alcanzarse por red desde cualquier cantidad de clientes.

Debajo de ambos transportes está la misma capa de datos: mensajes JSON-RPC 2.0 que transportan un pequeño conjunto de primitivas. Un servidor puede exponer tools que el modelo puede invocar, resources que puede leer, y prompts que puede reutilizar. El protocolo en sí es stateless — cada request lleva su propia versión de protocolo y sus capacidades, así que un servidor puede vivir detrás de un balanceador de carga común en lugar de atar a un cliente a una instancia durante toda una sesión.

Nada de esto requiere el SDK de un proveedor de modelos adentro del servidor. Un servidor MCP es simplemente un programa que habla el protocolo — no sabe ni le importa qué aplicación de IA termina llamándolo.

Sin un protocolo compartido, cada combinación herramienta-asistente es su propia integración: su propio flujo de autenticación, su propia forma de request, su propia documentación que queda vieja apenas alguno de los dos lados cambia algo. Construís para un asistente y el segundo necesita el mismo trabajo de nuevo — el esfuerzo escala con la cantidad de combinaciones, no con la cantidad de herramientas.

MCP reduce eso a una sola relación de cada lado. Un equipo que construye un producto publica un servidor MCP para él. Un equipo que construye una aplicación de IA publica un cliente MCP. Cualquier servidor construido según la spec funciona con cualquier cliente construido según la spec, así que quien construye la herramienta y quien construye la aplicación de IA nunca tienen que coordinar directamente.

Esa es toda la propuesta: no un modelo más inteligente, sino un estándar lo suficientemente aburrido como para que nadie tenga que seguir reinventando el cableado entre los modelos y los sistemas que necesitan tocar.

Un servidor MCP puede ofrecerle a un cliente cuatro tipos de cosas. Tres viven en el servidor; la cuarta deja que el servidor le pida algo al cliente en medio de una llamada:

Dos capacidades que antes vivían en esta lista, sampling y logging, están deprecadas en la spec actual. Los servidores nuevos se integran directamente con la API de un proveedor de modelos cuando necesitan una completion, y loguean a stderr o a OpenTelemetry en lugar de enrutar los logs por el protocolo.

El SDK de TypeScript es el camino más rápido a un servidor funcionando. Instalalo junto con Zod, que el SDK usa para los schemas tipados de las tools:

npm init -y
npm install @modelcontextprotocol/server zod
npm install -D @types/node typescript

Creá el servidor y registrá una tool. registerTool recibe un nombre, una descripción y un input schema, y un handler — lo que devuelve el handler se convierte en el resultado de la tool para el modelo:

import { McpServer } from '@modelcontextprotocol/server';
import * as z from 'zod/v4';

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

server.registerTool(
  'get_forecast',
  {
    description: 'Get the weather forecast for a city',
    inputSchema: z.object({
      city: z.string().describe('City name, e.g. "Buenos Aires"'),
    }),
  },
  async ({ city }) => {
    const forecast = await fetchForecast(city);
    return { content: [{ type: 'text', text: forecast }] };
  },
);

Por último, conectá el servidor a un transporte y corrélo. Para un servidor local que un proceso host lanza y con el que habla por stdio, es así:

import { StdioServerTransport } from '@modelcontextprotocol/server/stdio';

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

main();

Eso ya es un servidor completo y funcionando. Todo lo que sigue desde acá — más tools, resources, prompts, manejo de errores real — se construye sobre las mismas tres piezas: una instancia de servidor, capacidades registradas, y un transporte.

Un servidor local por stdio está bien para herramientas que solo van a correr en la misma máquina que el cliente — un servidor de filesystem, un helper local de git. En el momento en que una herramienta necesita compartirse entre un equipo o alcanzarse desde la web, necesita un transporte remoto en cambio: Streamable HTTP.

La forma casi no cambia. Cambiá el transporte por uno que hable HTTP, y montalo en una ruta del framework web que ya estés usando:

import { createMcpExpressApp } from '@modelcontextprotocol/express';
import { NodeStreamableHTTPServerTransport } from '@modelcontextprotocol/node';

const app = createMcpExpressApp();

app.post('/mcp', async (req, res) => {
  // Stateless: a fresh transport per request. No session to pin to an
  // instance, so this handler works behind an ordinary load balancer.
  const transport = new NodeStreamableHTTPServerTransport({
    sessionIdGenerator: undefined,
  });
  await server.connect(transport);
  await transport.handleRequest(req, res, req.body);
});

Como el protocolo es stateless, ese handler puede correr detrás de un balanceador de carga round-robin común — sin sticky sessions, sin un store de sesiones compartido, sin coordinación entre instancias. Desplegalo de la misma forma que desplegarías cualquier otro servicio HTTP: un contenedor detrás de un reverse proxy, una función serverless, lo que sea que tu stack ya haga para APIs.

Si querés que el servidor sea descubrible más allá de tu propio equipo, el MCP Registry aloja metadata de servidores públicos. Publicá el paquete a npm primero, y después usá la CLI oficial para registrarlo:

npm publish --access public

mcp-publisher init
mcp-publisher login github
mcp-publisher publish

Cómo se conecta un servidor depende de dónde va a correr. Los servidores locales por stdio se cablean en un archivo de configuración; los servidores remotos por HTTP se agregan como conectores con una URL.

En Claude Desktop, los servidores locales van en claude_desktop_config.json — en macOS, ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": ["/absolute/path/to/weather-server/build/index.js"]
    }
  }
}

En Claude Code, la CLI hace el mismo trabajo sin editar JSON a mano. Agregá un servidor local con un comando, o uno remoto con una URL:

# Local server, run over stdio
claude mcp add weather -- node /absolute/path/to/weather-server/build/index.js

# Remote server, over Streamable HTTP
claude mcp add --transport http weather https://weather.example.com/mcp

claude mcp add --transport http weather --scope project https://weather.example.com/mcp

# Writes the entry to .mcp.json at the repo root — commit it so the
# whole team gets the same server. Each teammate approves it once,
# the first time they open the project.

Agregar --scope project escribe la entrada en .mcp.json en la raíz del repositorio en lugar de tu configuración personal, así que subir ese archivo le da al equipo entero el mismo servidor — Claude Code le pide a cada persona que lo apruebe la primera vez que abre el proyecto. claude mcp list muestra el estado de conexión de todo lo que está configurado.

Para un servidor remoto, tanto claude.ai como la app de chat de Claude Desktop lo soportan como Custom Connector: Settings → Connectors → Add custom connector, y después la URL HTTPS del servidor. Si el servidor requiere autenticación, Claude te guía por un flujo OAuth antes de activar la conexión, y te deja definir exactamente cuáles de sus tools tienen permiso de correr.

MCP sigue siendo un estándar joven, en evolución activa — las revisiones recientes reescribieron el núcleo del protocolo más de una vez, la más importante al eliminar el estado de sesión por completo en favor de requests autocontenidos. Las capacidades nuevas ahora se lanzan primero como extensiones opcionales en lugar de aterrizar directo en la spec central, y cada feature lleva una ventana mínima de doce meses de deprecación antes de poder eliminarse.

Vale la pena construir teniendo eso en cuenta: fijá la versión de protocolo que apunta tu servidor, leé los avisos de deprecación cuando actualizás un SDK, y tratá la spec como algo que va a seguir moviéndose debajo tuyo. Las primitivas — tools, resources, prompts — se mantuvieron estables desde el principio; lo que sigue puliéndose es el cableado alrededor de ellas.