Casi todo el valor que una empresa no le está sacando a la IA se explica con una sola frase: el modelo no sabe nada de tu negocio.
Puede redactar un correo excelente. No sabe cuánto le debe ese cliente, ni qué se acordó en la junta del martes, ni si hay inventario. Así que le terminas pegando el contexto a mano, cada vez, y eso convierte una herramienta poderosa en un procesador de texto con opiniones.
MCP es lo que resuelve ese problema.
Qué es, en una frase
El Model Context Protocol es un estándar abierto para conectar modelos de IA con datos y herramientas. Lo publicó Anthropic y hoy lo usa la industria entera, incluidos sus competidores.
La analogía que mejor funciona es el USB. Antes de USB, cada dispositivo traía su propio conector y su propio driver. Conectar una impresora nueva era un proyecto. Después de USB, es enchufarla.
Antes de MCP, conectar un modelo a tu CRM era un desarrollo a la medida. Conectarlo también a tu Drive era otro desarrollo distinto. Y si cambiabas de modelo, se tiraba todo. Con MCP, cada sistema expone sus capacidades una vez, en un formato estándar, y cualquier modelo que hable el protocolo puede usarlas.
Por qué esto importa más de lo que suena
La diferencia práctica se ve en lo que puedes pedir.
Sin MCP:
«Escríbeme un correo de seguimiento para un cliente que lleva dos meses sin comprar.»
Y tú le pegas quién es, qué compró y cuándo.
Con MCP:
«Revisa qué clientes llevan más de 60 días sin comprar, míralos contra su historial, y prepárame un correo distinto para cada uno según lo que solían llevarse.»
El modelo consulta tu base, cruza, y te entrega el trabajo hecho. No es un salto de calidad en la redacción: es un salto en qué se le puede delegar.
Eso es lo que separa un chat de un agente.
Cómo funciona, sin entrar a lo técnico
Hay tres piezas:
El servidor MCP es un programa chico que se pone enfrente de un sistema tuyo —la base de datos, el ERP, el repositorio— y expone lo que se puede hacer con él en un formato que el modelo entiende. Algo como: «aquí puedes consultar facturas por cliente», «aquí puedes crear un ticket».
El cliente MCP es la aplicación donde trabaja la persona: Claude, un editor de código, un asistente interno.
El protocolo es el idioma común entre los dos.
Lo importante: tú decides qué expone cada servidor. No es “darle acceso a la IA a todo”. Un servidor puede ofrecer solo lectura de facturas y nada más. Lo que no expusiste, no existe para el modelo.
Qué se conecta en la práctica
De lo que hemos implementado, esto es lo que más rinde:
- Bases de datos internas. Consultas en lenguaje natural sobre lo que ya tienes, sin pasar por un reporte que alguien tiene que armar.
- CRM. Contexto del cliente sin salir de la conversación.
- Documentación y repositorios. Que el asistente conteste con la política real de la empresa, no con lo que se imagina.
- Herramientas de ticket y proyecto. Crear, mover y consultar sin cambiar de pestaña.
- Sistemas propios. Aquí está el mayor retorno, porque es donde vive la ventaja competitiva y donde nadie más tiene una integración lista.
Ese último punto es el que suele sorprender: el sistema viejo y feo que nadie quiere tocar suele ser el que más valor libera al conectarlo, porque es donde está la información que solo tú tienes.
Lo que hay que cuidar
MCP amplía lo que el modelo puede hacer. Eso incluye lo que puede hacer mal. Cuatro reglas que aplicamos siempre:
Permisos mínimos. El servidor MCP debe tener exactamente los permisos que necesita y ni uno más. Si solo va a leer facturas, que no pueda borrarlas. Es la misma disciplina de cualquier integración, pero aquí se olvida más seguido porque «es un asistente».
Lectura antes que escritura. Empieza con servidores que solo consultan. Cuando el equipo confíe en lo que devuelve, agregas acciones que modifican — y esas, con confirmación humana.
Registro de todo. Qué se consultó, quién lo pidió, cuándo. Si algo sale raro, quieres poder reconstruirlo.
Cuidado con lo que entra. Si el modelo lee contenido de fuera —correos, tickets, páginas—, ese contenido puede traer instrucciones escondidas que intenten que haga algo que no le pediste. No es teórico. Se mitiga con permisos acotados y con confirmación humana en cualquier acción que tenga consecuencias.
Por dónde empezar
El error clásico es arrancar con el sistema más importante y más complicado. Nuestra recomendación, en orden:
- Elige una pregunta que alguien haga cada semana y que hoy requiera que una persona busque en un sistema. «¿Cómo va la cobranza de este cliente?» es el ejemplo típico.
- Conecta solo ese sistema, solo de lectura. Una semana de trabajo, no un trimestre.
- Déjalo correr un mes con el equipo que hace esa pregunta.
- Mide cuántas veces se usó. Si se usó, agrega el siguiente sistema. Si no, averigua por qué antes de construir más.
Ese ciclo corto es la diferencia entre un proyecto que se adopta y una integración impecable que nadie abre.
Dónde encaja esto con lo demás
MCP es la plomería. Para que rinda hacen falta dos cosas más:
- Que la gente sepa qué pedirle. Un asistente conectado a todo, con un equipo que no sabe delegarle, sigue sin producir nada. Es la parte de capacitación.
- Que alguien mantenga los servidores. Son software: se actualizan, se monitorean, se rompen.
En JTech construimos servidores MCP sobre sistemas propios de nuestros clientes — incluida nuestra propia operación comercial. Si tienes un sistema donde vive información que hoy alguien consulta a mano, cuéntanos cuál es y te decimos si vale la pena conectarlo o no.