D365 F&O MCP Server

build_d365fo_project

Idempotent

Compile a D365FO model with xppc.exe, blocking until finished to clear stale-symbol build errors and optionally sync the database and run best-practice checks in one call.

Instructions

Build a D365FO model with xppc.exe (compiles the ENTIRE model, not one project). Blocks until done — call ONCE per build, do NOT poll (wait:false = legacy polling mode). fullBuild:true fixes "not been successfully compiled since it was last changed" stale-symbol errors.

Input Schema

TableJSON Schema

Name	Required	Description
`wait`	No	When true (default) the tool blocks until the build finishes and returns the final result in a single call. The agent should make exactly one call per requested build. Set false for legacy fire-and-forget polling behaviour.
`force`	No	Kill any running build processes for this model and restart.
`aosUrl`	No	restartAos root. Default: Infrastructure.HostUrl in AosService web.config; required on UDE.
`dbSync`	No	On a SUCCESSFUL build, also run the database sync (SyncEngine.exe) — REQUIRED after any table/view/data-entity change. true = partial sync of the syncable objects in the project, full-model when it has none; an ARRAY syncs exactly those tables/views (much faster).
`bpCheck`	No	On a SUCCESSFUL build, also run the best-practice checker and append its findings. Prefer this to a follow-up run_bp_check call: one build call instead of two round trips.
`fullBuild`	No	Full recompile of the TARGET model only (deps stay incremental). Use when xppc reports stale symbol errors.
`modelName`	No	D365FO model name to build (e.g. MyCustomModel). Auto-detected from workspace if omitted.
`restartAos`	No	After a successful build (+dbSync), restart the local IIS/IIS Express AOS serving aosUrl.
`waitTimeoutMs`	No	Maximum time (ms) to block when wait:true before returning a "still running" snapshot. Defaults to 30 minutes. The build itself continues in the background.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.19.1Sep 30, 2026

addedInput schema / properties / aosUrl

Added value: +{
+  "description": "restartAos root. Default: Infrastructure.HostUrl in AosService web.config; required on UDE.",
+  "type": "string"
+}

addedInput schema / properties / restartAos

Added value: +{
+  "description": "After a successful build (+dbSync), restart the local IIS/IIS Express AOS serving aosUrl.",
+  "type": "boolean"
+}

Changed3 schema fields changedv1.16.2Sep 1, 2026

changedInput schema / properties / bpCheck / description

Previous value: -"On a SUCCESSFUL build, also run the best-practice checker and append its findings — saves the usual follow-up run_bp_check call."New value: +"On a SUCCESSFUL build, also run the best-practice checker and append its findings. Prefer this to a follow-up run_bp_check call: one build call instead of two round trips."

addedInput schema / properties / dbSync

Added value: +{
+  "description": "On a SUCCESSFUL build, also run the database sync (SyncEngine.exe) — REQUIRED after any table/view/data-entity change. true = partial sync of the syncable objects in the project, full-model when it has none; an ARRAY syncs exactly those tables/views (much faster).",
+  "items": {
+    "type": "string"
+  },
+  "type": [
+    "boolean",
+    "array"
+  ]
+}

removedInput schema / properties / projectPath

Removed value: -{
-  "description": "(Legacy) Absolute path to a .rnrproj file — used only to extract the model name when modelName is not provided.",
-  "type": "string"
-}

Changed2 schema fields changedv1.14.0Aug 25, 2026

addedInput schema / properties / bpCheck

Added value: +{
+  "description": "On a SUCCESSFUL build, also run the best-practice checker and append its findings — saves the usual follow-up run_bp_check call.",
+  "type": "boolean"
+}

removedInput schema / properties / buildReferencedModels

Removed value: -{
-  "description": "DISABLED — always ignored. Rebuilding dependency models on every build slows the run down and referenced models are expected to already be compiled.",
-  "type": "boolean"
-}

Changed1 schema field changedv1.9.0Aug 8, 2026

changedInput schema / properties / buildReferencedModels / description

Previous value: -"Also build all custom/ISV models this model depends on before building the target. Skips Microsoft standard models."New value: +"DISABLED — always ignored. Rebuilding dependency models on every build slows the run down and referenced models are expected to already be compiled."

First observedv1.8.0Aug 4, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare idempotentHint/non-destructive/openWorld=false; the description adds real behavioral context the annotations do not — blocking semantics, single-call contract, the stale-symbol failure mode, and what dbSync/bpCheck trigger. It does not describe the returned result or failure output, so it stops short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four dense sentences, all front-loaded with the critical contract (block, call once, don't poll) before the conditional hints. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutating build tool with no output schema, the description covers the blocking contract, key modifiers, and side-effect triggers. What an agent still cannot learn is the shape of the success/failure response and the default model-resolution behavior beyond 'auto-detected'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so baseline is 3, but the description adds meaning beyond the schema: wait:false is framed as 'legacy polling mode' and fullBuild is tied to a specific error condition rather than a generic 'full recompile'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource+mechanism: 'Build a D365FO model with xppc.exe' and immediately scopes it ('compiles the ENTIRE model, not one project'), which distinguishes it from sibling verify_d365fo_project and the code-check tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit invocation guidance: 'call ONCE per build, do NOT poll', names the legacy alternative (wait:false), and routes conditional work ('fullBuild:true fixes stale-symbol errors') plus bpCheck's preference over a follow-up run_bp_check call.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

build_d365fo_project

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools