🛡️ D365FO 10.0.49: el servidor ERP MCP ya declara el riesgo de cada herramienta

Microsoft ha añadido al servidor dinámico Dynamics 365 ERP MCP un contrato de comportamiento para cada herramienta. A partir de 10.0.49 PQU-1, el cliente MCP puede saber si una herramienta es de solo lectura, destructiva, idempotente o capaz de interactuar con sistemas externos antes de invocarla.

No es una barrera de seguridad nueva ni un botón de aprobación incorporado a Dynamics 365. Son metadatos estándar de MCP que permiten a un cliente compatible decidir cuándo pedir confirmación humana. La diferencia es importante: hasta ahora el orquestador conocía el nombre, la descripción y el esquema de entrada de una herramienta; ahora recibe también vocabulario explícito sobre su riesgo operativo.

La misma actualización amplía las consultas SQL, endurece la resolución de campos y controles, devuelve todos los parámetros de acciones y añade compatibilidad con controles de opción, carga y visualización de documentos. Es un cambio pequeño en superficie, pero relevante para construir agentes ERP que puedan razonar mejor sobre qué van a hacer y no solo sobre cómo hacerlo.

Estado a 1 de septiembre de 2026: las mejoras están habilitadas por defecto desde 10.0.49 PQU-1, versión de plataforma 7.0.8199.29. Microsoft también las ha retroportado a 10.0.48 PQU-5 (7.0.7996.107) y 10.0.47 PQU-11 (7.0.7858.166). La nota de versión se actualizó el 28 de agosto de 2026.

Qué ha cambiado

La actualización agrupa cuatro áreas:

Área	Cambio	Consecuencia técnica
Seguridad del protocolo	Anotaciones readOnlyHint, destructiveHint, idempotentHint y openWorldHint	El cliente puede clasificar la llamada y aplicar una política de intervención humana
Herramientas de datos	Aritmética entre agregados SQL, validación explícita de campos y queryTimeout en SysDA	Menos llamadas, errores diagnosticables y mejor control de consultas largas
Herramientas de acción	Se devuelve el conjunto completo de parámetros, incluidos los heredados	El orquestador dispone del contrato real de una acción X++ expuesta
Herramientas de formulario	Option buttons, resolución de controles y grupos, etiquetas de menu items, búsqueda y controles de documentos	Más procesos pueden automatizarse mediante el view model del servidor

La disponibilidad exacta es la siguiente:

Aplicación	PQU mínima	Versión de plataforma mínima
10.0.49	PQU-1	7.0.8199.29
10.0.48	PQU-5	7.0.7996.107
10.0.47	PQU-11	7.0.7858.166

No hay una característica adicional que activar para estas mejoras: Microsoft las marca como habilitadas por defecto. Sí siguen aplicando los requisitos generales del servidor dinámico ERP MCP: entorno Tier 2 o superior, o Unified Developer Environment; servidor habilitado en Feature management; y cliente registrado en Allowed MCP Clients. Cloud Hosted Environments no están soportados.

Arquitectura: el contrato viaja con tools/list

MCP permite al cliente descubrir herramientas mediante tools/list. Cada definición contiene el nombre, la descripción, el esquema de entrada y, cuando el servidor las publica, sus anotaciones.

{
  "name": "data_find_entities_sql",
  "description": "Find or read records by using SQL",
  "inputSchema": { "type": "object" },
  "annotations": {
    "readOnlyHint": true,
    "destructiveHint": false,
    "idempotentHint": true,
    "openWorldHint": false
  }
}

El JSON anterior es ilustrativo; los valores deben inspeccionarse en la respuesta real de cada entorno y versión. No conviene copiar esta clasificación a una política sin verificarla.

El flujo de decisión queda así:

Usuario o proceso autónomo
          │
          ▼
Cliente/orquestador MCP
  1. descubre la herramienta
  2. lee sus annotations
  3. aplica su política HITL
          │
     aprobar / denegar
          │
          ▼
Dynamics 365 ERP MCP
  4. valida identidad y rol
  5. ejecuta data, form o action tool
          │
          ▼
Dynamics 365 F&O + extensiones + personalización

Hay dos controles distintos y ambos son necesarios:

• Las anotaciones informan al cliente sobre la naturaleza esperada de la operación. Pueden activar una confirmación, una etiqueta visual o una regla del host.
• La seguridad de F&O autoriza la operación real. El servidor genera contexto según el usuario autenticado y sus roles, y rechaza objetos o acciones fuera de ese alcance.

Cómo interpretar las cuatro anotaciones

El esquema oficial de MCP define:

