D365 F&O MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.14.0
Disambiguation5/5
Each tool targets a distinct aspect of D365FO development: reading metadata, searching, generating code, analyzing existing code, file operations, references, labels, patterns, security, extensibility, validation, build, test, review, undo, knowledge, validation, and preparation. Even similar tools like generate_object and d365fo_file(action='generate') are clearly differentiated by their descriptions.
Naming Consistency4/5
Most tools follow a verb_noun pattern (get_object_info, generate_object, analyze_code, etc.), but a few use single nouns (labels, object_patterns, security_info, extension_info) or bare verbs (search, prepare). This is a minor deviation rather than a chaotic mix.
Tool Count4/5
With 23 tools, the count is on the heavier side, but each tool serves a distinct purpose within the complex D365FO development domain. The tool surface covers object management, code generation, analysis, security, extensibility, build, test, validation, and knowledge, so the number is justified rather than excessive.
Completeness5/5
The tool set provides comprehensive coverage of the development lifecycle: reading, searching, generating, creating/modifying/deleting files, reference finding, label management, patterns, security analysis, extensibility analysis, naming validation, workspace setup, project verification, symbol indexing, build, DB sync, BP checking, unit testing, code review, undo, knowledge lookup, and a preparation tool. No obvious gaps prevent core workflows.
Average 4.4/5 across 23 of 23 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 38 of 38 community issues answered or closed in the last 6 months
- 642 commits in the last 12 weeks
- Last stable release on August 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the tool is known to be harmless. The description adds value by explaining what each mode returns (e.g., 'real implementation examples', 'missing standard methods'), offering behavioral context beyond the schema. It doesn't discuss performance or limitations, but the read-only nature is covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief opening and a bulleted list of modes. It is concise enough for a multi-mode tool and front-loads the core action. Every sentence adds information, though the list is somewhat lengthy.
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?
Without an output schema, the description compensates by explaining the return type of each mode (patterns, code examples, gaps, usage). Given the tool's complexity (10 params, 4 modes) and the read-only annotation, the description is sufficiently complete for an agent to select and invoke the tool correctly. Minor gaps remain around edge-case behavior, but not critical.
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 the baseline is 3. The description repeats mode-to-parameter associations (e.g., '[patterns]', '[api-usage]') but does not add substantive meaning beyond what the schema already provides. Each parameter's purpose is already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Learn from the existing codebase' and then enumerates four distinct modes with concrete outcomes (patterns, implementations, completeness, api-usage). It distinguishes itself by naming these modes, though the verb 'learn' is somewhat abstract and it doesn't explicitly contrast with sibling tools like get_method or object_patterns.
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?
It provides an explicit usage directive: 'call BEFORE generate_object(mode="pattern")' for the patterns mode. Other modes are described with their purposes, implying appropriate use cases, but no exclusions or comparisons to alternative tools are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false but no destructive hint. Description adds the interactive session requirement and headless failure, which is useful. However, it does not disclose any side effects (e.g., whether test results are written somewhere, or if it modifies project files). No contradiction with annotations.
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?
Two sentences total, first states purpose, second states a key constraint. No fluff, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool runs tests, one expects some indication of output or return value. The description doesn't mention what happens on success/failure, or what the agent should do with the result. Also doesn't mention whether it's a build-time operation. However, for a test runner, the agent might infer. Still, it's incomplete.
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 covers all parameters with meaningful descriptions. The description does not add extra parameter-level detail; it just mentions the executable. Baseline 3 due to high schema coverage.
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 specific verb 'Execute' and resource 'D365FO unit test class' with the executable SysTestConsole.exe. Clearly distinguishes from sibling tools like run_bp_check or build_d365fo_project.
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?
Provides a clear constraint: requires interactive console session, fails headless. However, it does not mention when to prefer this over related tools like analyze_code or validate_code, nor conditions under which it should be used versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safe read-only behavior, but the description adds valuable context by enumerating the kinds of checks performed (conventions and conflict detection). It does not disclose the exact output format or behavior on invalid names, but given the annotation coverage, this is adequate.
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?
A single sentence that is front-loaded with the core action and includes a concise enumeration of what is checked. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core functionality and constraints well, but with no output schema, it does not mention what the return value represents (e.g., a boolean or a list of violations). Also, usage context and prerequisites are not covered. For a validation tool with moderate complexity, this is a clear gap.
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 parameters are already documented. The description adds semantic context by mentioning extension naming and conflict detection, which maps to the baseObjectName parameter, but it does not add substantive details beyond what the schema already provides. Baseline 3 is appropriate.
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 uses a specific verb ('validate') with a clear resource ('proposed D365FO object name') and explicitly lists the validation aspects (extension naming, ISV prefix, type-specific suffixes, conflict detection). This distinguishes it from sibling tools like validate_code, which focuses on code validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use (before naming or generating an object), but there is no explicit statement of when to use it versus alternatives, nor any exclusions. It does not mention related tools like generate_object or suggest_edt, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety and determinism profile. The description adds value by specifying the exact executable (xppbp.exe) and the nature of the output (BP warnings/errors with rule codes like BPErrorLabelIsText). This goes beyond what annotations provide, though it does not detail side effects or failure modes, which is acceptable for a read-only tool.
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 two sentences: the first states the core action, the second describes the return type with concrete examples. It is front-loaded with the primary purpose, has zero fluff, and every sentence earns its place. Ideal structure for an agent to quickly parse.
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 read-only tool with well-documented parameters and a clear return type (BP warnings/errors with rule-code examples), the description covers essential context. The lack of an output schema is partially compensated by the rule-code examples. It could be slightly more explicit about the structure of the returned findings (e.g., list, grouping per object), but the included examples and parameter hints make it sufficiently complete for an agent to invoke correctly.
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?
The input schema has 100% coverage with detailed descriptions for all six parameters, including usage hints (e.g., 'preferred over targetFilter', 'Auto-detected if omitted'). The description itself adds no additional parameter information, so it stays at the baseline of 3 for schema-covered parameters.
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 clearly states the specific action ('Run Microsoft Best Practices checker (xppbp.exe)') and the resource ('on a D365FO project'). It also mentions the return type (warnings/errors with rule codes) and provides concrete examples, making it distinct from generic analysis tools like analyze_code or validate_code. The purpose is unambiguous and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for running best practice checks but does not explicitly state when to use it vs. alternatives such as analyze_code or validate_code. It lacks guidance on conditions that would prefer this tool over siblings, and does not mention exclusions or prerequisites. The usage context is only implied by the tool's name and stated function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true annotations, the description carries a moderate burden and delivers: it reveals the validate action is '<50 ms, offline', notes domain inference from other params, flags that domain is 'NOT a free-form pattern type', and describes the repair action as 'auto-fill missing required controls.' These specifics add real behavioral context beyond the annotations. The repair action is ambiguous about whether it mutates external state, but given the read-only toolkit framing this is not a clear contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely organized with a two-level hierarchy (domain → action) and consistent mode tags, front-loading the core 'choose a domain' concept. Given the tool's complexity — 12 parameters, 2 domains, 4 actions, nested recommend object — the length is justified and every section earns its place. Well-structured use of bold and bullets aids scanning.
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 high-complexity tool with no output schema, the description covers a great deal: domain inference rules, the recommendation decision flow, per-action return expectations ('Returns FP001-FP010 violations', 'full structure spec', 'a recommended pattern + reference forms to clone'), and when to call each action. Minor gaps exist around exact return formatting, but for the tool's breadth this is a thorough, near-complete description.
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 the baseline is 3 and the schema already documents every parameter with mode tags ([validate], [analyze], [spec]) and REQUIRED markers. The tool description adds workflow context that ties parameters together (e.g., recommend is 'preferred for a new form'), but the heavy lifting for parameter meaning lives in the schema's per-property descriptions, so it doesn't rise above baseline.
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 immediately establishes the resource (D365FO table and form patterns) with a specific verb ('Pattern toolkit. Choose a domain:'). It enumerates distinct modes (analyze, spec, validate) and even steers away from a sibling by stating that 'a concept like "number-sequence"/"SysOperation" belongs to get_knowledge, not here.' This clearly differentiates it from get_knowledge and other 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?
The description gives explicit workflow sequencing: RECOMMEND for new forms, 'Call after analyze, before building' for spec, 'Call before action=create on d365fo_file' for validate. It also states a when-not rule by excluding pattern-type concepts that belong to get_knowledge. It doesn't exhaustively compare against every sibling alternative, but the internal action ordering and explicit get_knowledge exclusion provide strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context like partial sync being 'much faster' and auto-extraction via projectPath, but it does not explicitly disclose that this modifies the database schema or that full sync could be time-consuming. It neither contradicts annotations nor adds substantial safety/side-effect information, so a mid-range score is appropriate.
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 three concise sentences with no fluff. It front-loads the primary verb and resource, then provides actionable guidance in an efficient, scannable manner. Every sentence contributes meaning.
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 write operation with no output schema, the description provides enough context for an agent to decide when to call it and how to parameterize it. It covers the main usage modes and the key automation feature. It does not describe return values or error behavior, but for an action tool that auto-detects most settings, this is acceptable.
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?
Input schema covers 100% of parameters, so baseline is 3. The description adds value beyond the schema by explaining the projectPath auto-extraction trick and when to use the tables parameter for partial sync, enhancing parameter understanding. This pushes the score above baseline.
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 clearly states the action 'Run a D365FO database sync' and even names the executable 'SyncEngine.exe'. It also distinguishes internal modes (partial vs full sync), making the tool's purpose unmistakable and differentiating it from the many sibling tools that handle building, validation, or analysis.
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 provides explicit when-to-use guidance: 'Use partial sync after adding/renaming fields or indexes on known tables' and 'Use full sync only when unsure what changed.' It also instructs on passing projectPath for auto-extraction. However, it does not explicitly contrast this tool with sibling tools (e.g., build_d365fo_project), so the 'vs alternatives' criterion is only partially met.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive behavior, but the description adds valuable context beyond that: it blocks until completion, the wait parameter behavior, and the fact that it compiles the entire model. It also explains the fullBuild stale-symbol fix, which is behavioral detail not present in annotations. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core purpose and key usage constraints. It avoids redundant elaboration and fits within two clauses while covering the most critical behavioral notes. It is concise without being under-specified.
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 build tool with no output schema, the description covers the essential operational knowledge: blocking behavior, polling guidance, fullBuild purpose, and model scope. It does not explicitly mention the return format, but the schema's wait parameter details that, and the description's 'call once' implies a final result. The coverage is strong for the tool's complexity.
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?
With 100% schema description coverage, the baseline is 3. The description enhances parameter understanding by explaining wait:false as legacy polling mode and highlighting fullBuild's role in fixing stale-symbol errors. It adds practical context that the schema alone does not convey, raising the score above baseline.
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 clearly states the tool builds a D365FO model using xppc.exe, and explicitly distinguishes it from building a single project by noting it compiles the entire model. This accurately separates it from sibling tools like verify_d365fo_project or run_bp_check, making its purpose unmistakable.
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 usage instructions: call once per build, do not poll, and explains that wait:false is legacy polling mode. It also mentions fullBuild for fixing stale-symbol errors, providing concrete guidance on when to use that parameter. However, it does not directly state when to prefer alternative tools, though the clear purpose implicitly handles that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=false and destructiveHint=false, so the tool may have side effects. The description adds valuable context by explicitly marking 'pattern' mode as 'text only, no write' and by instructing the agent to fetch mode-specific contracts via get_knowledge before invoking, which sets expectations about parameter discovery. It also mentions that a missing required param returns the complete spec (via schema param description), but the main description does not fully clarify whether scaffold modes write files or just return code, leaving slight ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a clear bulleted list of modes, and each sentence earns its place by explaining one mode or a workflow step. It is a bit long (six bullets plus two paragraphs of guidance), but the density of information justifies the length. The front-loaded first sentence immediately states the tool's purpose.
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?
Given the tool has six parameters, a nested object, and no output schema, the description covers the main invocation context: it lists all modes, tells how to obtain mode contracts, and mentions the alternative d365fo_file for generating XML. It does not explicitly describe the return format for scaffold or XML modes, but the lack of an output schema makes this less critical, and the description does provide enough context to select and invoke the tool correctly.
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 the schema already defines each parameter with enums and per-field descriptions. The description's main added value is telling the agent that mode-specific parameters are NOT inlined and must be retrieved via get_knowledge(kind='op-spec', topic='<mode>'), which is important for correct invocation. However, it does not add further meaning beyond what the schema already provides; per calibration, baseline 3 is appropriate.
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 opens with a specific verb+resource: 'Generate X++/AOT code.' It then enumerates six distinct modes, each with a concise purpose, which clearly differentiates the tool from alternatives like d365fo_file (used for XML generation). The inclusion of mode-specific behaviors (e.g., 'text only, no write') removes ambiguity about what each invocation does.
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 explicitly tells the agent when to use this tool versus alternatives: call analyze_code(mode='patterns') first, then generate_object(mode='pattern'), then d365fo_file(action='create'). It also states to use d365fo_file(action='generate') for existing object XML instead. This provides clear, actionable usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the description need not restate safety. It adds genuine behavioral value with the critical warning that extensions results carry SOURCE models and 'never use them as create/modify targets' — a non-obvious trap an agent must know. It also discloses batch dedup and cross-reference behavior, though it stops short of describing pagination or empty-result handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the opening sentence, followed by scannable bullet points per mode and one routing sentence. It is longer than the average description, but every sentence earns its place — the SOURCE-model warning and sibling routing are load-bearing. No filler or repetition of the title.
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 complex 7-parameter, 3-mode tool with no output schema, the description covers purpose, mode selection, the key behavioral caveat, and sibling routing. It states single-mode returns (name, type, model) but leaves batch/extensions return structure unspecified — a minor gap acceptable given no output schema and the annotation-provided safety profile.
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 coverage is 100%, so each of the 7 parameters is already documented (with mode-tag [single]/[batch]/[extensions] and mode-routing notes like 'Ignored when queries[] is provided'). The description reinforces the mode structure and adds the useful 'max 10' batch cap, but largely restates what the schema already communicates — appropriate for the 100%-coverage baseline.
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 ('Search pre-indexed D365FO objects by name or keyword') and enumerates three concrete modes with distinct inputs. It explicitly differentiates from the closest sibling, get_object_info, naming the exact condition ('when you already know the exact name and need full details') that selects the alternative.
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?
Gives explicit routing: 'Use get_object_info(objectType, name) when you already know the exact name' is a crisp this-vs-that exclusion. The three modes each carry trigger conditions (default single, batch for parallel with max 10, scope:'extensions' to restrict to custom/ISV models), so an agent knows exactly when and how to invoke each path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, and the description's verification semantics are consistent with those. The description adds value beyond the annotations by disclosing what is actually checked (AOT path existence on disk and .rnrproj references), plus the projectPath requirement for the reference check. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with the core purpose front-loaded in the first sentence, followed by usage guidance and the omission behavior. The final sentence is slightly dense with the parenthetical, but overall there's no filler and every sentence earns its place.
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 read-only verification tool with no output schema, the description adequately covers what is verified, when to use it, and the key parameter behaviors. The only gap is that it doesn't describe the return format (e.g., success/failure structure), which an agent might want, but this is minor and the description is otherwise complete for a verification operation.
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 schema already documents all five parameters. The description still adds meaningful nuance beyond the schema, specifically around `objects` ('omit to verify every object referenced in the project') and `projectPath` ('Required for project-reference check'), which clarifies behavior parameters alone don't convey. Schema carries most weight, but the description enriches it rather than merely repeating it.
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 that D365FO objects exist on disk at the correct AOT path and are referenced in the .rnrproj project file.' It precisely distinguishes the tool from its siblings by naming its check scope (disk path + project reference), which differentiates it from nearby tools like d365fo_file, build_d365fo_project, and find_references.
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 explicitly routes usage: 'Use instead of PowerShell to check d365fo_file(action="create") results,' which tells the agent when to reach for this tool over an alternative. It also explains the omit-objects workflow for verifying the entire project and states the projectPath prerequisite. It doesn't enumerate sibling exclusions, but the guidance given is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so a read operation is understood. The description adds meaningful behavioral detail beyond that: the method-name-matches-every-type over-reporting behavior, that label results span every object type (not just code), and the DYNAMICSXREFDB/full-server-mode requirement. This enriches the safety/behavioral profile without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place — method scoping, label semantics, and prerequisites are all operationally critical for correct invocation. It is front-loaded with the core purpose and scoping rule before edge cases. Slightly dense but 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?
Comprehensive for a read tool whose annotations already cover safety: all target types, method-scoping edge cases, label behavior, and the xref prerequisite are covered. The only gap is that with no output schema, the return format/pagination behavior (relevant given the limit param) is not described. Otherwise nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description substantially enriches parameter meaning. It explains the targetName scoping rule for methods (Owner.method vs bare name vs AOT path), the exact label id format ('@WAX2194' or '@MyLabelFile:MyLabel'), and how ownerName scopes a bare method name. It also clarifies targetType's 'label' value and the '@…' shortcut. This goes well beyond the schema's one-line parameter 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?
States a specific verb and resource: 'Find all references (where-used) to a class, method, field, table, enum, or LABEL.' This clearly distinguishes it from siblings like search (general search), get_object_info, and validate_code. The 'Essential for impact analysis before refactoring' line reinforces the distinct role. No tautology.
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?
Provides strong usage context — 'Essential for impact analysis before refactoring' — plus concrete invocation patterns (Owner.method, ownerName, AOT path) and an explicit over-reporting warning for bare method names. Covers label usage and its xref database prerequisite. It doesn't name which sibling to use instead in specific cases, but the guidance is otherwise explicit and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, and the description adds crucial specifics: modify applies immediately with no dry-run, delete is irreversible and reports ❌ when not found (never silent no-op), and create is incomplete until isError=false. It also notes .rnrproj registration handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but tightly structured with bullet points per action and clear warnings. It front-loads the primary actions and then details parameter relationships. It could trim some repetition (e.g., 'confirm with the user first' appears twice) but remains focused.
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 complex tool with 16 parameters and 4 actions, the description covers the core workflow, parameter dependencies (op-spec lookup), and behavioral caveats (irreversibility, Windows requirement, extension naming). It doesn't explain return values but has no output schema, so that's not required. Minor gaps: specific error handling beyond 'isError=false' and interaction with workspace paths could be more explicit, but adequate.
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 has 100% coverage, but the description adds meaning beyond it: modelName must never come from search results, objectName should never have prefix hand-built, operations array preferred for batch edits with order and failure handling, and properties/params require get_knowledge. These nuances aren't in the schema.
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 clearly states four specific actions (create, modify, delete, generate) acting on a D365FO AOT object, and distinguishes each with distinct semantics. It explicitly mentions writing into PackagesLocalDirectory for create and XML text for generate, making it distinct from sibling tools like get_object_info or search.
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?
Provides explicit when-to-use guidance: generate as an Azure/Linux fallback ('try create first'), Windows requirement for create/modify/delete, confirmation needed for modify (immediate apply) and delete (irreversible), and pointer to get_knowledge for operation-specific contracts. It also references undo_last_modification as a revert path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, so the tool is known to be read-only. The description adds behavioral context by detailing what each mode returns or analyzes (e.g., effective merged schema, available extension points, who already wraps). It also notes that showExistingExtensions 'roughly doubles the response', a practical performance trait. It does not contradict annotations and adds value beyond them, though it doesn't cover potential errors or latency.
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 a compact bulleted list, front-loaded with a clear one-line purpose. Each mode is described in one or two sentences with no redundancy. The structure is scannable and every sentence earns its place, from the overall analysis purpose to mode-specific guidance.
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 tool with 10 parameters and 5 modes, the description covers all modes and their intended use cases, including which parameters are relevant per mode. It explains outputs (e.g., merged schema, extension points, recommendations) sufficiently without an output schema. No missing critical information prevents an agent from calling the tool correctly, making it complete.
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% with detailed per-parameter descriptions (e.g., mode: 'coc/events/table-merge/points need target; strategy needs goal'). The description adds mode-level context but does not introduce new parameter meanings beyond the schema. Since the schema already documents parameters thoroughly, the baseline of 3 is appropriate; the description names which modes use which parameters, slightly aiding selection but not adding substantial semantics.
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 'D365FO extensibility analyzer' and enumerates five distinct modes (coc, events, table-merge, points, strategy) with specific resources and goals. Each mode is tied to a concrete action (e.g., 'Chain of Command extensions + event subscriptions for a class/table'), making it unambiguous what the tool does and how it differs from generic search or analysis 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?
Every mode includes explicit usage context: 'Use before writing a CoC extension to check for conflicts', 'Use before adding handlers to check for duplicates'. The strategy mode states it 'recommends the best extensibility mechanism for a goal', and the description explains which parameters each mode requires. This provides clear when-to-use guidance for each variation, effectively distinguishing from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds genuine value beyond that: the max-10 batching limit, per-object-section return shape, dot-suffix stripping for extension names, and the class members fast path. These are real behavioral disclosures that annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Core purpose is front-loaded and every sentence earns its place — batching, type selection, extension behavior, and class fast path are all high-value. It is dense to the point of being a single wall of text, and would benefit from light structural segmentation, but there is no filler or redundancy.
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 genuinely complex tool (4 params, nested objects, 20 objectTypes, numerous option flags, extension handling, no output schema), the description covers the critical usage surfaces well: return shape is hinted ('per-object sections back'), batching is explained, and the class special case is handled. The options field leans on the schema, which is acceptable given 100% coverage. Minor gaps remain around exact return formatting for non-class reads.
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: the name-vs-objects mutual requirement ('REQUIRED unless using objects[]'), per-object options overriding top-level options, and the class member syntax {'members':'names'} with optional prefix. This meaningfully enhances what the schema provides.
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?
Opens with a specific verb+resource ('Read D365FO object metadata') that precisely distinguishes it from sibling tools like search, generate_object, and find_references. The full objectType enum, extension-type semantics, and class-members fast path make the scope unmistakable even before consulting the schema.
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?
Gives explicit batching guidance ('for 2+ objects pass objects:[...], max 10 — ONE call, run in parallel, never loop single calls'), the exact condition for picking extension types, and a firm exclusion ('never shell out to find or read a file'). Schema adds 'use search first if unsure'. This is exemplary when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral detail: it discloses that artifact mode returns the full hierarchy (Role → Duties → Privileges → Entry Points) and coverage mode returns the reverse chain. This goes beyond the annotation without contradicting it, though it doesn't cover error cases or permissions.
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 two concise sentences with clear bullet-like mode breakdowns. Every phrase earns its place: it names the tool domain, the two modes, and the exact output shape for each. No fluff or redundancy.
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?
Despite having no output schema, the description explicitly states the return value shape for both modes (full hierarchy and reverse chain). With 100% schema coverage on parameters and readOnlyHint annotation, this is sufficient for an agent to select and invoke the tool correctly.
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 conceptual meaning beyond the schema by explaining the relationship between modes and the direction of traversal (forward hierarchy vs reverse chain). This helps the agent understand how the parameters like name, objectName, and includeChain fit together.
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 clearly identifies the tool as a 'D365FO security lookup' and specifies two distinct modes (artifact and coverage) with explicit arrow chains showing what each returns. This differentiates it from sibling tools like get_object_info and search by focusing on security hierarchy lookup.
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 clear usage context by explaining when to use artifact mode (look up a named privilege/duty/role) vs coverage mode (find who can access an object). However, it does not explicitly mention when not to use this tool or name alternative sibling tools for overlapping use cases, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is established. The description adds meaningful behavioral guarantees beyond that: for bp-moniker it states the tool is 'Backed by names/text extracted from a real D365FO install — never invents a moniker,' which addresses hallucination risk explicitly. For error diagnosis, it promises 'structured root cause + step-by-step fix + corrected X++ example,' setting expectations for output shape. It does not contradict the annotations and provides context that is not present in structured fields, so a 4 is warranted (not 5, as it omits details like rate limits or potential failure modes, though these are less critical for a read-only tool).
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 long but every sentence earns its place. The purpose is front-loaded ('X++ knowledge lookup'), followed by a bulleted breakdown per `kind`, each with clear action verbs and usage timing. The parameter descriptions are terse yet complete, and the overall structure is scannable. There is no padding or repetition; the length is justified by the four distinct modes, and the formatting improves comprehension. This is a model of efficient technical writing.
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 tool with 10 parameters, 4 enum-driven kinds, and no output schema, the description is outstandingly complete. It details every kind's purpose, required parameters, usage timing, and examples, and even explains the rationale for op-spec (that other tools omit inline params). It also clarifies fallback behavior ('Omit topic for the index'). The only thing missing is a description of the return payload, but because it is a knowledge lookup (not an operation), the output shape is less critical and the description hints at what each kind returns (e.g., 'structured root cause + step-by-step fix'). An agent would have no difficulty calling this tool correctly.
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 description coverage is 100%, so per calibration the baseline is 3. The description significantly exceeds that baseline by prefixing each parameter with its applicable kind (e.g., '[knowledge] REQUIRED', '[bp-moniker validate/suppress] REQUIRED') and explaining cross-parameter relationships that the schema does not. For instance, it states 'Omit topic for the index of available topics' (not in schema), explains that `topics` 'Replaces topic' for batch lookups, and provides concrete examples for `topic` values. These additions substantially aid parameter selection beyond the raw enum/type info, so a 4 reflects the incremental value.
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 opens with 'X++ knowledge lookup' and then enumerates four distinct `kind` values (knowledge, error, op-spec, bp-moniker), each with a concrete verb+resource pairing (e.g., 'look up an X++ topic/rule', 'diagnose a D365FO/X++ compiler or runtime error', 'parameter contract for ONE d365fo_file operation'). It clearly differentiates the tool from siblings by focusing on lookup/query behavior rather than generation or execution, and the examples (e.g., 'select-statement', 'TTS mismatch') make the scope unmistakable.
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, kind-specific usage instructions: 'Use BEFORE generating code' for knowledge, 'Call this instead of guessing — X++ error semantics differ from C#/.NET' for error, 'call this after picking the operation, before the call' for op-spec, and detailed validation/search/suppress guidance for bp-moniker. It also notes that op-spec exists because 'those two tools deliberately do not ship their parameters inline,' which explains the necessity of this lookup and implicitly warns against using the tool prematurely. No exclusions are stated, but the guidance is strong enough to route the agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds valuable behavioral context: it flags placeholder model names and missing prefix, and clarifies that projectName/projectPath are ignored unless the user changed the project. This goes beyond the annotations, though it does not describe return format or error behavior.
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 compact and front-loaded with the most important instruction ('ALWAYS call FIRST at session start'). Every sentence provides distinct value: what returns, flags, param usage, and authority. No filler or redundancy.
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 tool with no output schema, the description lists the key returned fields and behavioral nuances. It covers invocation timing, parameter conditions, and authoritative scoping. The annotations and schema handle safety and parameter details, leaving no significant gaps for an agent to misuse the tool.
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% with detailed descriptions for all three parameters. The description adds extra meaning by reinforcing when projectName/projectPath should be used and explaining why projectName is not a model name (selecting none if named). This supplements the schema without duplicating it.
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 clearly states the tool returns workspace configuration (model name, package path, framework directory, project path, environment type, EXTENSION_PREFIX). It also explicitly distinguishes itself as the authoritative source for the target model, unlike search results, which differentiates it from sibling tools like search and get_object_info.
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: 'ALWAYS call FIRST at session start.' It also specifies when to use parameters ('projectName/projectPath ONLY when the USER changed project') and warns against misuse ('NOT a model name'). It further sets an exclusion: 'not search results,' clarifying when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral nuance beyond the readOnlyHint: it works specifically on uncommitted changes (git diff HEAD), is limited to Windows/local mode, and warns against reading .xml/.xpp files if the diff appears truncated. These operational details are not covered by annotations and help the agent understand edge cases.
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 sentences cover purpose, exclusions, and a critical behavioral warning. The structure is front-loaded with the main purpose, followed by alternatives and a caveat, with no wasted words.
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 single-parameter read-only tool with good annotations, the description covers purpose, usage boundaries, and a specific failure scenario. The lack of an output schema is acceptable as the review output is self-explanatory from the stated purpose.
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?
The schema already fully describes directoryPath with 100% coverage, so the description doesn't need to restate it. The description reinforces the parameter's role in the tool's context but does not add new semantic meaning beyond the schema.
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 clearly defines the tool as a code review for uncommitted X++ changes (git diff HEAD), specifying BP violations, missing labels, and CoC patterns. This specific verb+resource+scope distinguishes it from siblings like verify_d365fo_project and get_object_info.
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?
Explicitly states when NOT to use the tool (verifying writes) and names the alternative tools (verify_d365fo_project + get_object_info). Additionally, it specifies 'Windows/local mode only' and gives guidance for truncated diffs, making usage context and exclusions clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds specific consequences: discarding ALL uncommitted changes for tracked files, deleting untracked files, and re-syncing the symbol/label index. It also discloses the side effect that a manual revert would leave stale, which is beyond the annotation's binary flag. No contradiction with annotations.
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 front-loaded with the core purpose in the first sentence, then immediately provides essential behavioral details in two concise sentences plus a terse note about the local companion mode. Every sentence earns its place; no filler or redundant phrasing.
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?
The tool's behavior depends on file tracking state, which the description fully covers. It also addresses the index re-sync side effect and the required environment (write-only/local mode), which are critical for correct usage. No output schema exists, but for a destructive rollback tool, describing output is less critical; the description covers all inputs and side effects an agent needs to invoke it safely.
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 description coverage is 100% for filePath, and the baseline for parameter semantics is 3. The description adds substantial meaning by explaining that the same filePath parameter triggers git checkout HEAD for tracked files or deletion for untracked files, which is not evident from the schema alone. This enriches the parameter's semantics meaningfully.
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 ('roll back') and resource ('a file'), with exact behavior for tracked vs untracked paths. Distinguishes itself from manual git revert and editor undo by mentioning the index sync side effect, which separates it from any sibling that might also touch files.
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?
Provides clear context about what the tool does and notes it is a local companion tool in write-only/local mode. It explains the destructive scope (all uncommitted changes, not just the last edit), which implicitly warns against misuse. However, it does not explicitly list when to prefer this over sibling tools (e.g., update_symbol_index) or when not to use it, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, and the description does not contradict them. It adds valuable behavioral details: the 30-min TTL for the groundingToken, its requirement for writes under a config flag, and the fact that the response embeds full parameter contracts, which goes beyond the annotations.
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 densely informative but well-structured with bolded mode names and bullet points. It front-loads the core purpose and TTL requirement, and every sentence serves a distinct explanatory purpose without redundancy.
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?
Given there is no output schema, the description compensates by enumerating the kinds of outputs for each mode (signature, wrappers, eligibility, collision check, naming, etc.). It also explains the groundingToken's role, providing sufficient context for an agent to anticipate what the tool returns and when to invoke it.
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 parameters are already well-documented. The description adds useful cross-tool semantics (e.g., objectName 'same value you would pass to d365fo_file create'), notes that operation's full contract returns in the response, and explains mode-specific defaults, enhancing the schema's field 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 clearly identifies the tool as a 'ONE-call context aggregator' that prepares grounded context for change or create operations. It specifies the exact two modes (change/create) and what each delivers, and explicitly distinguishes itself from the analyze→search→info→generate loop seen in sibling 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?
The description provides clear when-to-use guidance: it replaces a multi-step loop and is required for writes when GROUNDING_ENFORCE=true. It explains when to choose 'change' vs 'create', and each mode's purpose is spelled out, giving the agent explicit decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, matching the description's explicit 'write' tags for create, update, rename. The description adds valuable behavioral detail: create writes to every language .label.txt, update overwrites existing text, rename affects multiple file types, bulk mode behavior (failed entry doesn't abort batch), and auto-resolution of write plumbing. This is transparent and adds context beyond annotations.
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 well-structured with a clear introductory sentence, bulleted action items, and explicit parameter usage notes. Despite its length, every sentence serves a purpose—either defining an action, clarifying input formats, or providing operational tips (e.g., bulk mode, createIfMissing). It is organized for quick scanning and front-loads the core purpose.
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 tool with 14 parameters and multiple actions, the description covers all critical aspects: per-action parameter requirements, edge cases (bulk failures, missing labelId), write plumbing auto-resolution and override path, and safety (dryRun for rename). It also cross-references get_knowledge for deeper details, ensuring an agent has enough context to invoke correctly without an output schema.
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 meaningful semantics beyond the schema: labelId accepts various spellings (SYS67433, @SYS67433, @ContosoExt:MyLabel) and clarifies that omitting it lists label files; labels[] explains bulk mode and top-level field suppression; params explains auto-resolution and points to get_knowledge for contract. These additions raise it above the baseline, but not maximal since some parameters (e.g., verbose, maxResults) rely on schema descriptions without extra context.
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 clearly states it is a unified label operations tool with read/write actions and enumerates each action (search, info, create, update, rename) with concise purpose statements. It distinguishes these actions from each other and from sibling tools by focusing on label-specific operations, making the tool's purpose unambiguous.
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?
Provides explicit guidance for when to use each action, including required parameters, examples (e.g., createIfMissing for reuse, bulk mode via labels[]), and even advises dryRun for rename. It clarifies when to use create versus update and how to override auto-resolved write plumbing via get_knowledge, giving clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by explaining the cost of each call ('each call costs a bridge refresh'), the fact that it indexes files changed outside this server, and the distinct behavior of omitting filePath. It also imparts the efficiency warning about wasted round trips, which is valuable operational context that annotations alone do not provide.
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 compact yet information-dense. It leads with the core purpose, immediately follows with an explicit exclusion, and then covers a niche use case and a special parameter omission. Every sentence earns its place with no redundancy or filler.
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?
Given the tool's moderate complexity (one optional parameter, no output schema), the description is complete. It covers main use, misuse, special cases, and performance considerations, leaving no ambiguity about when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already documents filePath, the description adds crucial semantics: batching for arrays, the performance cost per call, and the special meaning of omitting filePath (bridge/cache refresh only, no symbol-DB indexing). This adds significant value beyond the raw schema.
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 clearly states the tool's purpose: indexing D365FO XML files changed outside the server. It distinguishes itself from sibling tools like d365fo_file create/modify by explicitly noting they refresh the index automatically, making this tool only for external changes.
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 provides explicit when-to-use and when-not-to-use guidance. It warns against calling after d365fo_file create/modify and gives a specific genuine use case (naming a new AxEdt/AxEnum in generate_object), plus explains the special case of omitting filePath for a bridge/cache refresh only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, but the description adds substantial behavior: offline execution, index-only reference resolution, structured violations with specific fields, and catching hallucinated symbols. It even discloses internal behavior of other tools (write tools running references). No contradiction with readOnlyHint.
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 well-structured with bullet points for modes, a clear call-to-action sentence for timing, and a note about configuration. Every sentence adds new information; there is no fluff or repetition.
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?
Despite having no output schema, the description covers what each mode returns (structured violations, symbol existence checks), when to call, and even mentions configuration flags. It fully equips an agent to correctly invoke the tool without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description goes far beyond by explaining the mode enum in detail (what syntax and references each do), how codeType='xml-table' changes reference checking, and the context parameter's purpose. This adds meaningful semantic value to the parameters.
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 clearly states the tool validates generated X++/XML, and further distinguishes two modes (syntax and references) with specific purposes. It differentiates from siblings by being offline (no xppbp.exe) and index-only, which is a precise, non-tautological definition.
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?
Explicitly instructs to call mode='both' AFTER generating and BEFORE writes, and recommends fixing errors in the same turn. It also explains when the tool may be redundant (write tools run references internally under GROUNDING_ENFORCE). This provides clear timing and alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![d365fo-mcp-server MCP server](https://glama.ai/mcp/servers/dynamics365ninja/d365fo-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/dynamics365ninja/d365fo-mcp-server)

Score Badge

Copy to your README.md:

[![d365fo-mcp-server MCP server](https://glama.ai/mcp/servers/dynamics365ninja/d365fo-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/dynamics365ninja/d365fo-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dynamics365ninja/d365fo-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server