Desde junio de 2026, Microsoft amplió el servidor MCP de Business Central para exponer un conjunto más amplio de APIs estándar y API queries con datos agregados y optimizados.
La nueva preview añade herramientas MCP para definir, validar y ejecutar consultas de datos personalizadas. Es una capacidad de evaluación, no una función que deba tratarse todavía como producción consolidada.
El agente no debería obligarte a construir una integración nueva cada vez que cambia la pregunta.
Hasta ahora, una gran parte de los proyectos de IA conectada al ERP chocaba con una limitación muy práctica: el agente podía consultar aquello que el sistema ya exponía mediante APIs, pero cualquier pregunta fuera de ese perímetro podía terminar en desarrollo, extensión, servicio intermedio o exportación. Business Central 29 explora una alternativa más flexible para determinados escenarios: permitir que una aplicación MCP defina y valide una consulta sobre datos del ERP antes de ejecutarla.
El dato existe en el ERP. La dificultad es convertirlo en una herramienta segura para el agente.
Business Central contiene información financiera, comercial y operativa muy valiosa: clientes, vencimientos, pedidos, compras, inventario, proyectos, fabricación, márgenes, movimientos y estados. Sin embargo, que el dato exista no significa que esté listo para ser utilizado por un agente. El sistema debe ofrecer una vía soportada, autorizada y suficientemente precisa para que la aplicación pueda recuperarlo.
Las APIs estándar resuelven una parte enorme de esa necesidad. Las API queries mejoran todavía más determinados escenarios porque permiten trabajar con conjuntos agregados u optimizados. Pero una empresa siempre tiene preguntas que no coinciden exactamente con una API preparada: combinaciones específicas de campos, filtros, relaciones o datos que tienen sentido para su modelo operativo.
La preview de Business Central 29 apunta directamente a esa brecha. Microsoft introduce herramientas MCP para definir, validar y ejecutar consultas de datos personalizadas, de modo que la aplicación pueda acceder a información para la que no existe una API concreta. El valor no está en saltarse las APIs; está en ampliar de forma controlada el perímetro que el agente puede consultar.
La nueva preview permite evaluar consultas definidas dinámicamente, siempre dentro de las capacidades, permisos y controles previstos por Microsoft.
API estándar, API query o consulta MCP personalizada: no son lo mismo y no deberían usarse para lo mismo.
La arquitectura correcta empieza utilizando la opción más estándar y mantenible que resuelva el caso. La nueva capacidad no convierte las consultas personalizadas en la opción por defecto. Al contrario: obliga a elegir con más criterio qué debe exponerse como API, qué puede resolverse con una query preparada y qué merece una consulta dinámica.
API estándar
Es la primera opción cuando Business Central ya expone la entidad o acción necesaria. Aporta un contrato claro, reutilizable y fácil de gobernar. Clientes, proveedores, artículos, pedidos y otras entidades comunes pueden resolverse sin inventar una interfaz nueva.
Úsala cuando: la necesidad encaja con una capacidad estándar existente.
API query
Permite exponer conjuntos de datos agregados y optimizados para análisis. Es especialmente útil cuando el agente necesita una lectura preparada de varias tablas o un dataset diseñado para responder preguntas repetitivas con rendimiento y consistencia.
Úsala cuando: la pregunta se repite y merece un conjunto de datos estable.
Consulta MCP personalizada en Business Central 29 Preview
Microsoft introduce herramientas para definir, validar y ejecutar una consulta en tiempo de uso. Esto permite explorar información para la que todavía no existe una API específica. El escenario es potente porque puede reducir desarrollos para preguntas puntuales o variables, pero precisamente por esa flexibilidad necesita límites, permisos, validación y observabilidad.
Úsala para evaluar: preguntas variables donde construir una API específica por cada combinación de datos no sería eficiente.
La novedad importa cuando una pregunta útil dejaba de ser viable por el coste de preparar el acceso.
No todas las preguntas justifican desarrollar una API. Muchas aparecen de forma ocasional, cambian según el rol o combinan datos diferentes dependiendo del contexto. Si cada nueva necesidad exige diseñar una integración completa, el coste de experimentar con agentes crece demasiado rápido. Las consultas MCP personalizadas pueden reducir esa fricción en determinados casos, especialmente durante exploración y prototipado controlado.
“¿Qué clientes combinan saldo vencido alto, caída de compras y riesgo de superar su límite?”
No es una consulta simple sobre un único registro. El valor aparece cuando el agente puede reunir señales relevantes para priorizar revisión financiera sin obligar a preparar una pantalla específica para cada variante.
“¿Qué pedidos importantes dependen de artículos con disponibilidad comprometida esta semana?”
El agente necesita cruzar contexto comercial con disponibilidad y fechas. Si el resultado ayuda a anticipar problemas antes de prometer una entrega, deja de ser una demo y empieza a tener impacto operativo.
“¿Qué proveedores concentran retrasos y qué pedidos de venta podrían verse afectados?”
Una pregunta transversal puede requerir datos que no estén preparados como una API específica. La capacidad de consulta dinámica permite explorar el caso antes de decidir si merece convertirse en una herramienta permanente.
“¿Dónde ha caído el margen y qué combinación de precio, coste o volumen lo explica?”
La IA puede ayudar a orientar el análisis, pero la calidad de la respuesta depende de que el dato recuperado sea fiable, comprensible y coherente con el modelo financiero de la compañía.
La consulta debe estar acotada por identidad, permisos, validación y reglas de negocio. La capacidad técnica nunca sustituye el diseño de seguridad.
El reto no es que el agente pueda preguntar. Es decidir qué preguntas puede hacer, sobre qué datos y con qué identidad.
Cuando una aplicación trabaja con un ERP, la seguridad no puede reducirse a “tiene acceso” o “no tiene acceso”. Hay datos financieros, precios, clientes, proveedores, salarios indirectamente reflejados en costes, información comercial y registros operativos cuya visibilidad depende del rol.
MCP no elimina ese modelo de permisos. La aplicación sigue necesitando autenticación y autorización, y el diseño debe respetar mínimo privilegio. Un agente orientado a cobros no necesita explorar todo inventario; uno de compras no necesita acceso a toda la contabilidad; un asistente de ventas no debería convertirse en una puerta trasera hacia información sensible.
La nueva flexibilidad de consultas hace todavía más importante definir límites: tablas accesibles, campos permitidos, filtros, volumen de datos, tiempo de ejecución, frecuencia, telemetría y criterios de error. La calidad de un agente empresarial se mide tanto por lo que puede hacer como por aquello que deliberadamente no puede hacer.
Dónde encaja MCP dentro de una arquitectura de agentes conectados a Business Central.
MCP no sustituye Business Central, Power Platform ni Azure. Es una capa de interacción entre aplicaciones compatibles y herramientas del ERP. El valor aparece cuando cada componente hace el trabajo que le corresponde y evitamos construir una arquitectura entera alrededor de una única moda tecnológica.
Business Central
Sistema de registro y ejecución. Finanzas, compras, ventas, inventario, proyectos, fabricación y procesos operativos mantienen la verdad transaccional.
Servidor MCP
Expone herramientas que un cliente compatible puede descubrir y utilizar. APIs, API queries y, en la preview de BC 29, nuevas capacidades de consulta personalizada.
Identidad y permisos
Microsoft Entra ID, roles y políticas delimitan quién puede utilizar cada capacidad. Sin identidad gobernada no existe una arquitectura seria de agentes.
Agente u aplicación
Copilot Studio u otros clientes compatibles interpretan la intención y utilizan herramientas concretas para obtener contexto o participar en procesos.
Power Platform, Dataverse, Azure y Microsoft 365
Un agente real puede necesitar documentos, aprobaciones, automatización, conocimiento, modelos, integración con CRM, correo o Teams. MCP resuelve una parte del acceso al ERP; el proceso completo puede necesitar otras capas del ecosistema Microsoft.
Cinco errores que pueden convertir una consulta flexible en una arquitectura difícil de gobernar.
Usar consultas dinámicas donde ya existe una API estándar
Si el estándar ya resuelve la necesidad, introducir flexibilidad adicional suele añadir complejidad sin aportar valor. Reutilizar contratos estables mejora mantenimiento, rendimiento y comprensión.
Dar acceso demasiado amplio para “ver qué pasa”
Un agente no necesita libertad ilimitada para demostrar valor. Un piloto serio define datos, roles, límites y casos de uso antes de abrir acceso. Menos superficie suele significar más control y mejores pruebas.
Convertir una preview en dependencia crítica
Business Central 29 sigue documentado como public preview. Es un entorno para evaluar dirección de producto y probar escenarios, no para diseñar hoy una operación crítica asumiendo que toda la capacidad está cerrada y estable.
Confundir recuperación de datos con una decisión fiable
Que el agente recupere correctamente un conjunto de registros no significa que la interpretación sea correcta. Hay que validar reglas, definiciones financieras, dimensiones, unidades, filtros y contexto antes de automatizar decisiones.
Diseñar agentes sin telemetría, ownership y operación
El proyecto no termina cuando la consulta devuelve datos. Hay que saber qué herramientas utiliza el agente, qué preguntas fallan, cuánto tarda, qué coste genera, qué permisos necesita, quién revisa incidencias y quién decide si una nueva consulta debe convertirse en una API o dataset gobernado. Sin operación, el piloto no escala.
Una consulta que funciona una vez no significa que deba seguir siendo dinámica para siempre.
La consulta dinámica puede ser excelente para explorar un caso, validar valor y descubrir qué información necesita realmente el usuario. Pero si la misma pregunta se repite cada día, alimenta una decisión crítica o necesita tiempos de respuesta predecibles, puede ser mejor convertirla en una API query, un servicio estable o un modelo de datos preparado.
Esto cambia la forma de diseñar proyectos de IA. Ya no es necesario decidir toda la arquitectura antes de saber si el caso aporta valor. Se puede empezar con un escenario acotado, observar qué consultas generan utilidad, medir adopción y después industrializar las que merecen convertirse en capacidades permanentes.
La empresa gana velocidad sin renunciar a gobierno: explorar con flexibilidad, consolidar lo que funciona y retirar lo que no aporta. Ese ciclo es mucho más saludable que construir desde el primer día una integración específica para cada hipótesis de negocio.
La consulta dinámica puede abrir el camino. La arquitectura final debe elegir la forma más estable de sostener cada caso que demuestre valor.
Ocho preguntas de negocio donde la flexibilidad puede ser más valiosa que una integración rígida.
No todas necesitan una consulta personalizada ni todas estarán disponibles exactamente igual en la preview. Son ejemplos de cómo pensar el problema: preguntas variables, con valor operativo, que dependen de datos vivos del ERP y que conviene evaluar antes de construir una interfaz específica.
Cobros: priorizar riesgo real
Combinar vencimiento, saldo, comportamiento de pago y actividad comercial para preparar una lista priorizada de clientes que necesitan intervención.
Pedidos: anticipar incumplimientos
Identificar pedidos relevantes cuya fecha comprometida puede verse afectada por stock, compras pendientes, fabricación o bloqueos.
Compras: revisar excepciones
Encontrar órdenes abiertas con retrasos, cambios de fecha o proveedores que concentran incidencias y necesitan seguimiento.
Inventario: explicar exceso o rotura
Cruzar movimientos, demanda, disponibilidad y pedidos abiertos para orientar por qué un artículo está acumulando stock o entrando en riesgo de rotura.
Proyectos: detectar desviaciones antes del cierre
Comparar presupuesto, consumo, compras, horas y facturación para localizar proyectos que deterioran margen antes de que el problema aparezca en el resultado mensual.
Fabricación: explicar variaciones
Analizar consumos, capacidad, tiempos, costes y producción para preparar hipótesis sobre una desviación que después revisa el responsable.
Dirección financiera: preparar comité
Recuperar señales relevantes de caja, ventas, cobros, inventario y proyectos para construir un briefing previo que el CFO pueda validar antes de una reunión.
Operación transversal: conectar ERP y contexto externo
Usar Business Central como fuente transaccional y combinarla con CRM, SharePoint, Power Platform o Azure cuando el agente necesita entender una situación de extremo a extremo.
MCP no elimina la integración. Cambia dónde merece la pena construirla.
La lectura interesante para arquitectura no es “ya no necesitamos APIs”. Es exactamente la contraria: las APIs siguen siendo el contrato preferente cuando existe una capacidad estable. MCP añade una capa que facilita a agentes descubrir y utilizar esas herramientas, y la preview de BC 29 explora además consultas dinámicas para escenarios donde todavía no existe ese contrato.
Esto permite reservar desarrollo específico para aquello que realmente lo necesita. Una pregunta ocasional puede explorarse sin crear inmediatamente una interfaz permanente. Un caso repetitivo puede madurar hacia una API query. Una acción crítica puede seguir necesitando un servicio o extensión diseñada con controles específicos.
La oportunidad está en disminuir integraciones desechables y aumentar capacidades reutilizables. Business Central, Power Platform, Azure y Copilot pueden trabajar como piezas de una arquitectura común si cada necesidad se resuelve en la capa adecuada.
Menos desarrollo por hipótesis
No construir una API completa para una pregunta que todavía no ha demostrado utilidad.
Más estándar donde ya existe
Aprovechar APIs estándar y API queries antes de añadir nuevas capas.
Más gobierno sobre agentes
Identidad, permisos, herramientas, telemetría y límites como parte del diseño, no como revisión final.
Más velocidad para validar valor
Probar antes qué preguntas y tareas merecen industrializarse.
Un piloto útil empieza por una pregunta de negocio, no por activar todas las herramientas disponibles.
Business Central 29 Preview debería utilizarse para aprender. El objetivo no es demostrar que una consulta técnica funciona, sino descubrir qué casos mejoran de verdad un proceso y qué requisitos de seguridad, rendimiento y operación aparecerían antes de una futura adopción productiva.
Selecciona una tarea repetitiva
Algo que hoy obligue a navegar por varias páginas, cruzar datos o preparar manualmente una lectura para tomar una decisión.
Define la información mínima
Campos, tablas, filtros y contexto estrictamente necesarios. Menos datos ayudan a validar precisión y reducen exposición innecesaria.
Comprueba si ya existe una capacidad estándar
Antes de una consulta dinámica, revisa APIs y API queries. La opción más simple y estable suele ser la mejor.
Prueba con usuarios que conozcan el dato
Finanzas, compras u operaciones deben validar significado y excepciones. La prueba técnica no sustituye el criterio del proceso.
Mide tiempo, precisión y utilidad
No midas “respuestas generadas”. Mide minutos ahorrados, incidencias evitadas, decisiones aceleradas y porcentaje de respuestas consideradas útiles.
Decide cómo industrializar
Mantener consulta, crear API query, desarrollar una extensión, integrar Power Platform o descartar el caso. El piloto debe terminar con una decisión.
La calidad del agente seguirá dependiendo de la calidad del ERP, los datos y el proceso.
MCP puede facilitar el acceso. No puede arreglar maestros duplicados, dimensiones inconsistentes, procesos no definidos, permisos históricos o una implantación llena de personalizaciones que nadie entiende. Si el dato de Business Central es pobre, un agente lo recuperará con más velocidad, pero seguirá siendo pobre.
Por eso la evolución hacia agentes refuerza, y no reduce, la importancia de tener un ERP bien diseñado. Cuanto más estándar sea el core, más coherentes los datos y más claros los roles, más sencillo será exponer capacidades a otras aplicaciones sin abrir una caja negra de excepciones.
Si una organización todavía opera sobre NAV, un ERP legacy o un Business Central fuertemente personalizado, la conversación sobre agentes puede ser también una conversación sobre modernización. No porque la IA obligue a migrar, sino porque hace visibles los costes de una arquitectura que no fue diseñada para compartir contexto de forma gobernada.
Primero claridad de proceso y dato. Después acceso, razonamiento y automatización.
Conectar agentes al ERP exige conocer Business Central y también la arquitectura que vive alrededor.
Ayesa Digital combina capacidades en Dynamics 365, Business Central, Power Platform, Azure, datos, Microsoft 365, seguridad e IA. Ese enfoque permite evaluar un caso sin forzarlo a una única plataforma: qué debe resolverse en el ERP, qué puede exponer MCP, qué necesita Copilot Studio, qué requiere automatización y cuándo Azure aporta una capa adicional.
La ventaja no está en desplegar más tecnología. Está en reducir desarrollos innecesarios, mantener el sistema transaccional gobernado y crear una ruta de evolución donde cada nuevo agente reutilice mejor la arquitectura anterior.
Qué conviene tener claro sobre Business Central 29, MCP y las nuevas consultas de datos.
¿Business Central 29 está ya disponible en producción?
La documentación de Microsoft consultada a comienzos de octubre de 2026 sigue presentando Update 29.0 como public preview para entornos sandbox online. Por tanto, las nuevas consultas MCP deben tratarse como capacidad de evaluación.
¿Qué añade BC 29 al servidor MCP?
Nuevas herramientas para definir, validar y ejecutar consultas de datos personalizadas. Microsoft plantea que una aplicación MCP pueda consultar información para la que no exista una API preparada.
¿Esto sustituye las APIs estándar?
No. Las APIs siguen siendo preferibles cuando ya resuelven el escenario. MCP facilita que agentes y aplicaciones utilicen esas capacidades de forma estandarizada.
¿Qué son las API queries?
Son consultas preparadas que permiten exponer conjuntos de datos agregados u optimizados. Microsoft las incorporó al servidor MCP mejorado para obtener resultados más adecuados en análisis y reporting.
¿Puede un agente preguntar cualquier cosa al ERP?
No debería. El acceso debe estar limitado por identidad, permisos, herramientas expuestas, validación y las reglas que defina la organización. La flexibilidad de consulta no equivale a acceso indiscriminado.
¿Necesito Copilot Studio?
No necesariamente para todos los escenarios. MCP es un protocolo utilizado por clientes compatibles. Copilot Studio encaja muy bien cuando el proyecto necesita agentes empresariales, herramientas, flujos y gobierno dentro del ecosistema Power Platform.
¿Cuándo merece la pena una consulta dinámica?
Cuando la pregunta es variable, el dato existe en Business Central, no hay una API preparada y construir una integración específica para cada hipótesis sería desproporcionado. Si el caso se vuelve repetitivo y crítico, puede ser mejor industrializarlo.
¿Qué debería medir un piloto?
Tiempo ahorrado, precisión, utilidad para el usuario, errores, frecuencia, rendimiento, seguridad y si la consulta merece convertirse en una capacidad estable del sistema.
¿Cómo se relaciona con ERP + IA?
MCP es una pieza de una arquitectura más amplia. Los agentes necesitan datos, identidad, automatización, conocimiento y gobierno. Business Central aporta el contexto transaccional; Power Platform, Microsoft 365 y Azure pueden completar el proceso.
¿Por dónde debería empezar una empresa?
Por una pregunta repetitiva y medible que hoy consuma tiempo y dependa de datos fiables de Business Central. Después se revisa qué acceso estándar existe y solo entonces se evalúa si la nueva consulta MCP aporta una ventaja real.
El valor de MCP no se mide por cuántas consultas puede hacer un agente, sino por cuántas integraciones innecesarias evita.
En un proyecto tradicional, cada nueva necesidad de datos puede abrir una conversación técnica: identificar tablas, diseñar endpoint, programar lógica, autenticar, probar, documentar, desplegar y mantener. Ese proceso tiene sentido cuando la capacidad va a utilizarse durante años o soporta un proceso crítico. Tiene mucho menos sentido cuando se trata de una pregunta exploratoria que quizá solo aporte valor en determinados momentos.
La capacidad de consultar de forma más flexible puede cambiar esa economía. Permite evaluar primero si una combinación de datos mejora realmente una tarea. Si funciona y se repite, se industrializa. Si no aporta, se descarta sin haber construido una pequeña integración permanente que después alguien tendrá que mantener.
Para un CIO, este enfoque es relevante porque el coste oculto de la IA no está solo en licencias o consumo de modelos. Está también en todas las interfaces, servicios y extensiones que se crean para alimentar casos que después no escalan. Reducir ese inventario de componentes puede ser más valioso que obtener una demo ligeramente más sofisticada.
Pregunta exploratoria
Prueba rápida, alcance limitado, lectura de datos y supervisión humana. El objetivo es saber si existe valor antes de invertir más.
Capacidad consolidada
Cuando la tarea demuestra retorno, se diseña para rendimiento, soporte, seguridad, ownership y evolución. La flexibilidad inicial no debe impedir una arquitectura robusta posterior.
La velocidad importa. La capacidad de revisar el dato, el filtro y el contexto importa todavía más.
Preguntar al ERP en lenguaje natural no elimina la necesidad de entender de dónde sale la respuesta.
Una experiencia conversacional puede hacer que acceder a la información parezca trivial. El usuario formula una pregunta, el agente recupera datos y devuelve una explicación. Pero detrás siguen existiendo filtros, relaciones, campos, fechas, dimensiones y reglas que condicionan el resultado. En procesos financieros u operativos, una respuesta útil debe poder revisarse.
Por eso los primeros casos deberían diseñarse para acompañar la decisión y no para ocultar el origen del dato. Si el agente afirma que diez clientes concentran el mayor riesgo de cobro, el responsable debe poder comprobar qué saldos, vencimientos y criterios ha utilizado. Si detecta una caída de margen, hay que entender qué periodos, dimensiones y costes intervienen en la lectura.
Esta necesidad de explicabilidad también ayuda a decidir qué consultas merecen consolidarse. Las preguntas recurrentes pueden acabar convertidas en datasets o herramientas más estables, con definiciones acordadas por Finanzas y Operaciones. Las preguntas excepcionales pueden mantener un enfoque más flexible siempre que el usuario conozca sus límites.
El resultado buscado no es que el agente sustituya el conocimiento del ERP. Es que elimine navegación, búsqueda y preparación manual para que ese conocimiento pueda aplicarse más rápido. La combinación correcta es dato gobernado, acceso seguro, interpretación asistida y una persona capaz de validar aquello que afecta al negocio.
Ese enfoque también mejora la adopción: cuando el usuario puede comprobar el origen y entiende los límites de la respuesta, confía más en la herramienta y detecta antes los casos en los que necesita revisar el dato directamente en Business Central.
Business Central + MCP
La guía general para entender cómo MCP conecta agentes con APIs, datos, identidad y gobierno en Business Central.
ERP + IA Microsoft
Cómo conectar ERP, Copilot, agentes, Power Platform, Azure y datos en una arquitectura empresarial coherente.
Power Platform conectada al ERP
Apps, flujos, Dataverse, reporting y agentes alrededor del sistema transaccional sin romper el core.
Microsoft Learn · Business Central 29
Documentación oficial de la versión 29.0 Preview y de la capacidad para ejecutar consultas de datos con MCP Server.
¿Qué pregunta de negocio te gustaría resolver sin construir otra integración a medida?
Podemos ayudarte a revisar el caso de uso, identificar qué datos y APIs existen en Business Central, evaluar dónde MCP puede aportar valor y decidir si el escenario necesita Copilot Studio, Power Platform, Azure o una capacidad específica del ERP.
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)