• readOnlyHint: la herramienta no modifica su entorno.
• destructiveHint: una herramienta que escribe puede realizar actualizaciones destructivas; false indica actualizaciones aditivas.
• idempotentHint: repetir la llamada con los mismos argumentos no añade efectos adicionales.
• openWorldHint: la herramienta puede interactuar con entidades externas a un dominio cerrado.

Son hints, no garantías. La especificación advierte expresamente que el cliente no debe basar decisiones de seguridad en anotaciones procedentes de servidores no confiables. En este caso el servidor es de Microsoft y está dentro del entorno ERP, pero la regla arquitectónica sigue siendo válida: una anotación no sustituye permisos, separación de funciones, validaciones de negocio, registro de auditoría ni confirmaciones deterministas.

También importa la relación entre campos. destructiveHint e idempotentHint solo tienen sentido cuando readOnlyHint es false. Si una operación no publica anotaciones, los valores por defecto del protocolo son conservadores: no se asume que sea de solo lectura ni idempotente, se considera potencialmente destructiva y capaz de actuar en mundo abierto.

Por qué mejora el human-in-the-loop

Antes, un cliente debía deducir el riesgo a partir del nombre y la descripción. Esa heurística se rompe fácilmente con acciones personalizadas, traducciones o nombres internos. El contrato permite políticas generales como:

Condición	Política recomendada
readOnlyHint = true	Permitir sin confirmación si el rol y la sensibilidad de los datos lo admiten
Escritura aditiva e idempotente	Confirmación resumida; reintento técnico controlado
destructiveHint = true	Confirmación explícita con entidad, clave, compañía y efecto esperado
idempotentHint = false	No reintentar automáticamente tras un timeout ambiguo
openWorldHint = true	Mostrar destino externo y revisar exfiltración, DLP y consentimiento

Esto no significa que Copilot Studio aplique automáticamente esa matriz. Microsoft confirma que el servidor publica las anotaciones para que el cliente llamante pueda decidir. El comportamiento concreto depende del host y de su versión. Debe probarse el canal real; no basta con ver la metadata en un inspector MCP.

Mejoras de datos: menos llamadas y errores menos opacos

Aritmética entre agregados

data_find_entities_sql admite ahora expresiones como:

SELECT SUM(AmountCurDebit) - SUM(AmountCurCredit)
FROM GeneralJournalAccountEntry

El nombre de entidad y los campos son solo un ejemplo de forma; deben sustituirse por entidades y columnas expuestas en el entorno. La mejora permite calcular un saldo en una llamada en lugar de recuperar dos agregados y restarlos en el modelo. Eso reduce latencia, consumo de tool calls y posibilidades de error de orquestación.

Validación de campos

Un campo inválido devuelve un error explícito. Antes podía producir un fallo opaco o una respuesta con una forma inesperada. La recomendación sigue siendo descubrir primero la entidad con data_find_entity_type y obtener su esquema mediante data_get_entity_metadata; la validación mejorada es una red de seguridad, no una excusa para saltarse la metadata.

Timeout en SysDA

Microsoft añade soporte para queryTimeout en el framework SysDA subyacente para el camino de datos del protocolo. La nota no documenta un valor por defecto ni recomienda modificarlo, así que no debe inventarse una cifra. Incluye consultas largas en las pruebas de rendimiento y comprueba cómo presenta el cliente un timeout antes de habilitar reintentos.

Mejoras de formularios y documentos

Las form tools no automatizan píxeles. Trabajan con APIs del servidor y con el view model de la aplicación. En este PQU ganan:

• controles FrameOptionButton = Radio y Check;
• resolución por nombre y dentro de grupos de grid;
• preferencia por controles que no son lookup al establecer valores;
• resolución de etiquetas de menu items, también mediante búsqueda;
• compatibilidad con document upload y document viewer controls.

Hay una discrepancia documental que conviene tratar con cautela. La página general del ERP MCP, actualizada el 19 de agosto, todavía enumera radio buttons, document viewer, DocuUpload y FileUpload como no soportados. La nota de 10.0.49, actualizada nueve días después, anuncia soporte para parte de esos controles en builds PQU concretas. La lectura razonable es que la nota de versión describe el comportamiento nuevo y la página general aún no se ha sincronizado, pero esto es una inferencia. Valida cada formulario y tipo de control en un sandbox antes de diseñar un proceso productivo.

Para adjuntos, además, no confundas control de formulario con transporte de archivos. La documentación específica mantiene límites y caminos distintos: recursos de salida están en preview, las respuestas inline tienen un límite aproximado de 160 KB, los recursos llegan hasta 5 MB y la carga en Copilot Studio usa actualmente un flow y APIs personalizadas de Dataverse, con un máximo documentado de 15 MB.

Implementación y validación paso a paso

1. Verificar el build efectivo

