ALM X++ MCP Server

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

The description discloses that the tool performs read-only analysis (consistent with readOnlyHint=true) and produces a review comment but does not write itself. It details the analysis steps but does not cover error conditions or edge cases, though annotations already signal read-only behavior.

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

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

The description is efficiently structured with a front-loaded trigger section and numbered analysis steps. Each sentence adds value with no redundancy, and the overall length is appropriate for the information conveyed.

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

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

The description covers the tool's purpose, usage, prerequisites, and post-call action. However, it lacks explicit details about the output format (beyond a comment) and error handling, which would be helpful given no output schema.

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

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

Schema description coverage is 100%, with each parameter well-described. The tool description adds no new parameter-level meaning beyond what is in the schema, so it meets the baseline but does not exceed it.

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

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

The description clearly states the tool's purpose: to analyze the full D365 F&O code impact of a Pull Request, listing four specific analysis areas. It distinguishes from sibling tools like search_d365_code by explicitly saying not to call it when PR is mentioned.

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

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

The description provides a priority trigger with explicit phrases for when to use the tool, explicitly states when not to call search_d365_code, lists prerequisites (DEVOPS_ORG_URL, DEVOPS_PAT), and instructs to call ado_post_pr_comment after analysis.

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

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

Annotations indicate readOnlyHint=true, and the description reinforces this by explaining the tool returns 'raw structured context only -- NOT a finished analysis' and lists exactly what is returned. It also describes the expected behavior after calling the tool (synthesize analysis in French). No contradictions 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.

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

The description is well-structured with sections and bullet points, but it is quite verbose (over 300 words). It includes detailed post-call instructions that could be made more concise. It is not minimal but remains clear and organized.

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

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

Given the tool has 6 parameters, no output schema, and high complexity, the description is exceptionally thorough. It covers all parameter behaviors, return structure post-call actions, and environment requirements. No gaps are apparent.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by providing context beyond the schema, such as explaining that 'project' falls back to an env var, that 'focusObjects' speeds up analysis, and that 'includeImages' adds latency. This exceeds the baseline.

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

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

The description explicitly states the tool's purpose: 'Fetch a Work Item and assemble ALL technical context needed for D365 F&O expert analysis.' It uses specific verbs ('fetch', 'assemble') and names the resource ('Work Item'). It distinguishes from sibling tools like 'search_labels' and 'search_d365_code' by specifying what the tool is NOT for, making it clear this tool is for holistic work item analysis.

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

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

The description provides explicit guidance on when to use and when not to use the tool, including a list of priority triggers (e.g., 'analyse le workitem', '#1234') and exclusions ('NEVER for: labels, X++ code lookup, AOT objects -- use search_labels / search_d365_code instead'). This clearly differentiates from sibling tools.

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

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

No annotations are provided, so the description fully discloses behavior. It details automatic naming conventions, parent-child relationships, Git branch creation, assignee/CC embedding, language rules for description, and required environment variables. This is comprehensive for a creation tool.

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

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

The description is well-structured with clear sections (WHEN, Rules A/B/C, LANGUAGE RULE) but is quite verbose. It could be more concise while retaining essential details. It is front-loaded with trigger phrases.

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

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

Given the tool's complexity (10 parameters, no output schema), the description covers creation logic, three parent scenarios, branching, language rule, and requirements. It does not explain return values, but for a creation tool, the side effects (task and branch creation) are implied. Overall, it is fairly complete.

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

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

Schema coverage is 100%, so the schema already describes each parameter. The description adds minimal extra semantics beyond listing which parameters are optional and some usage hints (e.g., assignTo is an email). It does not elaborate on specific parameter values or formats beyond what the schema provides.

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

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

The description clearly states the tool creates a D365 F&O development Task work item in Azure DevOps. It lists trigger phrases and details three specific naming/branching scenarios, distinguishing it from sibling tools like ado_query_workitems or ado_analyze_workitem.

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

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

The description explicitly tells when to use the tool: 'WHEN: user asks to create a DevOps Task or start development on a Work Item.' It provides trigger examples and outlines prerequisites (DEVOPS_ORG_URL, DEVOPS_PAT). However, it does not directly contrast with alternatives or state 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.

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

Annotations already indicate `readOnlyHint: true`. The description adds value by detailing the tool's behavioral traits: it uses KB signals and ADO history, produces a structured hour estimate broken down by phase, and provides confidence level and risk factors. 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.

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

The description is well-structured with clear sections (WHEN, EFFORT ESTIMATOR, Returns) and front-loaded trigger information. It is slightly verbose but every part adds value, earning a 4.

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

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

The tool has 3 parameters and no output schema. The description compensates by explaining the return values in detail (per-phase breakdown, signals, confidence, ready-to-paste estimate), making it sufficiently complete for an agent to understand inputs and outputs.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add much semantic information beyond the schema; it mentions `workItemId` implicitly in triggers but does not elaborate on optional parameters like `project` or `focusObjects` beyond what the schema already provides.

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

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

The description clearly states the tool's purpose: 'Estimate D365 F&O development effort for a Work Item.' It specifies a specific verb (estimate) and resource (Work Item), and distinguishes itself from siblings by indicating it should be called after `ado_analyze_workitem`.

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

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

The description explicitly provides WHEN triggers (e.g., 'estimate WI #N') and a priority trigger to call after `ado_analyze_workitem`. While it gives clear context for when to use, it does not explicitly state when not to use, so a 4 is appropriate.

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

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

Annotations provide readOnlyHint=true, and the description explains the tool analyzes requirements without modification. It describes what the tool returns (domain, objects, extensions, effort, reasoning) and that it may fetch from ADO if workItemId is given. No contradictions with annotations. It does not disclose potential error conditions 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.

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

