Qué es MCP y por qué tu ERP debería hablar con la IA

Publicado el 8 de septiembre de 2026 · 7 min de lectura

Casi todas las empresas que prueban un asistente de inteligencia artificial pasan por la misma escena: la demostración es impresionante, y a la semana alguien descubre que el bot dio un precio que ya no existe. La conclusión que se saca suele ser equivocada —"la IA todavía no sirve"— cuando el problema real es de plomería: al modelo se le dio una copia de los datos, no acceso a los datos.

Las tres formas de darle datos a un modelo

Hay exactamente tres, y conviene distinguirlas porque se confunden todo el tiempo:

• Pegarlos en el prompt. Funciona para volúmenes pequeños y estables. El problema es obvio: lo que pegaste hoy es lo que el modelo sabrá siempre, y cada consulta arrastra ese texto.
• RAG (búsqueda sobre documentos). Se indexan manuales, contratos o políticas y el sistema recupera los fragmentos relevantes antes de responder. Es la herramienta correcta para texto no estructurado, y la incorrecta para un precio: nadie quiere que el valor de un repuesto salga de un PDF de hace tres meses.
• Herramientas. En lugar de darle datos, se le dan al modelo funciones que puede invocar: "buscar repuesto", "consultar estado de orden", "listar disponibilidad". Cuando alguien pregunta un precio, el modelo llama a la función y responde con lo que devolvió el sistema en ese instante.

La tercera opción es la que resuelve el caso empresarial típico. Y es justo la que MCP estandariza.

Qué es MCP, sin marketing

MCP significa Model Context Protocol. Es un protocolo abierto que define cómo un modelo de IA descubre y ejecuta herramientas expuestas por un sistema externo. Tiene dos lados:

• El servidor MCP, que construyes tú (o tu proveedor) sobre tu sistema. Declara qué herramientas existen, qué parámetros aceptan y qué devuelven.
• El cliente, que es la aplicación de IA: un bot de mensajería, un asistente de escritorio, un agente dentro de tu producto. El cliente pregunta al servidor qué sabe hacer y decide cuándo llamarlo.

Lo relevante para una empresa es lo que el estándar elimina: antes, conectar un modelo a un sistema significaba escribir una integración a la medida para cada combinación de modelo y aplicación. Con MCP se expone el sistema una vez y cualquier cliente compatible puede usarlo. Si mañana cambias de modelo o de canal, el servidor sigue sirviendo.

Cómo se ve en la práctica

Un ejemplo real: un laboratorio de reparación de dispositivos cuyos precios, sedes, clientes y órdenes viven en su propio sistema de gestión. La mayoría de los mensajes le llegan desde campañas publicitarias, a cualquier hora, y cada uno exigía que alguien consultara un precio y coordinara una cita a mano.

La solución no fue exportar el catálogo ni entrenar un modelo. Fue montar un servidor MCP delante del backend que ya existía, exponiendo diez herramientas sobre su API: siete de consulta —precios de reparación por dispositivo, sedes, tipos de equipo y de reparación, búsqueda de clientes— y tres que escriben en el sistema: registrar un cliente, dar de alta un dispositivo y crear la cita.

Ahí está el salto que casi nadie da. Un asistente que solo lee es un buscador con mejor conversación; uno que puede escribir cierra el ciclo. En este caso la cita entra al sistema como una orden real, con el técnico asignado automáticamente por especialidad y carga, y si el horario choca con otra cita el equipo recibe un aviso para decidir. El asistente no "sabe" precios: los consulta, así que un cambio en el sistema se refleja en la siguiente respuesta sin reindexar nada. Está descrito en detalle en el caso completo.

Qué se necesita para empezar

• Un sistema que se pueda consultar. Una API, una base de datos accesible o un servicio interno. Si el dato solo existe dentro de una interfaz gráfica, primero hay que exponerlo.
• Un caso de uso acotado. Tres o cuatro preguntas que tu equipo responda todos los días. No "un asistente que sepa todo de la empresa": eso es como se fracasa.
• Una decisión explícita sobre permisos. Qué puede ver el asistente, qué no, y si puede escribir o solo leer. Empezar en modo lectura es casi siempre lo correcto.
• Un canal donde ya esté la gente. WhatsApp, Telegram, el chat interno o tu propia aplicación. Un asistente en un portal nuevo que nadie visita no se usa.

Los tres errores que más vemos

Exponer demasiado de una vez. Veinte herramientas hacen que el modelo elija mal y que nadie pueda depurar por qué respondió lo que respondió. Tres herramientas bien definidas rinden más.

Confundir el problema de datos con un problema de modelo. Cambiar a un modelo más caro no arregla que la fuente esté desactualizada. Primero la conexión, después el modelo.

Automatizar decisiones con consecuencias sin revisión. Para cotizaciones en firme, pagos o respuestas contractuales, lo sensato es que la IA prepare y una persona apruebe. Sigue siendo mucho más rápido que hacerlo todo a mano.

Cuándo no conviene

Si las preguntas que responde tu equipo son pocas al mes, o si cada una requiere criterio profesional y contexto que no está en ningún sistema, esto no paga el esfuerzo. Y si el dato que haría falta hoy no existe en ninguna parte —vive en la cabeza de alguien—, el proyecto que corresponde primero no es de IA: es de registrar ese dato.

Preguntas frecuentes