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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds non-obvious context the annotation can't: output is text, cost is 'Free', and there is a preferred skill-file alternative. It does not mention pagination behavior via cursor or size limits, hence not a 5.

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 short sentences, no filler. The primary purpose and the alternative-skill condition are front-loaded before the parameter modes, so the most decision-relevant information comes first.

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?

An output schema exists, so return-value explanation is unnecessary, and all six parameters are documented in-schema. The description covers purpose, routing, and the skill fallback; only pagination/chunking behavior (cursor + max_characters interaction) is left to the schema, which is a minor 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 coverage is 100% and every parameter has a terse description ('Omit to list or pick by task', 'Your goal, to pick a guide', 'Prior next_cursor', etc.), so the schema carries the load. The description's id/task routing rule is genuinely useful but overlaps with the usage-guidance dimension, and it says nothing about cursor, section, version, or max_characters. Baseline 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?

Specific verb + resource + format: 'Fetch a Locus how-to guide as text.' It also states scope (how-to guides, not API docs) and is easily distinguished from siblings like describe_api or search_apis.

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 the when/when-not condition: use this 'when no Locus skill files are installed; otherwise prefer the skill.' It also gives mode selection (omit id to list, pass task for a goal-targeted guide), so an agent knows exactly which call shape to use.

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