Skip to main content
Glama
dynamics365ninja

D365 F&O MCP Server

by dynamics365ninja
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

build_d365fo_project

Idempotent

Compile an entire D365FO model with xppc.exe, blocking until finished; optionally sync database, run best-practice checks, and restart AOS.

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

NameRequiredDescriptionDefault
waitNoWhen 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.
forceNoKill any running build processes for this model and restart.
aosUrlNorestartAos root. Default: Infrastructure.HostUrl in AosService web.config; required on UDE.
dbSyncNoOn 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).
bpCheckNoOn 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.
fullBuildNoFull recompile of the TARGET model only; deps are not built. Use when xppc reports stale symbol errors.
modelNameNoD365FO model name to build (e.g. MyCustomModel). Auto-detected from workspace if omitted.
restartAosNoAfter a successful build (+dbSync), restart the local IIS/IIS Express AOS serving aosUrl.
waitTimeoutMsNoMaximum 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.

  1. Changed1 schema field changedv1.21.0
    • changedInput schema / properties / fullBuild / description
      Previous value: -"Full recompile of the TARGET model only (deps stay incremental). Use when xppc reports stale symbol errors."New value: +"Full recompile of the TARGET model only; deps are not built. Use when xppc reports stale symbol errors."
  2. Changed2 schema fields changedv1.19.1
    • 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"
+}
  3. Changed3 schema fields changedv1.16.2
    • 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"
-}
  4. Changed2 schema fields changedv1.14.0
    • 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"
-}
  5. Changed1 schema field changedv1.9.0
    • 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."
  6. First observedv1.8.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare openWorld=false, idempotent=true, destructive=false. The description adds the critical non-obvious traits: the call blocks until completion, must be invoked exactly once, and wait:false is a legacy polling mode that agents should avoid. These are exactly the behavioral pitfalls an agent would otherwise fall into.

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?

Three tightly packed sentences, front-loaded with the verb and the scope caveat, then the blocking/polling constraint, then the fullBuild remedy. No filler and no repetition.

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, zero-required, mutation-ish build tool with no output schema, the description covers the key risks (blocking, single-call, stale symbols, required post-table-change sync indirectly via dbSync). It does not describe what the final result contains, which is a minor gap given there is no output schema.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter is already documented in the schema (wait, dbSync, fullBuild, restartAos, etc.). The description restates the wait/fullBuild semantics rather than adding new parameter detail, so the baseline 3 applies.

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 and resource (build a D365FO model via xppc.exe) and immediately disambiguates scope: it compiles the ENTIRE model, not one project. This scope distinction is exactly what an agent needs to avoid confusing it with project-level build/verify siblings.

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?

Gives strong operational guidance: call ONCE per build, do not poll, and use fullBuild:true to clear stale-symbol errors. It does not explicitly contrast against siblings like verify_d365fo_project or run_bp_check within the description (the bpCheck preference lives in the schema), so it stops short of full alternative routing.

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

Deploy Server

Other Tools