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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is low, but the description adds genuinely new behavioral limits: it does not download files, does not expose temporary URLs, and does not create private report drafts through MCP. That tells an agent precisely where the tool's authority ends.

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?

Two sentences, zero filler, with the positive statement of purpose front-loaded and the boundary conditions following. Every clause carries information an agent would otherwise have to guess.

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 an output schema present, the description need not explain return values, and with zero parameters there is no input to document. What remains — what the tool produces and what it explicitly will not do — is fully covered.

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 tool takes zero parameters and the schema states 'No inputs', so there are no parameter semantics to clarify. The description correctly adds no parameter noise, which is the right behavior for a no-arg tool.

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?

States a specific verb and resource ('Returns a read-only manifest of Hedgr exports') plus the scope ('available in the dashboard and where to generate them'). It is clear what the tool yields, though it never names or differentiates itself from any sibling beyond the implicit read-only family pattern.

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?

Usage is implied by the negative boundary ('Does not download files, expose temporary URLs, or generate private report drafts through MCP'), which tells the agent this is a discovery step rather than a retrieval step. However, it never states when to call it versus other discovery tools such as get_dashboard_context or get_platform_capabilities, and no alternative is named.

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