The description is well-structured with a 'WHEN' section, classification list, output details, triggers, and a note. While slightly long, every sentence adds value. It could be more compact but is not wasteful.

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

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

With no output schema, the description includes return fields (domain, objects, extensions, effort, reasoning) and explains the four verdicts. It also notes the optional project parameter falls back to an environment variable. However, it does not specify behavior when multiple conflicting inputs are provided (e.g., both workItemId and requirementText).

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

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

Schema coverage is 100% and the description adds significant context: it explains the use cases for each parameter (e.g., requirements overrides other inputs, requirementText when no WI ID), and the trigger section clarifies parameter selection. This goes beyond the schema's basic descriptions.

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

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

The description clearly states the tool classifies D365 F&O requirements into four verdicts (Standard, Config, Extension, Gap). It lists specific output elements (domain, objects, extensions, effort, reasoning). This distinguishes it from sibling tools like ado_analyze_workitem or detect_performance_issues which have different purposes.

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

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

The description provides explicit trigger phrases and a note that when a work item has already been analyzed by ado_analyze_workitem in the same turn, the user should pass requirementText directly. It also explains the relationship between parameters (workItemId, requirementText, requirements). However, it does not explicitly compare to sibling tools or state when NOT to use this tool.

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

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

Annotations already indicate readOnlyHint=true. The description adds authentication requirements (DEVOPS_ORG_URL + DEVOPS_PAT with Code: Read scope) and system behavior (listing all repos if repositoryId omitted). No contradictions.

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

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

The description is front-loaded with a lengthy priority trigger list in brackets, which is helpful but verbose. The main description packs purpose, usage, filters, return info, related tool, and auth. Tightening the trigger list would improve conciseness.

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

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

Despite no output schema, the description details what is returned (PR ID, title, author, branches, review status, work items, creation date). It covers authentication, usage guidelines, fallback behavior, and a related tool. Complete for a list PRs tool.

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

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

Schema coverage is 100% (baseline 3). The description adds context beyond schema: the behavior when repositoryId is unknown, and summarizes filters (status, author, target branch) which aligns with param descriptions. This adds value.

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

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

The description clearly states the tool lists pull requests in Azure DevOps. It provides trigger phrases for when to use, distinguishes from search_d365_code, and mentions the related ado_analyze_pr_impact for deeper analysis. The verb 'list' and resource 'Pull Requests' are specific.

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

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

The description explicitly says when to use ('PRIORITY TRIGGER' with user phrases) and when not to ('NEVER call search_d365_code'). It gives guidance on handling unknown repositoryId and suggests following up with ado_analyze_pr_impact for impact analysis.

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

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

No annotations exist, so description carries full burden. It discloses write permission requirements, the need for user confirmation, and that it posts a comment. Minor omission: no mention of failure modes or idempotency, but adequate for a write tool.

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

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

Structured with clear headers (WHEN, PRIORITY TRIGGER, WARNING, workflow), front-loading key use conditions. While slightly verbose, every sentence adds value. Could be tightened but effective.

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

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

For a 3-parameter tool with no output schema, the description covers purpose, workflow, permission requirements, and parameter hints. No return value information, but the tool's effect (posting comment) is clear, and side effects (write) are implied.

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

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

Schema coverage is 100%, but description adds context: explains `commentText` should come from `ado_analyze_workitem`, and `project` defaults from environment. This clarifies parameter usage beyond the schema.

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

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

The description explicitly states 'post, add, or save a comment to an ADO Work Item', using a specific verb and resource. It distinguishes from siblings like `ado_post_pr_comment` by targeting work items rather than PRs.

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

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

Provides explicit guidance: WHEN to use, PRIORITY TRIGGER, WARNING requiring explicit confirmation, and a recommended workflow (step-by-step). It also clarifies alternatives by naming `ado_analyze_workitem` as a prerequisite.

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

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

The description discloses that it is a write operation requiring confirmation and dependencies. With no annotations provided, it carries the full burden and adequately covers the essential behavioral aspects, though lacks detail on error handling or idempotency.

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

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

The description is well-structured with clear sections (WHEN, PRIORITY TRIGGER, WARNING, workflow). It is slightly verbose but front-loaded with the key purpose. Each sentence adds value.

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

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

Given no output schema and moderate complexity, the description covers when to call, what parameters need, prerequisites, and the confirmation step. It could mention the expected output (e.g., success indication), but is otherwise complete enough for an AI agent.

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

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

Despite 100% schema coverage, the description adds valuable context: commentText should come from ado_analyze_pr_impact, and explains inline vs top-level comment behavior via filePath/lineNumber. This enhances understanding beyond the schema.

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

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

The description clearly states the tool posts a review comment to an ADO Pull Request, using specific verbs and distinguishing from sibling tools like ado_post_comment. It also positions it in a workflow with ado_analyze_pr_impact.

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

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

Explicitly defines when to use (user asks to post/add/save), provides a recommended workflow with steps, warns to ask for confirmation, and mentions required environment variables. Clearly differentiates from other tools.

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

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

The description fully discloses the tool's read-only behavior, aligning with the readOnlyHint annotation. It details what the tool does (scan, detect conflicts, compute merge order) and what it outputs, leaving no ambiguity about safety or side effects.

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

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

The description is well-structured with bullet points for outputs and triggers. Every sentence provides useful information without fluff. Length is appropriate for the tool's complexity.

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

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

Despite the absence of an output schema, the description thoroughly explains the expected outputs (per-PR object table, conflict matrix, dependency graph, merge order) and triggers. It also mentions required credentials, covering all necessary context for an agent to use the tool effectively.

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

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

All parameters are already described in the schema (100% coverage). The description adds some contextual flavor (e.g., 'filter by target branch, e.g. develop') but does not significantly extend the schema's meaning. A baseline of 3 is raised to 4 because the description groups parameters logically within the tool's purpose.

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

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

