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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real behavioral information: live-room playback state travels over Realtime presence and is explicitly not readable through this tool, and the tool 'says so rather than guess'. It also discloses the internal shelving structure of the catalogue. What it omits is any note on freshness or size of the returned set.

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?

Purpose and scope are front-loaded, but the single dense paragraph leans heavily on metaphor ('the two doors', 'the house offers') where plain enumeration would be faster to parse. The trailing list of example queries is useful and earns its place, yet several parenthetical clauses restate what was already said.

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 structure is already covered, and the annotations handle safety. For a zero-required-parameter retrieval tool the description supplies scope, the four time-of-day shelves, the two access modes, and an explicit limitation on live-room state. The main gap is parameter-level behavior, but overall an agent has enough to call it correctly.

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 a middling 67%: 'mood' and 'local_hour' are documented in the schema, while 'language' has no description anywhere. The prose only glancingly touches parameters via 'what the house offers for this hour', and says nothing about how 'mood' influences results or how 'language' narrows them. It therefore fails to compensate for the undocumented parameter.

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 names a concrete resource and enumerates its contents: a worship catalogue divided into morning/day/evening/night shelves with songs and rationale, public-domain hymns, and two 'doors' (Worship and Worship Together). That is specific enough to distinguish it from siblings like 'hymn', 'gatherings_tonight', or 'daily_bread'. It never states a crisp verb ('list', 'get'), so the agent must infer that this is a retrieval tool, which keeps it out of 5 territory.

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 is conveyed indirectly through example user phrasings ('something to worship to tonight', 'a hymn for the morning', 'is anyone worshipping together right now'), which gives the agent solid situational context. However, no sibling is named as an alternative and there is no explicit when-not guidance, even though 'hymn' clearly overlaps with the public-domain hymns this tool also returns. That overlap is left for the agent to resolve.

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