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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile, and the description's 'Read' is consistent with that. The description adds interpretive context about what tree/tour outputs represent, which is useful but largely repeats the schema's own parameter descriptions. It does not disclose behavioral details like response shape, ordering guarantees, or revision-handling behavior beyond what the schema states for expected_revision.

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 two sentences with zero wasted words. It front-loads the action verb and resource, and appends the sibling-routing guidance in the second sentence. Every clause earns its place, and the structure makes the primary purpose immediately scannable.

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 output schema is present, parameters are fully covered by the schema, and annotations carry the safety profile, the description covers what an agent needs for correct invocation: the purpose, the two view modes, and the key alternative. The main gap is the lack of guidance distinguishing atlas_navigate from the other six siblings, particularly atlas_read, which sounds functionally similar by name. This is a minor omission in an otherwise complete definition.

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 both 'view' and 'expected_revision' already documented in the schema, so the baseline is 3. The description adds marginal elaboration ('every published node', 'first learning path') that slightly enriches the view enum, but it adds nothing about expected_revision. With the schema carrying the full burden, the description's contribution here is minimal but adequate.

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 ('Read') and resource (the 'tree' or 'tour' view), and immediately defines what each means: 'canonical ordered traversal of every published node' vs 'publisher-curated first learning path.' It also distinguishes itself from sibling atlas_orient by naming it explicitly for a different purpose. An agent can determine exactly what this tool does without opening the schema.

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 an explicit alternative and the condition that selects it: 'Use atlas_orient for relevance-ranked discovery.' This tells the agent when not to use atlas_navigate for at least one close sibling. However, with seven sibling tools in the list, it does not address differentiation from the others (e.g., atlas_read, atlas_cards), leaving some routing ambiguity.

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