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

Annotations already establish readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered — but the description goes well beyond that. It discloses that sermon and full-recording fallbacks are excluded, that text_type signals AI-edited or summarized rather than verbatim speech, that recording/summary-update dates are not expiry dates, the 8000 UTF-16 truncation limit with truncated/total_chars completeness flags, that no AI generation or network retrieval occurs, and that shared rate limits apply. This is unusually rich behavioral disclosure.

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 core purpose and section preference are front-loaded in the first sentence, and the remaining sentences are dense caveats rather than filler — each carries a distinct constraint (fallback exclusion, text_type meaning, date semantics, truncation, no AI, rate limits). It is information-heavy but not padded, though the caveat sentence about truncation is close to restating what the output schema already exposes.

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?

With an output schema present, return-value structure need not be explained, and the description nonetheless covers the two things an agent could get wrong: the 8000-unit truncation and the semantics of text_type and the session dates. Combined with the session-state precondition and the rate-limit note, nothing needed to call this tool 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% and the schema description already defines session_id as an exact public recording session ID with length bounds and a source example, so the baseline is 3. The description adds qualifying semantics the schema does not: the session must have ended or been interrupted, and it must contain saved announcements for a result to exist.

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 gives a specific verb and resource ('Returns saved parish announcements') and immediately narrows the scope to 'an ended or interrupted public session', naming the exact section preference (edited announcements section, else summary tab). That precision distinguishes it from siblings like get_sermon and get_transcript without the agent needing to open their schemas.

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?

Usage context is implied by the 'ended or interrupted public session' qualifier, which tells the agent this is for completed recordings rather than live or in-progress ones. However, no sibling is named as an alternative and there is no explicit when-not-to-use statement, so the agent must infer the routing from the content caveats alone.

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