get_app_guide_section

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's job is behavioral context beyond safety — and it delivers: the guide is 'intentionally limited to stable, customer-facing help,' navigation must be grounded only in explicitly named paths ('Do not infer, invent, or autocomplete nearby navigation'), and pricing must be reproduced verbatim with an exact CTA block appended in the in-app coach. These operational constraints shape how the agent should consume the result and cannot be inferred from annotations or schema.

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?

Front-loaded with purpose in the first sentence, then flows from usage scope to exclusions to navigation grounding to operational pricing rules to examples — a logical structure. It is long, but every section carries operational weight; the only drag is the dense single-sentence exclusion list, which could be broken up for easier parsing.

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 1-parameter lookup tool with an output schema present, the description covers everything needed for correct invocation: purpose, scope boundaries, grounding constraints, exact pricing reproduction behavior, and worked examples. Combined with annotations covering the read-only/idempotent profile, nothing material 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 description coverage is 100%, so each of the 12 enum values is already thoroughly documented, giving a baseline of 3. The description adds genuine value above that via natural-language example mappings ('where do I see my PRs?' -> pages_training) and by clarifying that cost/Free/Pro/Founding Member/3-analysis questions route to topic=pricing — a routing detail not present in the schema enum description.

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: 'Look up general customer help for the Wellness Project app.' Then narrows scope to 'broad questions about where a feature lives, how to use it, what a visible feature does, common troubleshooting steps, or pricing,' which clearly distinguishes it from the data-centric sibling tools like log_meal, update_workout, and get_exercise_history.

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?

Gives explicit scoping with 'Use this only for...' followed by a precise list of question types, plus negative guidance listing what must not be added or inferred (implementation details, policy, privacy claims, billing mechanics, etc.). It also provides concrete example-to-topic mappings and detailed conditional rules for the pricing topic, telling the agent exactly which message to reproduce and when.

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