The description clearly states the tool scans multiple PRs to build a cross-PR dependency graph based on shared objects and branch chains. It lists specific actions and outputs, distinguishing it from siblings like ado_list_prs (which simply lists PRs) and ado_analyze_pr_impact (which likely analyzes individual PR impact).

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

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

The description provides explicit trigger phrases ('PR dependencies', 'merge order PRs') and mentions required environment variables (DEVOPS_ORG_URL, DEVOPS_PAT). However, it does not explicitly state when not to use this tool or compare it to alternatives, though the triggers serve as implicit guidance.

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

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

Discloses important behaviors: returns max 50 items, includes specific fields, requires env vars, supports shortcuts and WIQL. No contradiction with annotations (readOnlyHint=true).

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

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

Description is dense but well-organized, starting with purpose and then triggering conditions. Could be improved with bullet points, but every sentence is useful and no fluff.

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

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

Covers all essential aspects: purpose, triggers, exclusions, parameter usage, environment requirements, return fields, and result limit. Adequate for a complex tool with no output schema.

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

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

Schema coverage is 100%, so description adds value by explaining query parameter usage with shortcuts and free-text search beyond schema. For other parameters, schema descriptions suffice. Overall good but not exceptional.

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

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

Description clearly states 'Query Work Items in Azure DevOps' and lists specific work item types. It explicitly distinguishes from sibling tools by stating when NOT to use and providing alternatives like search_labels or search_d365_code.

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

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

Provides a comprehensive list of trigger phrases (e.g., 'FDD', 'bug', 'sprint') and explicitly states exclusions with alternative tool recommendations. Also explains shortcuts and query usage patterns.

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

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

The description details what the tool detects (removed objects, changed method signatures, deprecated APIs, extensibility blocks, renamed fields, internal methods) and states it returns a prioritized risk report with fix recommendations. Annotations indicate readOnlyHint=true, which is consistent with a read-only analysis; no contradiction.

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

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

The description is well-structured, starting with the usage trigger, then explaining the analysis scope, and listing detection items. It is informative but could be slightly more concise; however, every sentence adds value.

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

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

Given the empty input schema and no output schema, the description fully explains the required input (path) and the output (prioritized risk report with recommendations). It covers all aspects needed for an upgrade impact analysis tool.

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

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

The input schema is empty (0 parameters), so the description compensates by stating the required environment variable 'Requires D365_CUSTOM_MODEL_PATH'. This adds necessary context beyond the schema, meeting the baseline expectation for 0-parameter tools.

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

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

The description clearly states the tool analyzes upgrade risk for custom D365 F&O models, cross-referencing custom code against the standard indexed codebase. It differentiates from siblings like ado_analyze_pr_impact (focused on PRs) by specifying its context of version upgrades and Microsoft updates.

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

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

The description explicitly starts with 'WHEN: upgrading D365 F&O to a new version or applying a Microsoft update' and provides trigger phrases. It also mentions the prerequisite 'Requires D365_CUSTOM_MODEL_PATH'. However, it does not explicitly mention alternatives among the sibling tools for other scenarios.

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

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

Discloses that all queries run in parallel, results are equivalent to search_d365_code, and returned together. Importantly, states that matching objects are FULLY loaded (all chunks) so no follow-up with get_object_details is needed. Consistent with readOnlyHint annotation.

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

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

Well-structured with a clear 'WHEN:' lead, behavioral explanation, and trigger phrases. Slightly lengthy due to trigger list, but every sentence adds value. Front-loaded with key information.

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

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

Given read-only annotation and no output schema, the description is complete: explains return behavior (equivalent to search_d365_code but batched, fully loaded objects), warns against redundant follow-up, and covers all 3 parameters. Sufficient for an agent to use correctly.

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

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

Schema coverage is 100% with good parameter descriptions. The description adds little beyond the schema for parameters, only reinforcing that queries are newline-separated (already in schema). Additional behavioral context (parallelism, full loading) does not directly enhance parameter semantics.

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

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

The description clearly states the tool performs parallel searches for multiple D365 objects or concepts simultaneously, distinguishing it from the sibling search_d365_code. It uses a specific verb 'batch search' and specifies the resource and action.

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

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

Explicitly states when to use ('need context on multiple objects') and when not ('INSTEAD of multiple sequential search_d365_code calls'). Provides maximum query limit (6) and trigger phrases, offering clear guidance.

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

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

Annotations provide readOnlyHint=true. Description adds valuable context: auto-fixing only on custom code, standard objects are read-only. No contradiction beyond the annotation; the description clarifies scope.

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

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

Concise yet comprehensive; starts with WHEN, lists triggers, detections, and exclusions. No redundant sentences.

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

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

Explains detection scope and behavior (read-only for standard, auto-fix for custom). No output schema, but description covers output sufficiently. Could be slightly more specific on output format.

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

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

Schema covers both parameters fully (100% coverage). Description adds no extra parameter-specific information beyond what the schema already provides.

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

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

The description clearly states the tool detects performance issues like N+1 queries, queries in loops, etc., on D365 F&O objects. It distinguishes from sibling tool 'validate_best_practices' by specifying boundaries.

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

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

Explicitly lists when to use (slow query, performance review, N+1 check) and when not to use (general code quality audit, referencing sibling tool). Also provides trigger phrases.

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

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

Annotations already indicate readOnlyHint=true. The description adds behavioral context: output is in plain business language without jargon, and the tool explains approval workflows specifically. This goes beyond the annotations by detailing output style and domain scope.

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

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

The description is well-structured with 'WHEN', core explanation, and 'Triggers' sections. Every sentence contributes value, no redundancy. It is concise yet comprehensive, front-loading usage conditions.

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

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

For a simple tool with one parameter and no output schema, the description fully covers purpose, usage guidelines, output style, and triggers. It is self-contained and leaves no ambiguity about what the tool does or when to use it.

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

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

