Tu ERP como servidor MCP: conectar Holded a un agente de IA
La primera vez que enseñas un servidor MCP sobre el ERP, la reacción suele ser buena. Alguien pregunta «¿cuánto tenemos pendiente de cobro?», la respuesta llega en tres segundos con las cifras del sistema, y en la sala hay caras de aprobación. Y entonces habla el responsable financiero: vale, ¿y quién decide qué puede ver esto, y qué puede tocar?
Esa pregunta es la que separa la demo del proyecto. Levantar un servidor MCP contra Holded es cuestión de una tarde. Que sobreviva a una auditoría, no: eso son tres requisitos que un MCP tiene que cumplir dentro de una empresa, y se deciden antes de escribir la primera línea.
Hemos montado varios en producción sobre distintos ERP. Esto es lo que hemos ido aprendiendo, incluidas las cosas que hicimos mal primero.
Qué cambia frente a una API normal
MCP es un estándar abierto para que un asistente de IA hable con sistemas externos. Expones tus datos una vez y cualquier cliente compatible los usa, en lugar de programar una integración por cada asistente.
Hasta ahí, suena a API con otro nombre. La diferencia está en quién la consume. Una API la llama un programa que hace exactamente lo que le mandaste. Un servidor MCP lo llama un modelo que decide qué invocar a partir de una frase suelta que alguien ha escrito en un chat.
Eso cambia el listón. Ya no basta con que la operación funcione: tiene que ser difícil de invocar por accidente.
Para qué sirve de verdad
Las preguntas que la gente hace todas las semanas y que hoy cuestan diez minutos de filtros y exportaciones:
- Qué facturas están pendientes de cobro y cuánto suman.
- Cuánto llevamos facturado a un cliente este año frente al pasado.
- Qué gastos recurrentes se renuevan el mes que viene.
- Qué margen deja un proyecto descontadas las horas imputadas.
- Si el cliente que acaba de llamar tiene algo vencido.
Ninguna es difícil por separado. El coste está en que cada una obliga a entrar, filtrar, exportar y cuadrar. Con MCP la respuesta aparece en la conversación, y sale del sistema, no de una hoja que alguien actualizó en marzo.
¿Y si tu ERP ya trae uno?
Cada vez más fabricantes están sacando su propio servidor MCP. Holded lanzó el suyo en junio de 2026, remoto, con OAuth y con perfiles de permisos que heredan los del usuario que pregunta. Conviene decirlo claro: si lo que necesitas es consultar tu ERP y poco más, empieza por ahí. Es lo más barato y lo mantiene otro.
La pregunta útil no es cuál es mejor. Es dónde se acaba el que viene de serie. Y se acaba en un sitio muy concreto: un MCP de fabricante ve su producto, y solo su producto.
Compara estas dos preguntas. «¿Cuánto le he facturado a este cliente este año?» la resuelve el MCP del ERP sin despeinarse. «¿Cuánto margen me deja este cliente descontando los costes que le repercuto y las horas que le hemos imputado?» vive en tres sistemas a la vez, y ninguno de ellos la puede contestar por separado.
La segunda es la que se pregunta en una reunión de dirección. Es la razón por la que acabamos construyendo el nuestro, y no porque el de nadie estuviera mal: es que lo que nos preguntábamos cruzaba varios sistemas a la vez.
Hay un segundo caso donde el nativo se queda corto, y es cuando trabajas sobre las cuentas de varios clientes en lugar de sobre la tuya. Ahí necesitas aislamiento entre clientes, y eso no tiene por qué resolverlo una herramienta pensada para «tu cuenta».
Si tu caso es el primero, usa lo que ya tienes y ahórrate el proyecto. Si es alguno de los otros dos, lo que viene ahora te interesa.
Solo lectura, y en serio
Un servidor MCP sobre el ERP tiene que nacer sin poder escribir. Consultar, listar y resumir cubren casi todo el valor y no rompen nada. Crear una factura o cancelar una licencia son operaciones con consecuencias contables, y un modelo que ha malinterpretado una frase ambigua no debería poder provocarlas.
Cuando la escritura hace falta, permitirla no es suficiente. Las operaciones de escritura necesitan una confirmación que el modelo no pueda fabricar por su cuenta, algo que se decide fuera de la conversación. Si falta, la operación no se ejecuta. Un malentendido nunca acaba en un asiento contable.
Identidad real, no una clave compartida
La vía rápida es darle al servidor una clave de API del ERP y que actúe siempre como el mismo usuario. Funciona en diez minutos y es un error caro.
Con ese diseño, cualquiera que llegue al asistente ve todo lo que ve esa clave. El comercial nuevo puede preguntar por las nóminas. Y el registro de auditoría, si lo hay, dice que la consulta la hizo «el integrador», que no le sirve a nadie.
Lo correcto es autenticar a cada persona con la identidad corporativa que ya tienes, normalmente Microsoft Entra ID, y que el servidor aplique los permisos de esa persona concreta. El comercial ve su cartera, el financiero ve la cuenta entera, igual que dentro del ERP. El patrón general está en la documentación de la plataforma de identidad de Microsoft, y no tiene mucho misterio salvo que hay que hacerlo desde el principio: retrofitear identidad en un servidor que nació con clave fija es rehacerlo.
Herramientas escritas para que un modelo acierte
Esto lo subestimamos nosotros al principio. El modelo elige qué herramienta llamar leyendo su nombre y su descripción, así que esos textos no son documentación: son el interfaz. Escribirlos mal se paga en llamadas erróneas.
Lo que nos ha funcionado, después de bastantes iteraciones:
- Nombrar por dominio y no por tabla. Una herramienta que resuma la situación financiera de un cliente vale más que cinco que devuelvan trozos.
- Avisar de las trampas en la propia descripción. Si en tu ERP un código de estado no significa lo que parece, escríbelo ahí. El modelo no lo deduce, y se equivocará con mucha seguridad en sí mismo.
- Devolver poco por defecto. Que los listados den solo lo esencial salvo que se pida el detalle. Un listado completo se come el contexto y encarece cada pregunta.
- Escribir errores que expliquen qué falta. Un mensaje útil permite al modelo corregir en el segundo intento; un «error» genérico hace que pruebe cosas al azar.
El filtro por cliente va abajo del todo
Si el servidor sirve a más de una empresa, el aislamiento no puede depender de que cada consulta se acuerde de filtrar. Tiene que estar en la capa de datos, por debajo de las herramientas, de forma que una consulta mal escrita devuelva vacío en vez de devolver datos de otro.
Es la diferencia entre un bug molesto y una llamada muy incómoda.
Lo que no hay que hacer
Exponer el ERP entero porque técnicamente se puede. Cada herramienta añadida es superficie de ataque y ruido para el modelo, que empieza a dudar entre opciones parecidas. Empieza por las cinco preguntas que de verdad se repiten.
Confiar en que el modelo se portará bien porque se lo has pedido en el prompt. Un texto de sistema se sortea; una comprobación de permisos en el servidor, no. El control va en el código.
Y montarlo sobre datos sucios. Si tu ERP tiene el mismo cliente dado de alta tres veces, la IA sumará mal y lo dirá con una convicción notable. MCP no arregla la calidad del dato: la pone en boca de una máquina que suena segura.
Cuándo compensa un servidor MCP
Cuando hay muchas preguntas repetidas de respuesta corta, cuando quien las hace no se maneja bien con el ERP, y cuando el dato está razonablemente limpio. Ahí el ahorro se nota la primera semana.
No compensa si lo que necesitas es un cuadro de mando con las mismas métricas cada mes. Para eso un informe bien hecho es más barato, más rápido y más fiable que una conversación. Las dos cosas conviven, pero resuelven problemas distintos y confundirlos sale caro.
Por dónde empezaríamos
Tres o cuatro herramientas sobre las preguntas más frecuentes, en solo lectura, con la identidad corporativa conectada y registro desde el primer día. A partir de ahí se añade lo que la gente pida, que casi nunca coincide con lo que parecía vistoso en la demo.
Si quieres verlo funcionando sobre un ERP real, o valorar qué tendría sentido exponer en el tuyo, mira nuestro servicio de servidores MCP o escríbenos. En media hora se ve si tu caso es candidato.