No pruebes solo contra el número funcional 10.0.49. Registra la versión de plataforma y confirma uno de los mínimos de la tabla anterior. Los PQU son acumulativos, pero un entorno 10.0.49 sin PQU-1 todavía no cumple el requisito.

2. Revisar el servidor dinámico

1. En Feature management, comprueba Dynamics 365 ERP Model Context Protocol server.
2. En Allowed MCP Clients, autoriza únicamente los clientes necesarios.
3. Usa un entorno Tier 2+ o UDE; no planifiques CHE.
4. Retira dependencias del servidor estático de 13 herramientas: Microsoft ha fijado su retirada para el 1 de octubre de 2026.

3. Añadirlo a Copilot Studio

1. Abre el agente y entra en Tools.
2. Selecciona Add a tool y filtra por Model Context Protocol.
3. Añade Dynamics 365 ERP MCP server y crea la conexión.
4. Limita el rol de F&O a los deberes y privilegios del proceso.
5. En las instrucciones, prioriza data tools para CRUD y reserva form o action tools para lógica que no pueda resolverse con entidades.

4. Inspeccionar la metadata

Usa un cliente que permita ver la respuesta de tools/list —por ejemplo, la conexión documentada para Visual Studio Code— y conserva un snapshot de nombre, esquema y annotations por versión. No presupongas que todos los clientes muestran estas propiedades en su interfaz.

5. Probar la política HITL

Crea una matriz con al menos:

• consulta de solo lectura;
• creación aditiva;
• actualización;
• eliminación o contabilización irreversible;
• repetición tras timeout;
• acción personalizada X++;
• formulario con option button;
• visualización y carga documental.

Para cada caso registra herramienta elegida, anotaciones recibidas, confirmación presentada, identidad efectiva, compañía, resultado y comportamiento del reintento.

Seguridad y licenciamiento

El servidor filtra menu items, entidades y acciones según el rol de seguridad efectivo. Ese filtrado reduce además el contexto que debe procesar el orquestador. Asigna a la identidad del agente el rol vacío System agent para la exención de licencia cuando aplique y, por separado, solo los roles funcionales mínimos necesarios. Microsoft indica expresamente que no deben añadirse privilegios al rol System agent.

En Copilot Studio, las llamadas se facturan como Agent Action a una tarifa fija que incluye orquestación y ejecución MCP. En otros clientes, Microsoft documenta 0,1 Copilot Credits por tool call, además del coste del modelo del cliente. Las licencias Finance Premium y Supply Chain Management Premium eximen esa ejecución para clientes distintos de Copilot Studio; no eliminan la tarifa fija de Agent Action dentro de Copilot Studio.

Las anotaciones pueden reducir reintentos y llamadas innecesarias, pero no cambian la tarifa. Incluye en observabilidad el número de tool calls por tarea, especialmente si una mejor resolución de controles o una consulta agregada permite reemplazar varios pasos.

Checklist de adopción

Control	Evidencia esperada
Versión	Plataforma igual o superior al build PQU documentado
Descubrimiento	Snapshot de tools/list con annotations
HITL	Prueba de confirmación por categoría de riesgo y por canal
Mínimo privilegio	Rol efectivo y objetos visibles para la identidad de prueba
Reintentos	Política distinta para operaciones idempotentes y no idempotentes
SQL	Agregados aritméticos y errores de campo validados
Formularios	Option buttons, lookup ambiguo, búsqueda y documentos probados
Adjuntos	Tamaño, timeout, preview y flow de carga documentados
Coste	Tool calls por escenario y cliente medidos
Migración	Sin dependencia del servidor estático antes del 1 de octubre

Conclusión

Las anotaciones HITL convierten el catálogo de herramientas del ERP MCP en algo más que una lista de funciones: añaden un vocabulario de riesgo que un cliente puede utilizar antes de tocar el ERP. Es una mejora de arquitectura porque separa tres responsabilidades: el servidor declara el comportamiento, el cliente decide la interacción humana y F&O aplica la autorización real.

El matiz decisivo es que las anotaciones son información, no enforcement. Una adopción segura necesita cliente compatible, confirmaciones verificadas, roles mínimos, protección frente a reintentos y pruebas sobre el build exacto. Con esa disciplina, las mejoras de 10.0.49 reducen llamadas, eliminan ambigüedad y amplían el alcance de los procesos automatizables sin convertir al modelo en la frontera de seguridad.

Referencias oficiales

• Platform updates for version 10.0.49 of finance and operations apps
• Use Model Context Protocol for finance and operations apps
• Build an agent with Dynamics 365 ERP MCP
• Files with Dynamics 365 ERP MCP
• Connect to Dynamics 365 ERP MCP with Visual Studio Code
• MCP specification: Tools
• MCP schema reference: ToolAnnotations