MCP en empresas: qué revisar antes de conectar IA al ERP

Qué resuelve MCP en una integración empresarial

Una empresa quiere que su asistente consulte el estado de un pedido en el ERP y lo relacione con una oportunidad del CRM. La pregunta inicial es qué datos necesita, quién puede consultarlos y cómo comprobar la respuesta. MCP puede formar parte de esa conexión; elegirlo requiere evaluar el proceso completo.

Model Context Protocol define una interfaz común entre aplicaciones de IA y servidores que ofrecen capacidades externas. Su documentación distingue la aplicación anfitriona, sus clientes de conexión y los servidores. También acota su alcance: regula el intercambio de contexto, sin determinar cómo la aplicación utiliza el modelo o gestiona esa información. MCP, arquitectura del protocolo.

Esta guía traduce esa arquitectura a decisiones para empresas chilenas. Utiliza documentación técnica, no un anuncio del día. Recomendamos evaluar MCP como una opción de integración y pedir evidencia de las operaciones disponibles en el sistema concreto, antes de comprometer una automatización.

Separar la información de las operaciones disponibles

El estándar distingue recursos, herramientas y plantillas de instrucciones. Los recursos aportan información de lectura para contexto; las herramientas son funciones invocables y pueden consultar información o modificar sistemas. Las plantillas ayudan a estructurar una interacción. Por eso, que algo aparezca como herramienta no significa necesariamente que escriba datos. MCP, capacidades de los servidores.

Para una evaluación, proponemos una ficha por operación: nombre, propósito, campos de entrada, resultado, sistema de origen y efecto permitido. Consultar el estado de un pedido, cambiar su dirección y cancelarlo merecen fichas distintas. Esa separación permite revisar el alcance con operaciones, tecnología y quienes administran los accesos.

Defina también el significado empresarial de cada campo. Un estado llamado cerrado podría referirse a despacho, facturación u oportunidad comercial según el sistema. Recomendamos acordar identificadores, estados y reglas de interpretación; una respuesta con el formato correcto todavía puede contestar una pregunta distinta de la que hizo el usuario.

Comprobar el servidor y la compatibilidad real

La documentación de Azure API Management ofrece un ejemplo concreto: permite exponer operaciones de APIs REST como herramientas MCP. La página consultada, actualizada el 11 de septiembre de 2026, declara soporte para herramientas, pero no para recursos ni plantillas MCP. Esa limitación corresponde a ese producto; no describe todo el estándar. Microsoft, MCP en API Management.

Nuestra recomendación es pedir una demostración de la combinación exacta que se utilizará: aplicación de IA, servidor, versión y sistema de destino. Revise quién mantiene el servidor, qué operaciones expone, cómo se autentica y qué restricciones impone el proveedor del ERP o CRM. El nombre de una plataforma en un catálogo no prueba que estén disponibles todos sus módulos.

Si el sistema interno no dispone de un servidor MCP, puede hacer falta desarrollarlo. Microsoft documenta un recorrido en que el servidor valida una solicitud, llama a una API interna y devuelve el resultado. La conexión con esa API continúa siendo parte del trabajo. Microsoft, construcción de un servidor MCP.

Definir quién accede y con qué alcance

La misma guía de Microsoft recomienda autenticación, protección de credenciales, permisos mínimos para las llamadas a APIs internas y seguimiento de las herramientas invocadas. Son controles que se deben implementar y verificar; una conexión MCP por sí sola no acredita que estén configurados. Microsoft, controles del servidor.

Para el piloto proponemos documentar la identidad utilizada en cada tramo. Si varias personas acceden mediante una cuenta técnica, hay que comprobar cómo se restringen los registros que cada una puede consultar. Incluya qué campos llegan al asistente, dónde se procesan y qué información queda en los registros de actividad.

Empiece con las operaciones necesarias para la tarea acordada. En nuestro ejemplo hipotético bastaría consultar pedidos y oportunidades; modificar precios o cancelar documentos queda fuera de ese alcance. Si luego se incorporan escrituras, defina por separado las condiciones, responsables y confirmaciones que correspondan a sus consecuencias.

Probar desde la pregunta hasta el sistema de origen

Recomendamos preparar preguntas de evaluación con respuestas conocidas. Incluya un pedido válido, otro inexistente, dos clientes con nombres parecidos y un registro al que la persona no tenga acceso. Agregue campos ausentes, una API temporalmente indisponible y una herramienta que cambie de versión. Son pruebas propuestas, no resultados de una implementación de Digital Dev.

En cada prueba observe qué operación se eligió, qué argumentos recibió y qué devolvió el sistema. Luego compruebe que la explicación al usuario conserve el alcance de ese resultado. Una consulta incompleta debe reconocerse como incompleta; la ausencia de respuesta no debería convertirse en un estado comercial inventado.

Cuando el proceso incluya cambios, evalúe también qué ocurre al perderse una confirmación. La guía sobre reintentos sin duplicar pedidos desarrolla ese problema. La aceptación debe comprobar el resultado en el sistema de origen, además del mensaje mostrado por el asistente.

Elegir una conexión que la empresa pueda mantener

Como criterio editorial, conviene comparar MCP con una integración directa. Si el trabajo consiste en transferir campos mediante reglas fijas, evalúe primero esa alternativa. Si distintas aplicaciones de IA necesitan reutilizar capacidades, incluya MCP en la comparación. Decida por compatibilidad, mantenimiento y utilidad comprobada, sin asumir que el protocolo reducirá costos automáticamente.

Pida una propuesta que separe acceso al sistema, desarrollo o configuración del servidor, pruebas, operación y cambios futuros. Asigne responsables para credenciales, versiones y fallos. La integración de sistemas ERP y CRM empieza por ese alcance verificable: una tarea definida, permisos concretos y evidencia de que la información llega con el significado correcto.