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

The annotations already indicate a read-only, idempotent, non-destructive operation, and the description adds substantial behavioral context beyond that: it will not search a database, will not return specific groups or contact details, will not assess named churches, and it returns crisis resources when self-harm or suicide is mentioned. These limitations and safety behaviors are exactly the kind of information an agent needs to invoke the tool appropriately.

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 description is dense but well organized: purpose first, then usage trigger, then inputs, then outputs, then limitations and safety behavior. Every sentence earns its place, and the critical scoping information is front-loaded. Despite its length, it avoids redundancy and is highly skimmable.

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?

There is no output schema, so the description carries the full responsibility for explaining return values, and it does so thoroughly: where people from a tradition typically look, a checklist of warning signs and healthy-group signs, and a link to Sanctuary's finder page. It also covers all optional inputs, use cases, limitations, and a safety fallback. For a six-parameter tool with no output schema, this is complete.

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 each parameter already has a clear description in the schema. The tool description summarizes the six parameters in plain language ('area, faith tradition, life stage, in-person or online, what they want to avoid, and whether they want to join or start a group'), but it mostly restates what the schema already documents. It adds little new meaning beyond a convenient grouping.

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 is specific and concrete: 'Writes a guide to finding a house church, microchurch, dinner church, Alpha course, or church small group...' It lists the exact resource types and the output components, and explicitly differentiates itself from retrieval tools by stating it does not search a database or return specific groups. This makes the tool's purpose unmistakable and distinguishes it from siblings.

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?

The description clearly states when to use the tool: 'Use when the user asks for help finding a Christian gathering or community, whether after leaving a church, moving, coming to faith, or being between churches.' It also gives useful exclusions (no database search, no assessment of named churches), but it does not explicitly name sibling tools as alternatives for other cases, so it stops short of a full when-not-to-use routing.

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