Model Context Protocol (MCP) y Business Central: el “USB-C” de la IA empresarial
MCP y Business CentralEl "USB-C" de la IA empresarial
Análisis completo del protocolo que conecta agentes de IA con sistemas empresariales. Qué es, cómo funciona, arquitectura, flujo real en Business Central y qué cambia para consultores.
Conectar inteligencia artificial con sistemas empresariales sigue siendo, hoy, uno de los grandes cuellos de botella de la transformación digital. Los modelos pueden razonar cada vez mejor, pero si no pueden acceder de forma fiable a datos, procesos y acciones del negocio, se quedan aislados detrás de silos de información y sistemas heredados. Anthropic resumió este problema con claridad al presentar MCP: cada nueva fuente de datos suele exigir su propia implementación, y eso hace muy difícil escalar sistemas realmente conectados. Al mismo tiempo, los agentes están empezando a entrar en producción porque los modelos han mejorado en comprensión, planificación, uso de herramientas y recuperación de errores.
Aquí es donde entra MCP, el Model Context Protocol. La mejor forma de entenderlo es con una analogía muy potente: MCP es para la IA lo que USB-C fue para los dispositivos. Igual que USB-C dio una forma estándar de conectar equipos distintos, MCP propone una forma estándar de conectar aplicaciones de IA con sistemas externos, datos y herramientas.
En otras palabras: el gran cambio no es solo que la IA "hable mejor", sino que empiece a trabajar con los sistemas de la empresa de una forma más uniforme, reutilizable y gobernable. Y eso es exactamente el tipo de terreno en el que un ERP como Dynamics 365 Business Central puede jugar un papel central.
En lenguaje no técnico, MCP es un idioma común para que una aplicación de IA pueda entender qué puede hacer en un sistema externo, qué datos puede consultar y cómo pedir esas acciones de forma estructurada. En vez de construir una integración distinta para cada combinación de asistente, agente, copiloto, ERP, CRM o base de datos, MCP busca que todos "se entiendan" a través del mismo protocolo.
En una definición más precisa, la publicación oficial de Anthropic presenta MCP como un estándar abierto que permite crear conexiones seguras y bidireccionales entre fuentes de datos y herramientas impulsadas por IA. La documentación oficial del protocolo añade que MCP es un estándar abierto para conectar aplicaciones de IA con sistemas externos y que su foco está en el intercambio de contexto, no en dictar cómo debe razonar el modelo o cómo debe implementarse el agente.
¿Por qué esto importa tanto? Porque soluciona, en la práctica, el problema de integraciones N x M. Si tienes 4 asistentes y 6 sistemas empresariales, el enfoque tradicional te empuja hacia 24 integraciones específicas. MCP intenta romper esa lógica: cada cliente aprende a hablar MCP y cada sistema expone capacidades vía MCP. El objetivo es pasar de una malla de conectores personalizados a un protocolo común. Esa idea encaja exactamente con lo que Anthropic describe como sustitución de integraciones fragmentadas por un único estándar, y con lo que la documentación oficial del protocolo resume como "construir una vez e integrar en todas partes".
MCP vs API tradicional
MCP no sustituye necesariamente a la API. La API sigue siendo la forma de exponer datos o acciones del sistema. La diferencia es que MCP añade una capa estándar para que una aplicación de IA descubra esas capacidades y las use de forma estructurada, con mecanismos oficiales como tools/list y tools/call.
MCP vs integración personalizada
MCP reduce la necesidad de desarrollar un "conector único" para cada pareja agente-sistema. Esa es precisamente la fragmentación que Anthropic identifica como el problema de fondo.
MCP vs function calling
La diferencia conceptual es importante. El function calling permite que un modelo invoque funciones que una aplicación le pone delante. MCP va un paso más allá: define un protocolo compartido para descubrir, describir e invocar capacidades de sistemas externos mediante una arquitectura común de host, cliente y servidor. Dicho de otro modo, el function calling resuelve la llamada; MCP estandariza el ecosistema en el que esas llamadas se publican y se consumen.
Mini-resumen: MCP no es el modelo, no es el ERP y no es una API nueva. Es el estándar común que permite que una IA conecte con sistemas externos sin reinventar la integración en cada caso.
Estandarización
Cuando el protocolo es común, la conversación entre agente y sistema deja de depender de acuerdos ad hoc. Eso reduce fricción técnica y hace más sencillo incorporar nuevos clientes o nuevos sistemas sin empezar desde cero.
Interoperabilidad
La documentación oficial del protocolo destaca un ecosistema amplio de clientes y servidores compatibles, y su promesa central es clara: construir una vez e integrar en muchos sitios. En negocio, eso significa que una inversión en exposición de capacidades puede reutilizarse más allá de una sola interfaz.
Escalabilidad
La arquitectura MCP permite que un host conecte con uno o varios servidores, creando un modelo donde un mismo agente puede trabajar con múltiples fuentes de contexto y múltiples herramientas sin que cada conexión sea una integración artesanal.
Agentes que operan sistemas
Los agentes no se limitan a responder texto: según la documentación oficial de Anthropic, están empezando a entrar en producción precisamente porque ya pueden razonar, planificar, usar herramientas con más fiabilidad y apoyarse en el "ground truth" que les llega desde el entorno. MCP es uno de los estándares que hace posible esa capa operativa.
En otras palabras: MCP cambia las reglas porque convierte la conexión entre IA y sistemas en algo menos artesanal y más industrializable.
El flujo general puede resumirse así:
1. El usuario hace una petición en lenguaje natural
Todo empieza con una instrucción humana, por ejemplo: "Muéstrame los clientes con incidencias" o "Crea un pedido de venta". Anthropic describe que los agentes comienzan su trabajo a partir de una orden o una conversación con el usuario, y Microsoft muestra este patrón en Business Central con ejemplos como "Can you list all items" o "list my customers".
2. El agente interpreta la intención
El modelo no piensa en pantallas ni en menús: interpreta la intención del usuario y decide si necesita contexto, datos o una acción. En MCP, las tools están pensadas precisamente para que el modelo pueda descubrirlas y usarlas según el contexto.
3. El MCP Client establece la conexión y negocia capacidades
Bajo el capó, el cliente MCP inicializa la conexión con el servidor, negocia capacidades y aprende qué primitives soporta ese servidor. La arquitectura oficial describe esta fase como parte del ciclo de vida del protocolo y de la negociación de capacidades entre cliente y servidor.
4. El MCP Server expone sus capacidades
Una vez conectado, el cliente puede pedir la lista de tools disponibles mediante mecanismos como tools/list. La respuesta no es solo una lista de nombres: incluye metadatos como nombre, título, descripción e inputSchema, que ayudan a la IA a entender qué hace cada herramienta y qué parámetros espera.
5. Se ejecuta la acción
Cuando el modelo decide qué tool necesita, el cliente lanza una llamada tools/call con el nombre de la herramienta y sus argumentos. El servidor MCP recibe esa petición, interactúa con el sistema externo y devuelve un resultado estructurado.
6. Se devuelve la respuesta al usuario
El resultado vuelve al agente, y el agente lo integra en la conversación. Aquí ocurre algo clave: la IA ya no responde "solo con su entrenamiento", sino con información obtenida en tiempo real o con acciones realmente ejecutadas sobre el sistema externo.
Internamente, todo esto se apoya en un protocolo de petición/respuesta; la documentación oficial del protocolo indica que MCP usa JSON-RPC 2.0 como base.
Mini-resumen: MCP convierte una petición en lenguaje natural en una secuencia estructurada: descubrir capacidades, elegir herramienta, ejecutar y devolver resultado.
La arquitectura de MCP tiene tres piezas fundamentales.
MCP Host
Qué es: el host es la aplicación de IA con la que interactúa el usuario. Es el "contenedor" del agente o copiloto. La documentación oficial pone como ejemplo aplicaciones como Visual Studio Code o Claude Desktop.
Por qué importa: es donde se coordina toda la experiencia: conversación, decisiones del modelo y gestión de conexiones.
MCP Client
Qué es: el client es el intermediario técnico que mantiene la conexión con un servidor MCP y obtiene de él el contexto o las tools que el host necesita. La documentación oficial explica incluso que el host crea un cliente MCP por cada servidor al que se conecta.
Por qué importa: separa la experiencia del usuario de la conexión técnica con cada sistema.
MCP Server
Qué es: el server es el programa que expone datos, contexto o acciones a los clientes MCP. Puede ejecutarse local o remotamente. En términos simples, es la "puerta de entrada estándar" de un sistema para que un agente de IA pueda trabajar con él.
Por qué importa: en Business Central, Microsoft describe explícitamente su MCP Server como el puente entre los clientes MCP y los datos de Business Central.
En otras palabras: el host conversa, el client conecta y el server expone. Cuando esta división se entiende bien, MCP deja de parecer abstracto.
En MCP, el concepto más importante son las primitives. La documentación oficial del protocolo explica que, del lado del servidor, MCP puede exponer tres grandes tipos: tools, resources y prompts. Para este artículo, la pieza central son las tools, porque son las que más directamente aterrizan la conexión entre IA y sistemas empresariales.
Tools vs Resources
Una tool es una función ejecutable que el modelo puede invocar para realizar una acción. Un resource, en cambio, es una fuente de información más pasiva, de solo lectura, que aporta contexto.
Dicho de forma simple: datos es lo que el agente consulta; acciones es lo que el agente ejecuta. La documentación oficial de MCP lo deja muy claro: las tools son model-controlled y sirven para actuar; los resources aportan contexto estructurado que la aplicación puede recuperar y pasar al modelo.
Sistema autodescriptivo
Que un sistema sea self-describing o autodescriptivo significa, en la práctica, que no solo expone una capacidad, sino que explica esa capacidad. En MCP eso ocurre porque las tools se publican con metadatos como nombre, descripción y esquema de entrada; y en resources ocurre algo parecido con metadatos que los hacen descubribles y autoexplicativos. Eso reduce ambigüedad y ayuda a que el agente sepa mejor qué usar y cómo usarlo.
¿Cómo decide el agente qué tool usar?
Según la arquitectura oficial, la aplicación de IA recopila las tools de los servidores conectados y construye un registro unificado de herramientas. A partir de ahí, el modelo ve qué acciones tiene disponibles y genera la llamada apropiada según el contexto de la conversación.
Hay además un punto importante para empresa: MCP no implica "barra libre". La documentación oficial del protocolo subraya mecanismos de supervisión humana como aprobaciones, visibilidad de tools, permisos preaprobados y logs de actividad.
Mini-resumen: en MCP, una tool no es solo "una función". Es una capacidad publicada, descrita y utilizable por un agente con un contrato claro.
El impacto de MCP en empresa se entiende muy bien en tres planos.
Automatización de procesos
Si un agente puede consultar datos y también ejecutar acciones, ya no se queda en "responder preguntas": puede participar en procesos. La documentación oficial de MCP pone ejemplos como búsquedas, creación de eventos o envío de mensajes; y la lógica es perfectamente trasladable al mundo empresarial: consultar una entidad, tomar una decisión y ejecutar el siguiente paso.
Acceso al ERP con lenguaje natural
Una de las promesas más poderosas es que el usuario deje de pensar en tablas, endpoints o rutas técnicas. En lugar de eso, formula una necesidad de negocio y el agente traduce esa intención en tools y llamadas estructuradas. Microsoft documenta precisamente este patrón en Business Central al hablar de acceso conversacional a datos y lógica de negocio.
Orquestación de sistemas
La fuerza real aparece cuando un mismo host conecta con varios servidores MCP. La documentación oficial del protocolo dedica una sección entera a cómo múltiples servidores pueden trabajar juntos en una misma tarea, combinando contexto y acciones de varias fuentes. En empresa, eso abre la puerta a escenarios donde un agente consulta ERP, calendario, base de conocimiento y mensajería dentro del mismo flujo.
En otras palabras: MCP no solo conecta IA con "un dato", sino con ecosistemas de trabajo.
Aquí conviene ser muy preciso y ceñirse a lo que Microsoft ya ha documentado oficialmente.
Microsoft Learn documenta un Business Central MCP Server para Business Central online. Microsoft lo describe como el puente entre los clientes MCP y los datos de Business Central, y explica que permite a aplicaciones de IA acceder e interactuar con sistemas externos como Business Central de forma consistente y segura.
¿Qué ha confirmado Microsoft?
Que clientes MCP como Visual Studio Code con GitHub Copilot, Copilot Studio y otros clientes compatibles con la especificación MCP puedan conectarse a Business Central para descubrir tools y ejecutarlas. Microsoft también documenta capacidades como ver y gestionar registros, ejecutar procesos de negocio y responder consultas en lenguaje natural.
¿Qué se expone?
Microsoft explica que el MCP Server de Business Central trabaja sobre API pages de Business Central, tanto estándar como personalizadas. En la documentación aparecen como ejemplos entidades y operaciones sobre customers, items y sales orders.
Además, Microsoft deja claro que, por defecto, el servidor da acceso de solo lectura a todas las API pages expuestas; si se quiere permitir crear, modificar, borrar o ejecutar bound actions, eso debe configurarse explícitamente por objeto API y por permiso.
La idea clave: APIs → operations → tools
Microsoft documenta que cada operación permitida sobre un API page object —read, create, modify, update, delete o bound action— se convierte en una tool correspondiente dentro del MCP Server. Eso es exactamente el puente que permite que un agente "vea" capacidades del ERP y las use.
Para quien quiera una capa un poco más técnica, Microsoft también documenta un funcionamiento dinámico en el que aparecen tools de sistema como bc_actions_search, bc_actions_describe y bc_actions_invoke, utilizadas para localizar, describir e invocar capacidades en tiempo de ejecución.
Conviene no afirmar más de lo documentado: en las fuentes consultadas, Microsoft pone el foco en API pages y tools. Por eso, en este artículo no doy por hecho una implementación específica de resources o prompts en Business Central, aunque sí existan como conceptos generales dentro del protocolo MCP.
Mini-resumen: en Business Central, Microsoft ya documenta un MCP Server que expone capacidades del ERP a agentes de IA a partir de las APIs del sistema, con permisos y configuración gobernados por el administrador.
Tomemos el ejemplo: "Muéstrame clientes con pagos atrasados".
Importante: este es un ejemplo conceptual de negocio para explicar el flujo. Microsoft documenta el mecanismo general de exposición de APIs y tools, pero la tool exacta y la disponibilidad concreta dependen de cómo esté configurado el MCP Server y de qué API pages estén expuestas en tu entorno.
1. El usuario hace la petición
El usuario no piensa en endpoints ni en objetos API. Solo expresa una necesidad de negocio en lenguaje natural. Ese es justamente el patrón que Microsoft muestra al interactuar con Business Central desde GitHub Copilot o desde agentes en Copilot Studio.
2. El agente interpreta la intención
El agente detecta que el usuario quiere una consulta sobre clientes y situación de cobro. Según la documentación de Microsoft y Anthropic, las instrucciones y las tools disponibles son las que le ayudan a decidir qué conocimiento o herramienta debe invocar.
3. MCP identifica la tool adecuada
Aquí entra el núcleo del protocolo. Si la configuración es dinámica, Microsoft documenta tools de sistema como bc_actions_search, bc_actions_describe y bc_actions_invoke, que permiten al agente buscar y usar la capacidad adecuada en tiempo de ejecución. Si la configuración no es dinámica, puede haber tools explícitas asociadas a API pages concretas.
4. Se llama a Business Central
Una vez identificada la capacidad, el MCP Server de Business Central actúa como puente hacia los datos del ERP. Si la operación necesaria está expuesta y autorizada, el servidor accede a la API correspondiente y recupera o ejecuta lo solicitado.
5. Se devuelve la información
El resultado vuelve en formato estructurado al agente, y el agente lo transforma en una respuesta comprensible para el usuario. Aquí está la clave: el usuario recibe una respuesta conversacional, pero debajo ha habido una llamada real al sistema.
6. Todo ocurre con permisos reales
Microsoft subraya que las operaciones se realizan con la identidad y permisos del usuario, y que esto preserva la trazabilidad. Eso cambia por completo la conversación sobre gobierno: no es "una IA todopoderosa", sino una IA que opera dentro del marco de seguridad del ERP.
En otras palabras: el usuario ve una conversación; por debajo, MCP está haciendo descubrimiento, selección de tool, llamada al ERP y devolución del resultado.
1. Consultar clientes
Este es el ejemplo más directo y más confirmado por la documentación. Microsoft muestra interacciones como "list my customers" en Visual Studio Code con GitHub Copilot, y documenta también la capacidad de view/list sobre clientes a través del MCP Server.
Por debajo, lo que ocurre es que el agente descubre una tool de lectura disponible, llama a Business Central y devuelve la lista o el resumen al usuario.
2. Crear un pedido de venta
Microsoft documenta que, con la configuración adecuada, el MCP Server puede permitir create, modify, delete y también bound actions; y en la documentación de Visual Studio Code se mencionan operaciones como crear elementos y procesar pedidos de venta.
¿Qué pasa por debajo? Que el agente solo podrá crear ese pedido si la API page correspondiente está expuesta y tiene permiso de creación. Si después existe una acción ligada para registrar o cambiar estado, esa acción también podría exponerse como tool si está autorizada.
3. Analizar ventas
Aquí conviene hablar con precisión: como caso conceptual, si las entidades o APIs de ventas están expuestas en modo lectura, el agente puede recuperar esos datos y luego resumir tendencias, comparar periodos o detectar desviaciones.
La parte "analítica" la hace el modelo; la parte "conseguir el dato fiable y actual" la hace Business Central a través del MCP Server. No estoy afirmando aquí una tool de análisis predefinida por Microsoft para Business Central; estoy describiendo el patrón general que habilita MCP sobre datos expuestos.
En otras palabras: en Business Central, MCP no convierte mágicamente al ERP en un chatbot. Lo que hace es exponer capacidades reales del ERP para que un agente pueda consultar, actuar y después explicarlo en lenguaje natural.
Antes
Antes, conectar IA con sistemas empresariales implicaba normalmente integraciones manuales, conectores específicos, APIs consumidas de forma ad hoc y bastante trabajo de mantenimiento. Anthropic lo resume de forma muy clara: cada nueva fuente de datos exigía su propia implementación y eso fragmentaba el ecosistema.
Después
Después de MCP, el enfoque cambia hacia un estándar único para publicar y consumir capacidades. Eso no significa "cero trabajo", porque siguen existiendo configuración, permisos, seguridad y gobierno. Pero sí significa que, si el cliente entiende MCP y el sistema expone MCP, el modelo se acerca mucho más a un esquema plug & play que al de la integración artesanal de siempre.
Para Business Central, la diferencia es especialmente relevante: Microsoft ya documenta que el servidor MCP puede dar acceso de solo lectura por defecto a API pages expuestas y que las operaciones adicionales se publican como tools según configuración. Eso convierte la conversación de "cómo hago otro conector" en "qué capacidades expongo, con qué permisos y para qué agente".
- Integración específica para cada pareja agente-sistema
- Conectores personalizados y APIs ad hoc
- Mantenimiento elevado por fragmentación
- Cada nueva fuente = nueva implementación
- Escalabilidad muy limitada
- Protocolo estándar y reutilizable
- Descubrimiento autodescriptivo de capacidades
- Esquema más cercano a plug & play
- Configuración, permisos y gobierno centralizados
- "Qué capacidades expongo" en vez de "cómo hago otro conector"
Mini-resumen: antes predominaba la integración específica; después gana peso la capacidad reutilizable expuesta con un protocolo común.
Para un consultor de Business Central, MCP supone un cambio de paradigma. Ya no basta con conocer tablas, páginas y procesos de negocio. Ahora importa también pensar qué capacidades del ERP deben estar disponibles para un agente, con qué permisos, en qué contexto y bajo qué gobierno. Microsoft documenta precisamente que la configuración del MCP Server define las APIs accesibles y sus permisos, y que las operaciones se ejecutan con identidad real del usuario.
Nuevas habilidades requeridas
En la parte funcional, hay que saber seleccionar casos de uso con valor real.
En la parte técnica, hay que entender API pages, permisos, tools, configuraciones MCP e instrucciones del agente. Microsoft explica que las instrucciones ayudan al agente a decidir qué tool o conocimiento llamar, a completar entradas y a generar la respuesta; y Anthropic insiste en que la interfaz agente-herramienta debe diseñarse y documentarse con mucho cuidado.
Connector vs MCP Server: una distinción estratégica
Microsoft distingue entre el Business Central connector, pensado para integración y automatización más estándar, y el Business Central MCP Server, orientado a escenarios de AI orchestration y agentes.
Esa distinción es clave para consultoría. No todo caso de uso necesita MCP; pero cuando quieres un agente que recupere datos, los analice y actúe en un flujo más autónomo, MCP entra en escena con mucha lógica.
En otras palabras: el consultor deja de ser solo alguien que "configura el ERP" y pasa a ser quien diseña cómo ese ERP se vuelve operable por agentes de IA sin perder control, trazabilidad ni sentido de negocio.
MCP se está consolidando como uno de los estándares más relevantes para conectar IA con sistemas reales. La idea central es simple, pero potente: dar a los agentes una forma común de descubrir capacidades, acceder a contexto y ejecutar acciones sobre sistemas externos. Eso es exactamente lo que Anthropic planteó al lanzar el protocolo y lo que la documentación oficial del protocolo desarrolla a nivel arquitectónico.
En Business Central, Microsoft ya ha documentado un camino claro: un MCP Server para Business Central online, conexión desde clientes compatibles, exposición de APIs como tools, permisos gobernados y ejecución con identidad real del usuario. Eso no es una promesa abstracta: es una base concreta para construir experiencias agentic sobre el ERP.
El mensaje final es este: el futuro no pertenece solo a los sistemas que tienen datos, sino a los sistemas que saben exponer esos datos y esas acciones de forma comprensible para la IA. Y en ese mapa, MCP puede convertirse en el idioma común, mientras que Business Central empieza claramente a prepararse para hablarlo.
Referencias
Microsoft Learn — Model Context Protocol (MCP) in Business Central overview.
Microsoft Learn — Configure Business Central MCP Server.
Microsoft Learn — Connect to Business Central MCP Server with Visual Studio Code.
Microsoft Learn — Create Agents in Copilot Studio that Connect to Business Central.
Anthropic — Introducing the Model Context Protocol.
Model Context Protocol — What is MCP? / Architecture overview / Understanding MCP servers.
Anthropic — Building effective agents.