Schema coverage is 100% with a clear description of the 'objectName' parameter. The description reaffirms the parameter's purpose through examples but does not add new semantic details beyond the schema, meeting the baseline expectation.

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

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

The description clearly states the tool explains D365 approval workflows in business language, specifying who approves, states, and outcomes. It distinguishes from sibling 'get_object_details' by explicitly stating it is not for technical workflow class details.

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

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

The description provides explicit 'WHEN' conditions (user asks about approval workflow, who approves, states, etc.) and 'NOT' conditions with a direct alternative ('use `get_object_details`'). Triggers list example queries, making usage criteria precise.

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

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

Annotations include readOnlyHint: true, which is consistent with the read-only nature described. The description adds valuable behavioral context by specifying the required pregenerated cache file and the tool's dependency on it, going beyond what annotations provide.

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

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

The description is well-structured with the main purpose first, then detailed reference kinds, prerequisites, and trigger phrases. It is somewhat lengthy but each sentence adds value. A minor improvement could be tightening the list of reference kinds.

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

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

The description is comprehensive for a read-only tool, explaining what references are covered and the prerequisite. However, the lack of output schema or description of the return format leaves a gap for the agent to fully understand the response structure.

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

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 does not add significant new meaning beyond the schema's parameter descriptions, though it reinforces the format of methodKey.

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

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

The description clearly states the tool finds callers of a D365 F&O method/class and gets the full cross-reference profile from compiled XRef DB. It lists all reference kinds explicitly, distinguishing it from sibling tools like find_references or find_extensions.

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

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

The description provides a clear prerequisite (requires xref_index.json.gz) and includes trigger phrases in multiple languages. It implies comprehensive coverage of reference kinds, guiding when to use, but lacks explicit when-not or comparisons to siblings.

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

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

The description states it generates a new entity template when generateIfMissing=true, which is a write operation, but the annotation declares readOnlyHint=true. This is a direct contradiction. The description does not disclose the write behavior clearly, leaving the agent misinformed about whether modifications occur. No other behavioral traits beyond the contradictory generation are mentioned.

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

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

The description is well-structured starting with a clear 'WHEN' section, followed by trigger phrases, then a detailed explanation. While it is longer than minimal, every part adds value. It is front-loaded with the most important usage context. Could be slightly more concise, but overall effective.

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

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

Given the complexity of the tool and absence of an output schema, the description thoroughly covers purpose, usage scenarios, parameter behavior, return values (entity name, public name, IsPublic, key fields, data sources), and the optional generation feature. No critical information is missing for an AI agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, providing baseline 3. The description adds extra value: for tableName it gives examples like 'SalesTable'; for maxResults it mentions default (15) and max (30); for generateIfMissing it explains the condition for template generation. This additional context helps the agent understand parameter usage beyond the schema definitions.

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

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

The description explicitly states the tool finds data entities that expose a given table for OData/DMF integrations, using specific verbs like 'find', 'generate', and 'scan'. It gives concrete examples such as 'Which entity exposes SalesTable for OData?' and mentions scanning AxDataEntityView objects. This clearly distinguishes it from sibling tools, which focus on ADO, code analysis, or other D365 tasks.

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

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

The description begins with 'WHEN: developer needs to integrate via OData and wants to find the entity name for a given table,' providing clear usage context. It also explains when to set generateIfMissing=true and lists trigger phrases. Although it does not explicitly state when not to use it or compare to alternatives, the sibling tools are different enough that no direct competition exists, making this guidance sufficient.

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

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

Annotations already indicate readOnlyHint=true. The description adds detailed behavior: matches against a built-in database, resolves label IDs, returns root causes, step-by-step resolution, label matches, and source code locations. No contradictions.

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

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

Well-structured with front-loaded WHEN section and clear bullet points, but slightly long. Could be tightened without losing information.

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

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

Despite no output schema, the description clearly explains the return values (root causes, resolution, label matches, source code locations). Also covers interaction with search_labels for label IDs.

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

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

Schema provides 100% coverage with descriptions for both parameters. Description enriches by explaining audienceType behavior difference and providing examples for errorOrSymptom.

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

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

Description clearly states the tool finds known D365 F&O error patterns matching error messages or symptom descriptions. It differentiates from sibling tools like search_labels (which resolves label IDs) and search_d365_code (which searches code).

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

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

Explicitly provides WHEN conditions and triggers for both developer and business scenarios. Includes specific guidance to call search_labels first if the error text contains a label ID, and explains audienceType usage.

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

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

Annotations declare readOnlyHint=true, so the tool is read-only. The description adds behavioral details beyond the annotation: it queries Azure DevOps Code Search API in real-time (parallel, no index download) and finds multiple extension object types. This enriches transparency without contradicting the annotation.

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

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

Description is well-structured with a front-loaded 'WHEN:' clause, followed by what it finds and the special API behavior. It is slightly wordy but every sentence adds value. Could be trimmed slightly but remains clear and efficient.

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

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

Given the tool's complexity (multiple object types, real-time API query), the description covers purpose, triggers, scope, and sibling distinction. It does not explain return format (no output schema) but that is acceptable for a find operation. No prerequisites or constraints are missing.

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

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

The sole parameter baseObjectName has schema coverage 100% with a description and example. The tool description adds usage context (examples like 'SalesTable') but no additional semantic details beyond what the schema provides. With high coverage, baseline 3 is appropriate.

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

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

Description clearly states the tool's purpose: finding extension objects, Chain of Command classes, and event handlers for a base object. It specifies triggers ('WHEN: before modifying an object') and explicitly distinguishes from sibling 'find_references' using 'NOT for general references'. This gives the agent a precise verb+resource+scope.

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

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

