verify_d365fo_project

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

Annotations declare readOnlyHint=true and openWorldHint=false, and the description's verification semantics are consistent with those. The description adds value beyond the annotations by disclosing what is actually checked (AOT path existence on disk and .rnrproj references), plus the projectPath requirement for the reference check. No contradiction exists.

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

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

Three sentences with the core purpose front-loaded in the first sentence, followed by usage guidance and the omission behavior. The final sentence is slightly dense with the parenthetical, but overall there's no filler and every sentence earns its place.

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

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

For a read-only verification tool with no output schema, the description adequately covers what is verified, when to use it, and the key parameter behaviors. The only gap is that it doesn't describe the return format (e.g., success/failure structure), which an agent might want, but this is minor and the description is otherwise complete for a verification operation.

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

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

Schema coverage is 100%, so the schema already documents all five parameters. The description still adds meaningful nuance beyond the schema, specifically around `objects` ('omit to verify every object referenced in the project') and `projectPath` ('Required for project-reference check'), which clarifies behavior parameters alone don't convey. Schema carries most weight, but the description enriches it rather than merely repeating it.

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

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

The description states a specific verb and resource: 'Verify that D365FO objects exist on disk at the correct AOT path and are referenced in the .rnrproj project file.' It precisely distinguishes the tool from its siblings by naming its check scope (disk path + project reference), which differentiates it from nearby tools like d365fo_file, build_d365fo_project, and find_references.

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

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

The description explicitly routes usage: 'Use instead of PowerShell to check d365fo_file(action="create") results,' which tells the agent when to reach for this tool over an alternative. It also explains the omit-objects workflow for verifying the entire project and states the projectPath prerequisite. It doesn't enumerate sibling exclusions, but the guidance given is concrete and actionable.

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