D365 F&O MCP Server

build_d365fo_project

Idempotent

Compile an entire D365FO model with xppc.exe, blocking until the build completes. Use fullBuild to resolve stale-symbol compilation errors and dbSync to sync database changes after success.

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.
`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.
`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.

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.4/5.0

Behavior4/5

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

Beyond the annotations, the description discloses several important behaviors: it uses xppc.exe, compiles the entire model, blocks until completion, warns against polling, and explains that fullBuild addresses a specific stale-symbol error. It does not mention dbSync/bpCheck side effects, but those are already described in the input schema.

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?

The description is dense and well-structured: three sentences, each carrying a distinct high-value fact. It front-loads the most important semantic clarification (entire model vs one project) before moving to call behavior and the stale-symbol fix.

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?

With 7 optional parameters and 100% schema coverage, most operational details are already captured in structured fields. The description covers the tool-level semantics and the main gotcha. It does not describe a formal output contract, but the wait parameter already promises the final result in a single call.

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 the baseline is 3. The description adds value by quoting the exact stale-symbol error that fullBuild fixes and by clarifying wait:false as legacy polling mode. Other parameters are well-covered by the schema, so no serious gap exists.

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?

The description states a specific verb and resource: it builds a D365FO model with xppc.exe. It immediately clarifies scope by saying it compiles the ENTIRE model, not one project, which distinguishes it from sibling tools like verify_d365fo_project and run_bp_check.

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

Usage Guidelines4/5

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

The description gives explicit operational guidance: block until done, call once per build, do not poll, and treat wait:false as legacy polling mode. It also gives a concrete condition for using fullBuild (stale-symbol errors), though it does not name alternative tools for when not to build.

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