The description provides explicit when-to-use guidance ('before modifying an object -- check existing customizations') and lists triggers like 'extensions de', 'CoC sur' to indicate context. It also states what the tool does not do ('NOT for general references') and directs to the alternative 'find_references'. This is comprehensive usage guidance.

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

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

Discloses that it's a full index scan (O(1M+ chunks)) and thus expensive, provides label ID search behavior (both forms automatically), and notes it is not for extensions only. This adds value beyond the readOnlyHint annotation and no contradiction.

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

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

The description is well-structured with clear sections (WHEN, triggers, performance warning, workflow for labels). It is front-loaded and every sentence provides useful information, though somewhat lengthy.

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

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

Covers usage, performance, alternatives, label handling, and exclusions. No output schema is provided, but the description implies the return (list of referencing objects). Adequately complete for a tool with 3 parameters.

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

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

Schema coverage is 100%, baseline is 3. Description adds context for the name parameter regarding label ID auto-search and provides default/max values for maxResults and locationsPerObject, enhancing understanding.

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

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

The description explicitly states the tool's purpose: impact analysis and finding references to objects or methods. It includes trigger phrases like 'all usages of' and distinguishes from siblings such as find_callers and get_object_details.

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

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

Provides explicit WHEN and WHEN-NOT usage criteria, listing triggers for calling and alternatives. It advises against using this tool for identification or description tasks and recommends find_callers when the XRef index is loaded.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by noting delegation to get_relation_graph when the index is loaded and that results are identical. No contradictions, but could elaborate on potential side effects or performance.

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

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

Description is dense but well-organized with sections like 'WHEN:', triggers, return info, and a note. The trigger list is somewhat long but useful for pattern matching. Could trim slightly, but overall efficient.

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

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

For a simple input schema with no output schema, the description covers return types, usage context, and relationship to siblings. It also includes a note about delegation, making it fully informative for an AI agent.

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

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

Schema coverage is 100% with a clear description for objectName. The description adds examples ('e.g. 'SalesTable', 'VendInvoiceJour''), which aids understanding beyond the schema.

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

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

The description clearly states the tool retrieves all relations, schema, or foreign keys of a D365 object, listing trigger phrases and distinguishing return types (outgoing and incoming). It differentiates from the sibling tool get_relation_graph by noting identical results.

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

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

Explicitly states when to use ('ALWAYS call this BEFORE generating any code that touches multiple objects') and when not to ('do NOT call both find_related_objects AND get_relation_graph'). Includes trigger examples for common queries.

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

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

Description confirms read-only behavior (generating diagrams from knowledge base), aligns with annotations. Adds context about rendering environments, disabled flow diagrams with rationale. Exceeds annotation coverage.

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

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

Description is front-loaded with WHEN and triggers, structured logically. Could be slightly trimmed but all content is relevant and earns its place. Minor redundancy in triggers list.

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

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

For a tool with 4 parameters, full schema coverage, and no output schema, the description covers all necessary aspects: purpose, usage, parameter details, disabled features, and rendering context. Complete for the complexity level.

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

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

Schema coverage is 100%, and description adds meaningful context: explains diagramType options (er/security), objectName purpose, maxRelated default/max, and methodName as unused. No parameter is left vague.

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

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

The description clearly states the tool generates visual diagrams of D365 table relationships or security chains, and lists specific triggers and diagram types. It distinguishes from sibling tool trace_security_chain by noting when to use each.

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

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

Explicit WHEN section lists triggers and use cases. Provides clear alternative guidance for trace_security_chain when a text chain is needed. Warns that flow diagrams are disabled, preventing incorrect usage.

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

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

Annotations declare readOnlyHint=true, and description does not contradict; adds behavioral context by listing sections generated and trigger phrases. Though no mention of authorization or rate limits, the read-only nature is clear.

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

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

Well-structured: usage condition first, then title and sections, then triggers. Concisely covers key points, though trigger list could be more condensed. No waste.

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

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

Given readOnlyHint and high schema coverage, description is adequate. It specifies the sections generated but does not mention output format (e.g., markdown). No output schema exists, so description should clarify return value; slight gap.

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

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

Schema description coverage is 100%, so baseline is 3. Description adds minimal semantic depth beyond schema; it mentions sections but does not elaborate on parameter usage or provide examples. Acceptable but not enhanced.

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

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

Clearly states it generates a Functional Design Document (FDD) with specific sections. Distinguishes from sibling tools by explicitly stating it is not for developer technical docs and recommends get_object_details instead.

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

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

Provides explicit WHEN conditions (user asks for FDD/functional spec/cahier des charges) and WHEN NOT (developer docs, use get_object_details). Also lists trigger phrases, giving clear guidance on when to invoke.

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

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

The description adds significant behavioral context beyond the readOnlyHint annotation: it explains the tool uses real field names, relations, and indexes, auto-detects joins, generates side-by-side X++ and SQL with explanations, and warns that generated X++ is a template. It also mentions necessary preconditions for multi-table joins. 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.

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

The description is well-structured and front-loaded with the WHEN to use. It contains multiple sections (triggers, capabilities, dependencies, warnings) that are logically ordered. While it is somewhat lengthy, every sentence adds useful information, and it avoids redundancy.

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

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

Given the complexity (8 parameters, no output schema), the description covers what the tool returns (side-by-side X++ and SQL with explanations) and what scenarios it supports (field selection, joins, filters, etc.). It also addresses prerequisites and limitations. It is comprehensive enough for an AI agent to invoke correctly.

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

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

Schema coverage is 100% with each parameter having a description. The description adds value by explaining how parameters interact (e.g., 'description' auto-detects fields/joins/filters, 'top' distinguishes firstonly vs top N) and by noting that natural language inputs are accepted. This goes beyond what the schema alone provides.

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

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

