MCP: conectá tu IA a tus herramientas y datos

Dejá de copiar y pegar entre la IA y tus apps: con MCP tu asistente lee tus datos y ejecuta acciones reales por vos.

Tu asistente de IA es brillante para conversar, pero por defecto vive encerrado en una caja: no puede leer tus archivos, consultar tu base de datos ni mover un dedo en tus herramientas. MCP (Model Context Protocol) es el estándar que rompe esa caja. Le da a cualquier modelo una forma única y estándar de conectarse con tus datos y tus apps para que, en vez de solo responderte, haga el trabajo. Si querés pasar de "la IA me sugiere" a "la IA lo hace", esta es la pieza que te falta.

Qué es MCP: el USB-C de la IA

MCP es un protocolo abierto que Anthropic lanzó a fines de 2024 y donó a fines de 2025 a la Agentic AI Foundation, bajo el paraguas de la Linux Foundation. Hoy no es cosa de una sola empresa: lo adoptaron OpenAI, Google, Microsoft y AWS. La analogía oficial es la mejor que hay: es el USB-C de la IA. Antes de USB-C cada dispositivo traía su propio cable; ahora hay un solo puerto para todo. MCP hace lo mismo entre los modelos y el mundo exterior: un enchufe estándar entre cualquier IA y cualquier herramienta.

En concreto hay dos piezas: clientes (la app donde chateás con la IA) y servers (piezas chicas que exponen una herramienta o una fuente de datos). Ambos hablan el mismo idioma.

[ Cliente de IA ]  <--- MCP --->  [ Server de archivos ]
 Claude, ChatGPT,                 [ Server de GitHub    ]
 Cursor, tu propia app            [ Server de tu base   ]

MCP es un solo estándar que reemplaza mil integraciones a medida: se escribe una vez y sirve para cualquier modelo que lo hable.

El problema que resuelve: de N×M a N+M

Antes de MCP, conectar modelos con herramientas era un infierno combinatorio. Cada modelo necesitaba su propio "pegamento" para cada herramienta. Cinco modelos por ocho herramientas eran cuarenta integraciones distintas, cada una hecha a mano y cada una lista para romperse cuando algo cambiaba. Eso es un problema N×M, y no escala.

MCP lo da vuelta a N+M. Cada herramienta expone un server MCP una sola vez; cada modelo aprende a hablar MCP una sola vez. Nadie más escribe pegamento.

Sin MCP:  5 modelos × 8 herramientas = 40 integraciones a medida   (N×M)
Con MCP:  5 modelos + 8 herramientas = 13 piezas estándar          (N+M)

La regla es N+M, no N×M: cada conector se escribe una vez y lo reutiliza todo el ecosistema.

Los 3 primitivos: tools, resources y prompts

Un server MCP puede exponer hasta tres tipos de cosas. Entender la diferencia es entender el 90% del protocolo:

Tools — funciones que el modelo puede ejecutar (crear una factura, mandar un mail, correr una query). Las controla el modelo: decide solo cuándo llamarlas.
Resources — datos que el modelo puede leer como contexto (un archivo, una fila de tu base, un documento). Son de solo lectura y los controla la aplicación.
Prompts — plantillas reutilizables que dispara el usuario, muchas veces como un "/comando". Las controlás vos.

Una tool se define como un contrato claro de qué recibe y qué hace:

{
  "name": "crear_factura",
  "description": "Genera una factura para un cliente y la guarda en la base",
  "inputSchema": {
    "type": "object",
    "properties": {
      "cliente_id": { "type": "string" },
      "monto":      { "type": "number" },
      "moneda":     { "type": "string", "enum": ["ARS", "USD"] }
    },
    "required": ["cliente_id", "monto"]
  }
}

Tools = el modelo actúa; resources = el modelo lee; prompts = vos disparás un flujo guardado.

Cómo conectás un server en la práctica

La parte que a todos les cuesta imaginar termina siendo un bloque de JSON. Un cliente como Claude Desktop guarda su lista de servers en un archivo de config: le agregás una entrada por cada server y listo. Este ejemplo le da a la IA acceso de archivos a una sola carpeta:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/tu-usuario/Proyectos"
      ]
    }
  }
}

En Mac ese archivo vive en ~/Library/Application Support/Claude/claude_desktop_config.json. command es qué se ejecuta para levantar el server (acá npx, que viene con Node), args son los argumentos —incluida la carpeta que le habilitás— y el nombre (filesystem) es solo la etiqueta que ves en el cliente. Guardás, reiniciás la app del todo y el server aparece disponible.

Cada server corre con permisos reales: dale acceso solo a las carpetas, tokens y bases que de verdad necesita.

Servers que ya podés usar hoy

No tenés que construir nada al arranque. Hay miles de servers ya hechos —más de diez mil públicos a mediados de 2026—. Los oficiales de referencia cubren lo básico: filesystem (archivos), git y memory. Y las propias empresas mantienen los suyos: GitHub tiene su server oficial, y hay para Postgres, Slack, Google Drive, Notion y prácticamente cualquier SaaS que uses.

Muchos ya son remotos: no instalás nada, apuntás a una URL. Así conectás el server oficial de GitHub en Claude Code:

# Server remoto oficial de GitHub (hospedado por GitHub, sin instalar nada)
claude mcp add --transport http github https://api.githubcopilot.com/mcp/

# Ver los servers conectados
claude mcp list

Antes de programar un server, fijate si ya existe: el 90% de las integraciones comunes ya están hechas y mantenidas.

Cuándo te conviene — y qué podés construir

MCP no es para todo. Si solo querés que la IA te redacte o te explique algo, no lo necesitás. Te conviene cuando querés que la IA toque herramientas y datos reales, no cuando solo tiene que charlar. El salto es de "asistente que sugiere" a "agente que ejecuta".

Casos donde brilla:

Un agente que lee tus issues de GitHub, los clasifica y te deja un resumen escrito.
Un asistente interno que consulta tu base de datos en lenguaje natural y arma el reporte.
Un flujo que revisa tu carpeta de contratos y extrae los vencimientos a una planilla.

Un ejemplo concreto de punta a punta, combinando dos servers:

Vos (en el chat):
  "Revisá los issues abiertos del repo, agrupá los bugs por módulo
   y dejame el resumen en un archivo resumen-bugs.md"

El agente, con MCP:
  1. Server de GitHub   -> lee los issues abiertos     (resource)
  2. Razonamiento       -> los agrupa y prioriza
  3. Server filesystem  -> escribe resumen-bugs.md      (tool)

Cero copiar y pegar. Vos pedís el resultado, no los pasos.

Próximo paso

Elegí una sola herramienta que ya uses todos los días —tu repo, tu Drive, tu base— y conectala con su server MCP en el cliente que tengas a mano. Con ese primer server andando vas a ver, en cinco minutos, la diferencia entre una IA que responde y una que hace. Si querés que definamos juntos qué servers le convienen a tu equipo y cómo conectarlos sin abrir un agujero de seguridad, agendá una llamada en /agenda y lo armamos sobre tu stack real.