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

The description says 'Fetch', which strongly implies a read-only operation, but the annotation declares readOnlyHint=false, suggesting the tool may have side effects. This is a direct contradiction. No other behavioral traits (e.g., side effects, error on missing project) are disclosed.

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 a single, concise sentence with no filler words. It front-loads the core purpose and lookup method, achieving maximum clarity with minimal text.

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 one simple parameter and no output schema, the description covers the basic purpose, but the contradiction with annotations leaves a critical gap. It does not explain return payload, error behavior, or any side effects, making it incomplete 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?

With schema description coverage at 0%, the description is the only source of parameter meaning. It clarifies that 'project' accepts an id or slug, which adds real value beyond the minimal schema. However, it does not specify format, requiredness, or constraints, so the compensation is partial.

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 uses a specific verb ('Fetch'), resource ('project'), and scope ('single'), and explicitly names the lookup key ('by id or slug'). This clearly differentiates it from siblings like list_projects or get_status without needing to inspect schemas.

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 implies usage when a single project is needed by id or slug, but it does not explicitly contrast with alternatives like list_projects or when not to use it. No exclusion or alternative routing is given, leaving context implied rather than stated.

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