The description clearly states the tool's purpose: generating X++ select and T-SQL queries for D365 tables with proper joins. It provides specific trigger phrases, examples, and exactly what it supports (field selection, joins, filters, etc.), making it easy to distinguish from sibling tools which focus on other D365 development tasks.

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

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

The description explicitly tells WHEN to use the tool ('WHEN: developer needs correct X++ select or T-SQL...') and provides a list of trigger phrases. It also gives a prerequisite guidance: for multi-table joins, call `find_related_objects` first. While it does not explicitly say when NOT to use it, the context is clear enough.

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

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

The description clearly shows the tool generates code (read-only, consistent with readOnlyHint annotation) and adds behavioral details: it requires test scenarios, uses real field names from knowledge base, and notes that generic templates rarely compile. 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.

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

The description is front-loaded with trigger conditions and is structurally clear, in about 7 sentences. It covers when, what, constraints, and parameter guidance without significant redundancy, though a few sentences could be tightened.

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

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

The description adequately explains the input requirements and generated output type, but lacks details about output format (plain code? file path?) and error handling. Given no output schema, this gap moderately affects completeness for an agent deciding to invoke the tool.

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

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

With 100% schema coverage, baseline is 3. The description adds extra meaning by explaining how testScenarios are used (each scenario becomes a concrete test method) and the default behavior for methodName. This goes beyond the schema descriptions.

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

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

The description states a specific verb ('Generate') and resource ('X++ SysTest unit test code') for a well-defined scope ('CUSTOM D365 F&O object'), clearly distinguishing it from sibling tools that focus on analysis, queries, or other generation tasks like forms or queries.

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

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

The description begins with explicit trigger words ('WHEN: developer needs to write or scaffold unit tests...') and provides context about when it is meaningful (only custom/extension code). However, it does not explicitly state when NOT to use it or mention alternative approaches for non-custom code.

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

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

Annotations declare readOnlyHint: true, which is consistent with a tool that generates XML output without side effects. The description adds that the output is 'complete, compilable' and mentions correct control serialization, but does not disclose additional behavioral traits like permissions or rate limits beyond what annotations already indicate.

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

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

The description is somewhat long but highly informative and well-structured. It front-loads the purpose and trigger phrases, then explains the output and patterns. Every sentence adds value, though it could be slightly more concise by reducing the trigger phrase examples.

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

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

Given the tool's complexity (6 parameters, 2 required), the description covers all relevant aspects: patterns, input formats (PascalCase, comma-separated), and output description. There is no output schema, but the explanation of the XML return is sufficient. It does not address error handling or permissions, but for a generation tool this is acceptable.

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

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

Schema coverage is 100% with all parameters having descriptions. The description adds value by explaining the relationship between formPattern and primaryTable/secondaryTable, giving example values (e.g., 'ALMCustomerForm'), and noting conditional usage (e.g., secondaryTable for DetailsTransaction). This goes beyond the schema descriptions.

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

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

Description clearly states the tool generates a D365 F&O form or form extension. It lists specific trigger phrases and explains the output (complete compilable AxForm AOT XML with correct control serialization), distinguishing it from sibling tools which are for queries, analysis, or other code generation.

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

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

The description starts with 'WHEN: creating a new D365 F&O form or form extension' and lists trigger phrases, providing clear context for when to use. It does not explicitly mention when not to use or reference alternatives, but among siblings there are no similar form generators, so the guidance is clear enough.

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

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

The description explains it uses real metadata from the KB, generating code without side effects, consistent with readOnlyHint. It adds behavioral details beyond annotations, such as template types and the need for object existence verification.

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

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

The description is packed with useful information but is somewhat dense due to listing triggers and template types inline. It could be more structured (e.g., bullet points) while still being concise enough.

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

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 clearly indicates the output is ready-to-use X++ code. It covers preconditions (call get_object_details), usage context, and provides sufficient detail for an agent to use the tool correctly.

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

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

The description enriches the schema by explaining template types ('coc' = Chain of Command, etc.) and the optional methodName parameter. Schema description coverage is 100%, and the description adds context that goes beyond the raw schema.

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

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

The description clearly states the tool generates ready-to-use X++ code for extensions and customizations, with specific template types listed. It distinguishes itself from sibling tools like generate_diagram or generate_query by focusing on X++ code templates and providing trigger examples.

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

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

The description starts with 'WHEN: writing an extension or customization' and advises calling get_object_details first. While it does not explicitly state when not to use or compare to alternatives, the context is clear enough for an agent.

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

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

Annotations indicate readOnlyHint=true and the description confirms this. It discloses behavioral traits such as merging live disk source, the effect of methodName on return content, and the two-step pattern, adding 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.

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

The description is comprehensive but slightly verbose, with some redundant emphasis (e.g., 'CORRECT and INTENDED'). However, it is well-structured and front-loaded with key information, making it efficient overall.

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

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

Given the tool's simplicity (2 params, no output schema), the description covers all relevant aspects: what is returned, the two-step pattern, and warnings against unnecessary calls. It is complete for the intended use.

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

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

Schema coverage is 100%. The description adds meaning by explaining that methodName returns full body vs signatures, provides examples, and describes the intended two-step pattern, enhancing the schema definition.

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

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

The description clearly states the tool gets complete details of a D365 object when the exact name is known, specifying what is returned (fields, methods, etc.) and distinguishing it from siblings like search_d365_code and list_objects.

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

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

Explicitly states when to use (exact name known) and when not (searching, listing), and describes the intended two-step pattern for method details, providing clear triggers and exclusions.

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

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

Annotations already indicate readOnlyHint=true. The description supplements this by detailing the return JSON fields (status, indexed chunk count, loaded version, custom model path), providing behavioral context 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.

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

The description is extremely concise, front-loading the use case with 'WHEN:', listing trigger phrases, and specifying the return structure. Every sentence adds value.

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

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

