Skip to main content
Glama
dynamics365ninja

D365 F&O MCP Server

by dynamics365ninja
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

verify_d365fo_project

Read-only

Validate D365FO objects after a build by checking they exist on disk at correct AOT paths and are listed in the .rnrproj project file. Omit objects to validate the whole project.

Instructions

Verify that D365FO objects exist on disk at the correct AOT path and are referenced in the .rnrproj project file. Use instead of PowerShell. Runs AFTER a build, not after a write: d365fo_file already verifies its own write inline (on disk + .rnrproj reference) and says so in its response. Omit objects to verify the ENTIRE project: every object referenced in the .rnrproj is checked on disk (requires projectPath, or an auto-detected/configured project).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
objectsNoList of objects to verify. OPTIONAL — omit to verify every object referenced in the project (.rnrproj).
modelNameNoModel name. Auto-detected if omitted.
projectPathNoAbsolute path to the .rnrproj file. Required for project-reference check.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.16.2
    • removedInput schema / properties / packageName
      Removed value: -{
-  "description": "Package name. Auto-resolved from model name if omitted.",
-  "type": "string"
-}
    • removedInput schema / properties / packagePath
      Removed value: -{
-  "description": "Base package path (default: auto-detected PackagesLocalDirectory)",
-  "type": "string"
-}
  2. Changed1 schema field changedv1.14.0
    • changedInput schema / properties / modelName / description
      Previous value: -"Model name. Auto-detected from mcp.json if omitted."New value: +"Model name. Auto-detected if omitted."
  3. First observedv1.8.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true, and the description adds useful behavioral context: the tool runs after build, is read-only verification, and supports scoped vs whole-project verification. It does not describe result/output or failure behavior, but this is a minor gap given the read-only nature.

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 but every sentence earns its place: core purpose, alternative tool, timing, and the important omit-objects behavior. It is front-loaded with the primary verification action and keeps all guidance relevant.

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

Completeness5/5

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

For a read-only verification tool with three optional parameters and no output schema, the description supplies sufficient context for correct selection and invocation. It covers scope, timing, prerequisites, and the key alternative, so an agent can act without further clarification.

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, but the description adds meaning beyond the schema by clarifying that omitting `objects` verifies every object in the project and that projectPath is needed for project-reference checking or can be auto-detected/configured. This goes beyond the raw schema descriptions.

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: verify D365FO objects exist on disk at the correct AOT path and are referenced in the .rnrproj project file. It clearly distinguishes this from related tools like d365fo_file by noting it runs after a build rather than after a write.

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?

The description gives explicit when-to-use guidance: after a build, not after a write, and names d365fo_file as the alternative that already verifies its own write inline. It also explains the omit-objects behavior for verifying the entire project and notes the projectPath requirement, leaving little to inference.

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