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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the opening 'read-only lookup with no side effects - safe to call repeatedly' largely restates structured data, though it is not a contradiction. The description earns credit for genuine behavioral detail beyond annotations: cancelled shifts are excluded from the result and the caller's own signups are returned alongside the shifts.

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?

It is a dense, front-loaded paragraph with no filler sentences; the safety claim leads and the ID-provenance rules follow. The opening clause duplicates the annotations, which costs a little efficiency, but every remaining sentence carries 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?

An output schema exists, so return values need not be explained, yet the description still maps output identifiers to the inputs of related tools, which is exactly the cross-tool knowledge an agent needs to chain calls. Nothing required to invoke it correctly 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%, so the baseline is 3 and both parameters are already documented. The description still adds cross-tool semantics: event_id comes from list_school_events, and the returned shift 'id' values are the shift_id input elsewhere, tying parameter meaning to sibling tool contracts.

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 and resource ('Returns one event's full detail for the selected school') and enumerates exactly what is included: date, times, location, capacity, ticket price, status, volunteer shifts with remaining slots, and the caller's signups. It distinguishes itself from the sibling list_school_events, which is named as the source of event_id.

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 where to get the required event_id ('from list_school_events') and how the returned shift and signup IDs feed sign_up_for_volunteer_shift and cancel_my_volunteer_signup, which is real routing guidance. It stops short of stating when NOT to use it (e.g. bulk retrieval vs. the list tool), so it is clear context without explicit exclusions.

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