Given zero parameters and no output schema, the description fully covers what the tool does and what it returns. No gaps remain for a simple health check tool.

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

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

The schema has no parameters with 100% coverage, so the baseline is 3. The description does not add parameter-specific info but does describe the output, which is beyond the schema.

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

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

The description clearly states the tool checks server status, loaded D365 version, or custom model path. It uses a specific verb and resource, and distinguishes from sibling tools which focus on code analysis and work items.

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

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

The description explicitly lists trigger phrases like 'status', 'statut', 'is the server ready', etc., and the context of checking server status. It does not explicitly exclude scenarios but provides clear context for when to use.

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

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

Annotations already declare readOnlyHint=true, so the description adds the valuable detail that the tool 'reads the file system directly -- always reflects the latest uncommitted state', which informs the agent about freshness and potential side effects (none). This goes beyond the annotation.

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

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

The description is concise: two sentences plus a list of triggers, all front-loaded. Every sentence adds value, with no redundancy or fluff.

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

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

For a simple tool with one optional parameter and no output schema, the description covers purpose, triggers, parameter configuration, behavioral trait (file system read), and state (uncommitted). No gaps remain.

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

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

The input schema already describes the parameter with 100% coverage, so baseline is 3. The description adds context about the header fallback and overriding behavior, which provides additional semantic clarity beyond the schema.

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

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

The description clearly uses the verb 'list' with a specific resource ('custom/extension objects in their model') and distinguishes itself from the sibling tool 'list_objects' by specifying the scope (custom/extension model directory). Trigger phrases further reinforce the purpose.

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

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

The description starts with 'WHEN' and lists explicit trigger phrases, providing clear usage context. It also explains how to configure the `customModelPath` via parameter or header, guiding the agent on when to use each method.

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

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

Annotations already declare readOnlyHint=true; description adds valuable behavioral traits: 'Full index scan', 'returns EVERY matching object', and default model listing behavior. No contradictions.

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

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

Concise with clear structure: usage condition, examples, exclusions. Minor verbosity in trigger examples but essential for agent comprehension.

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

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

Given no output schema, description fully covers behavior, performance implication (full index scan), default behavior, and exclusions. Complete for a list tool with two parameters.

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

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

Schema coverage is 100% with detailed parameter descriptions. Description adds context about default behavior and scan scope, enhancing agent understanding beyond schema.

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

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

Clearly states the tool lists ALL objects of a given type or model, with specific verb 'list' and resource 'objects'. Differentiates from siblings get_object_details (single object) and search_d365_code (natural language search).

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

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

Explicitly provides WHEN to use (need all objects of type/model), example triggers, and WHEN NOT to use with specific alternative tools named. Offers clear context for decision-making.

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

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

Annotations already indicate readOnlyHint=true; description adds that it produces a Mermaid diagram and lists elements included (forms, tables, classes, etc.), but lacks details on performance or limits.

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

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

Well-structured with usage conditions front-loaded, but slightly lengthy. Each sentence adds value; no redundancy.

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

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

Covers multiple use cases (known process, unknown object, 'list'), describes output (Mermaid diagram), and lists involved object types. No output schema, but description compensates well.

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

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

Single parameter processName has 100% schema description. Description adds concrete examples and distinguishes behavior for known vs unknown processes, adding significant value beyond schema.

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

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

Clearly states the tool maps D365 F&O business processes to object chains. Explicitly distinguishes from sibling tool 'find_related_objects' by specifying it is not for single object FK relations.

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

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

Provides explicit when-to-use triggers (e.g., 'Order-to-Cash', 'map the process') and when-not-to-use with a specific alternative (find_related_objects). Also mentions using 'list' to discover known processes.

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

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

Beyond the readOnlyHint annotation, the description details that top-scoring results return all chunks (metadata, Declaration, methods) while lower-scoring results return a preview, eliminating the need for follow-up calls. It also notes that batch_search is faster for multiple concepts. This adds significant behavioral context.

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

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

The description is structured with clear headings (WHEN, NOT for, NEVER) and front-loads the purpose. It is somewhat lengthy but each section adds value. Minor redundancy (e.g., repeated admonitions) prevents a perfect score.

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

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

Given 4 parameters, no output schema, and 37 sibling tools, the description fully covers when and how to use the tool, including return behavior, limitations, and integration with alternatives. It leaves no critical gaps for an AI agent.

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

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

Schema coverage is 100% with each parameter already well-described. The description adds examples for query and explains domain filtering, but does not substantially extend the schema's semantic meaning. Baseline 3 is appropriate given the schema already covers parameters thoroughly.

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

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

The description clearly states that the tool searches the D365 F&O knowledge base for code objects using natural language or partial names, and explicitly distinguishes it from sibling tools like list_objects and get_object_details. It specifies the return behavior (all chunks for top results, preview for lower), leaving no ambiguity about purpose.

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

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

The description provides explicit when-to-use (unknown/partial names, concept searching) and when-not-to-use (exact name known, listing all objects, work item queries). It lists trigger words, warns against calling twice in same turn, and directs work item queries to specific alternatives. This is comprehensive guidance.

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

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

Adds significant behavioral context beyond the readOnlyHint annotation: describes normalization of colon/short forms, large-scale search over 1M+ entries, and on-demand language loading with ~15s latency on first call for non-default languages.

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

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

Structured effectively with core purpose, examples, workflow, and language details. All sentences add value, though slightly wordy in places. Could tighten slightly without losing information.

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

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

Covers input variants, workflow, and language behavior well. Does not describe the return format (e.g., list of matches), which is a minor gap given no output schema. Otherwise complete for a search tool.

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

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

Despite 100% schema coverage, the description adds concrete examples ('Sales order', '@SYS12345', '@SYS:12345') and clarifies that both forms are normalized. It also explains language loading behavior relevant to the 'language' parameter.

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

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

