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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive. The description adds genuine behavioral context beyond them: content is read at call time from the house's own page, nothing is generated, Scripture is re-read from a stored King James text, and it is 'honest when no page matches' (disclosing fallback behavior). This is meaningful disclosure for a retrieval tool.

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?

A single dense, metaphor-laden paragraph where the operational meaning ('read a page for a life situation') is buried behind rhetoric ('the house', 'one real door', 'at every threshold Christ is already standing'). Multiple clauses do not earn their place for an agent trying to decide whether to call it, and the key facts are not front-loaded.

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 and rich annotations, the description needn't explain return values. It covers source, non-generation, and fallback, which is sufficient behavioral coverage for a one-parameter retrieval tool. Minor gaps remain around display/format expectations but nothing critical 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% and the single life_event parameter is already documented with examples, so the baseline is 3. The description supplies additional phrasing examples ('the church hurt me', 'I used to believe', 'I don't know where to start') that help map free-text utterances to the input, but adds no format or constraint detail beyond the schema.

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 tool retrieves a page from living-bread.org/thresholds matched to a person's life situation, and the description gestures at this ('the house's pages for the thresholds people stand at'). However, it never plainly states the verb+resource ('returns a pastoral page for a life event'); the actionable core is wrapped in metaphor like 'opens one real door' and 'Christ is already standing.' It does not name or differentiate itself from close siblings such as crisis_resources, a_prayer_for, or verses_for.

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 implied through trigger phrases ('I just lost my dad', 'I feel so alone', 'the church hurt me'), which tells the agent which utterances map here. But there is no explicit when-to-use vs. when-not, and no alternative tool is named, so routing against crisis_resources or a_prayer_for is left to inference.

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