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

Annotations only declare a safe read operation, so the description carries the real behavioral burden and does it: it discloses that 2hives has no prayer sessions yet, that the tool returns an honest negative answer, and that it offers a quiet session without words instead. That is outcome behavior an agent could not derive from readOnlyHint/destructiveHint and prevents it from promising content that does not exist.

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 the trigger clause, followed by behavioral caveat, then exclusions, which is the right order for an agent. Every sentence carries information, though the four consecutive negative sentences are slightly list-like and could be compressed into one exclusion clause.

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 three-optional-parameter read tool with full schema coverage and no output schema, the description supplies everything missing: the trigger condition, the empty-catalog behavior, the substitute offer, and clear boundaries. An agent can decide whether to call it and can set expectations about the response without further information.

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% and all three parameters (voice, language, length_min) are documented in-schema with defaults, ranges and enum values. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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 identifies the resource clearly (prayer, rosary, evening prayer, Bible reading) and distinguishes it from sibling tools by naming find_sleep_sessions and find_breathing as different resources. The verb is implied through trigger conditions rather than stated directly, so an agent infers 'finds prayer audio' rather than reading it, but nothing is ambiguous.

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?

Explicit when-to-use triggers are given ('when the user asks for a prayer, a rosary, an evening prayer or a Bible reading') along with hard exclusions: not medical, not emergencies, not crisis, not general meditation chat. It also routes two adjacent needs to named alternatives, find_sleep_sessions and find_breathing, which is exactly the when-not guidance an agent needs.

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