The description clearly states the tool searches D365 F&O labels across languages, resolving between label text and label IDs. It distinguishes from siblings like 'find_references' by specifying the workflow sequence.

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

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

Provides explicit workflow instruction: call this first to resolve label text/ID, then use 'find_references' for usage detection. Also explains language loading behavior, helping agents decide when to call.

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

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

Annotations indicate readOnlyHint=true, and the description adds value by explaining the tool returns ranked candidates with base type, label, and model. It also mentions D365 best practice, providing useful behavioral 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.

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

Well-structured with a 'WHEN:' section and trigger list. While slightly verbose, it front-loads the key purpose and is efficient overall.

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

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

Given no output schema, the description sufficiently explains return values. All parameters are covered, and the usage context (before field declaration) is clear, making the tool complete for its intended use.

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

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

Schema coverage is 100%, but the description adds useful examples for 'purpose' (e.g., 'customer account number') and restates key parameters with context. This adds meaning beyond the schema descriptions.

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

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

The description clearly states the tool's purpose: to find the best existing D365 EDT to extend when adding a new field to a table, avoiding raw primitives. It specifies the verb 'find' and the resource 'EDT candidates', and distinguishes it from sibling tools like search_d365_code or find_entity_for_table.

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

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

Explicitly instructs to call 'BEFORE declaring any field with a primitive type' and provides trigger phrases. While it doesn't list when not to use, the context is clear and no direct alternative tool exists among siblings.

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

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

Annotations indicate readOnlyHint=true, and the description aligns by emphasizing analysis and suggestions (no mutations). It discloses scope (custom code only) and lists specific refactoring patterns, adding value beyond the annotation.

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

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

The description is information-dense but well-structured, starting with 'WHEN' for quick orientation. Every sentence adds value, though it could be slightly more concise without loss.

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

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

With no output schema, the description covers return value ('Returns before/after code examples'). It explains when to use, what it analyzes, and constraints. Lacks details on error handling or performance, but sufficient for a read-only tool.

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

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

Schema description coverage is 100% (both parameters have descriptions). The tool description adds minimal extra context: it contextualizes objectName as custom code and methodName as optional. This justifies the baseline score of 3.

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

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

The description clearly states the tool's purpose: suggesting refactoring actions for custom D365 F&O X++ code before PR merge or review. It lists triggers, analysis types, and output, distinguishing it from sibling tools focused on analysis, queries, or generation.

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

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

Explicit 'WHEN' condition, concrete triggers, and a clear exclusion for standard Microsoft code. Provides actionable guidance for when to use and when not to, with no direct sibling overlap.

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

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

Describes licence classification with confidence levels, grant-level awareness, optimization section, and cost estimates. Annotations already indicate readOnly, but description adds rich behavioral context without contradiction.

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

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

Despite moderate length, every sentence adds value, triggers are front-loaded, and structure is logical. Minor verbosity could be trimmed without loss.

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

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

Given no output schema, the description covers output structure, licence classification, and optimization. Lacks error handling details but is sufficient for intended use.

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

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

Schema coverage is 100%, so baseline is 3. Description adds context about roleName format and maxEntryPoints defaults/limits, but does not significantly extend semantics beyond the schema.

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

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

The description explicitly states the tool builds the complete role-to-licence tree, lists trigger phrases, and clearly distinguishes from the sibling tool 'trace_security_chain' for pure technical chains.

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

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

It provides explicit when-to-use scenarios (security design, licence audit) and when-not-to-use (pure technical chain without licence inference), with clear alternatives.

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

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

Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds detailed traversal path (Role->Duties->Privileges->Entry Points->Table/Form Permissions) and behavior when businessLanguage=true, disclosing all key behavioral traits 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.

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

The description is well-structured with labeled sections (WHEN, triggers, traversal, NOT), and key information is front-loaded. While slightly verbose (including many trigger phrases), every sentence adds useful context.

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

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

Despite no output schema, the description explains that the tool returns a technical chain or plain-language capability list, which is adequate for an AI agent. The sibling tools and context signals provide additional clarity, making it reasonably complete.

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

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

Schema coverage is 100% and both parameters have descriptions. The description adds value by providing example values for securityObjectName and clarifying the effect of businessLanguage=true, enhancing understanding beyond the schema.

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

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

The description clearly states the tool is for security audit, producing a technical chain from Role/Duty/Privilege to Entry Points and Table/Form permissions, and also offers business-language explanation. This is a specific verb+resource with clear scope, distinguishing it from siblings.

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

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

The description explicitly provides WHEN to use (security audit) and WHEN NOT to use (for licence cost inference, use trace_role_license_tree). It also lists numerous trigger phrases for both technical and business language cases, offering excellent context for selection.

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

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

Description discloses that auto-fixing is only possible on custom code, and standard objects yield read-only analysis. This adds context beyond the readOnlyHint annotation. No direct contradiction, but the annotation implies overall read-only, which description qualifies.

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

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

Description is well-structured with clear sections (WHEN, Checks, NOT for) and front-loaded with purpose. However, the list of trigger phrases is somewhat verbose and could be more concise.

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

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

Given the complexity (3 params, no output schema, many siblings), the description covers purpose, usage, behavioral nuances, and limitations. It lacks return format details but is otherwise complete for effective use.

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

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

Schema coverage is 100%, and descriptions in schema adequately document parameters. The description adds no additional meaning beyond what schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool validates best practices on D365 F&O objects, listing specific checks (security, performance, etc.) and distinguishes from sibling 'detect_performance_issues' by explicitly stating what it does not do.

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

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

The description provides explicit WHEN (code review, quality gate), triggers (e.g., 'vérifie les bonnes pratiques'), and a clear NOT for deep performance profiling with a named alternative ('use detect_performance_issues').

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