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

Annotations already declare readOnlyHint and destructiveHint, so the safety profile is covered. The description adds valuable behavior beyond annotations: the content is 'the same content rendered publicly' at the web URL and is 'never the entitlement-gated depth layer', plus it enumerates exactly which sections are included. No contradictory statements.

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 front-loaded with the core action ('Get the full free content of one capability guide by slug') and then details the content structure in an organized list within the sentence. Every clause earns its place, though the sentence is long and dense; splitting it into two sentences could improve readability without losing information.

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 single-item retrieval tool with one parameter, a full output schema, and annotations covering safety, the description is complete. It explains exactly what the returned content includes (sections, tensions, sources), the public vs. gated scope, and the slug provenance. No essential call-time information is missing.

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% for the single slug parameter, giving baseline 3. The description adds meaning by stating the slug is obtained '(from list_guides)', revealing a cross-tool prerequisite and implying the slug must be a known guide identifier, not an arbitrary string. This goes beyond the schema's simple example.

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 clearly states the tool retrieves 'the full free content of one capability guide by slug' — a specific verb, resource, and retrieval mechanism. It distinguishes itself from siblings like list_guides (plural listing) and get_guide_part (part retrieval) by emphasizing 'full' guide content and naming the five-movement structure that constitutes the whole.

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?

It tells the agent the slug must come from list_guides and explicitly excludes the entitlement-gated 'depth' layer, conveying when not to use this tool. However, it does not explicitly name alternatives like get_guide_part for when only a section is needed, so the guidance is strong but not fully explicit about sibling routing.

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