Macaroon Bible Evidence

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so safety is fully covered by structured data. The description adds that exactly one cross-reference is returned and that relationship attribution is included, but says nothing about auth, rate limits, or error behavior. A 3 fits with annotations carrying the safety burden.

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, front-loaded sentence with no filler. Every element (verb, cardinality, input scope, attribution) earns its place.

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-value detail is not required, but the four required parameters have zero schema descriptions and the description does not fill that gap. For a tool whose inputs determine the entire query, an agent lacks enough information to format source_id and book_id 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 description coverage is 0% across four required parameters, so the description would need to compensate but does not. It only hints at 'exact verse' and never explains source_id's bsb/web enum, book_id format, or the chapter/verse bounds documented in 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 description uses a specific verb ('Return') and resource ('one sourced cross-reference for an exact verse') and adds a distinguishing scope note ('with relationship attribution'). It is clearly not a comparison or context tool, though it never names which sibling to prefer over it.

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?

There is no when-to-use, when-not-to-use, or alternative-tool guidance. The phrase 'for an exact verse' implies a precision requirement but does not tell an agent when this preview is preferable to faith_scripture_lookup or faith_passage_context_preview.

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

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

Annotations already declare the tool as read-only, idempotent, non-destructive, and closed-world. The description adds a useful behavioral guarantee beyond annotations: it promises comparison 'without blending or interpreting the source texts,' clarifying output fidelity and scope. No auth, rate-limit, or pagination details are provided, but those are not critical here.

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 a single, front-loaded sentence with no redundant or filler content. It communicates the core operation efficiently.

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 values need not be explained, and annotations cover the safety profile. However, the description lacks sibling routing guidance and any parameter format details, leaving meaningful gaps for an agent selecting and invoking the tool.

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 0% and the description does not explain book_id, chapter, or verse semantics beyond implying a single verse is required. It does not specify the expected book_id format or translation identifiers, so it fails to compensate for the missing schema descriptions.

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 states a specific verb ('Compare') and resource ('one exact verse') with named translations (BSB and WEB), making the core purpose clear. It does not explicitly differentiate itself from sibling tools like faith_scripture_lookup or faith_passage_context_preview, so it falls short of a 5.

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 provides no guidance on when to use this tool versus alternatives such as faith_scripture_lookup or faith_passage_context_preview. The phrase 'without blending or interpreting' hints at a use case, but no explicit when-to-use or when-not-to-use conditions are given.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world reads, so the safety profile is covered. The description adds real behavioral content on top: the exact output window (one verse before/after, same chapter only) and the guarantee that no interpretation is generated.

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?

One sentence, front-loaded with the returned artifact and its scope, closing with the key negative guarantee. No filler and nothing repeated from structured fields.

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 shape needn't be explained, and the window semantics are stated. However, with four required, zero-documented parameters the definition is thin, and edge behavior (e.g., verse 1 or the last verse of a chapter having no neighbor) is unaddressed.

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 0%, so the description must carry parameter meaning and does not. It never clarifies source_id values (bsb/web), book_id format conventions, or chapter/verse numbering assumptions, leaving the agent to infer semantics from bare field names and numeric bounds.

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?

States a specific verb (Return) and a precisely scoped resource: the requested verse plus one same-chapter verse before and after. This is distinguishable from a plain lookup or a search tool by the context-window semantics, though no sibling is named to reinforce the distinction.

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 clause 'no generated interpretation' implicitly signals this is the raw-context option rather than an interpretive/guide tool such as faith_topic_guide_preview, but it never states when to pick this over faith_scripture_lookup or faith_passage_compare_preview. Usage is implied rather than instructed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the useful constraint that retrieval is limited to a same-chapter range of at most five verses and only from "pinned" evidence sources. It says nothing about what happens when the range is invalid or exceeds the chapter, but with annotations this gap is minor.

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 front-loaded sentence with no filler or repetition of the title. It is efficient, though arguably too terse given the five undocumented required parameters.

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 format need not be described, and annotations cover safety. The remaining gap is parameter documentation: five required parameters with no schema descriptions and only partial coverage in the description leaves an agent guessing at book_id format and range semantics.

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 0%, so the description must carry parameter meaning; it partially does by naming the source enum values implicitly (BSB or WEB) and by revealing that verse_start/verse_end describe a 1-5 verse same-chapter span. It does not explain book_id format (abbreviation? 2-24 chars), chapter/verse numbering conventions, or whether verse_end is inclusive.

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 ("Retrieve") and resource ("exact, same-chapter verses") plus the qualifying constraints (one to five verses, pinned BSB or WEB). These constraints implicitly separate it from sibling tools like faith_scripture_search_preview or faith_passage_context_preview, though no sibling is named. Clear purpose, but sibling differentiation is only inferable.

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?

There is no explicit when-to-use or when-not-to-use statement, and no alternative tool is named despite nine siblings that overlap heavily (search, compare, context, cross-references). The scope wording ("exact, same-chapter", "one to five") hints at boundaries but never states them as routing criteria.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false). The description adds a useful behavioral trait — the hard cap of three results and the literal (non-semantic) matching — but says nothing about the two corpora, match failure behavior, or result shape beyond what the output schema carries.

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 front-loaded sentence with no wasted words; the result limit appears before the qualifier. It is tight, though the terse semicolon clause reads more as shorthand than as structured guidance.

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 values need not be described. However, with two required parameters, one of them an undocumented enum, the definition leaves an agent guessing which corpus to select — a meaningful gap for a two-parameter tool.

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 0%, so the description must compensate. It only partially hints at 'query' being short (matching the 40-char cap) and completely ignores source_id, whose enum values 'bsb' and 'web' are opaque abbreviations an agent cannot resolve from the description.

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 concrete verb and resource: return up to three literal corpus matches for a short keyword or phrase. The 'not a doctrinal ranking' clause implicitly separates it from interpretive siblings such as faith_topic_guide_preview, though no sibling is named outright.

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?

Input expectations are implied ('short keyword or phrase'), but there is no statement of when to choose this over faith_scripture_lookup or faith_passage_context_preview. Usage must be inferred from the description alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds only that details are 'current' and that the service is 'public', which gives some behavioral context. It does not cover authentication, error cases, or pagination beyond what annotations imply.

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 a single front-loaded sentence with no wasted words. It immediately communicates the action, target resource, and scope.

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 simple single-resource lookup with rich annotations, a fully described parameter, and an output schema, the description is mostly complete. It does not explain how this tool relates to similar service tools like faith_service_page or faith_service_evidence, leaving a minor sibling-selection gap.

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 service_id parameter is fully documented with type, pattern, and description in the schema. The tool description does not add format or syntax details beyond what the schema already provides, so baseline 3 is appropriate.

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?

States a specific verb and resource: get details for one Christian Faith service. It also scopes the resource to public services. However, it does not distinguish itself from nearby siblings such as faith_service_page or faith_service_evidence, so it is clear but not sibling-differentiating.

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 phrase 'one public Christian Faith service' implies the tool is for retrieving a single service when its ID is known, as opposed to list or search tools. There is no explicit guidance on when to use this versus faith_services_list, faith_services_search, or faith_service_page. Usage is therefore implied but not fully specified.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the useful notion that the payload includes limitations, not just evidence, but says nothing about provenance, freshness, or the shape of that evidence.

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 tight sentence with no filler, front-loading the verb and the payoff ('validation evidence and limitations'). Every word earns its place.

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-value description is not required, and the lone input parameter is covered. The remaining gap is routing: nothing tells the agent how this differs from faith_service_detail or when evidence retrieval is the right call.

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 service_id parameter is fully documented with a pattern, so the schema does the heavy lifting. The description only reinforces that the ID refers to one public Christian Faith service; it adds no syntax or format information 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?

Clear verb ('Get') plus a specific resource ('validation evidence and limitations for one public Christian Faith service'), which distinguishes it from siblings like faith_service_detail and faith_service_page that presumably return service content rather than validation metadata. It stops short of making that contrast explicit, so an agent must infer it from the name.

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?

No when-to-use or when-not-to-use guidance. With ten sibling faith_* tools, including faith_service_detail, an agent is given no cue as to when evidence/limitations retrieval is warranted versus fetching the service record itself. Usage is only implied by the resource name.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds a distinct trait beyond annotations: retrieving the page incurs no execution and no cost, which is meaningful decision context for an agent choosing between previewing and actually invoking a service.

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 front-loaded sentence with no filler; the read-without-cost constraint is stated immediately. The only minor cost to structure is the unexplained 'Macaroon' term, which forces the reader to guess at the resource.

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 one-parameter read tool with full annotation coverage and an output schema, the description supplies enough to call it correctly: no auth, no payment, no execution. The remaining gap is sibling disambiguation against faith_service_detail and faith_service_evidence, which is not addressed.

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% for the single service_id parameter, including its regex-constrained format and 'exact public Christian Faith service ID' definition. The description adds no further meaning about the parameter, so the baseline of 3 applies when the schema does all the work.

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 verb 'Get' is clear, but the resource is described as an 'external Macaroon page', a term that does not map onto anything recognizable in the Christian Faith service domain implied by the service_id pattern. It also fails to distinguish itself from adjacent siblings such as faith_service_detail or faith_service_evidence, so an agent cannot confidently route between them from the text alone.

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?

'Without executing or paying for a service' implies the condition under which to prefer this tool (read-only inspection of a page rather than running/purchasing the service), which is useful implied guidance. However, no alternative tool is named and no explicit when-not-to-use case is given, so the routing signal remains inferential.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the 'public, sale-ready' eligibility filter, which is real behavioral context, but says nothing about volume, pagination, ordering, or what 'sale-ready' excludes.

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?

One short, front-loaded sentence with no filler or repetition. It is arguably too terse: 'sale-ready' is unexplained domain jargon that a caller may not be able to interpret.

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 values need no explanation, annotations cover the safety profile, and there are no parameters to document. The only gap is the undefined 'sale-ready' qualifier and no hint of result size or pagination.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. There are no per-parameter semantics for the description to add or omit.

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?

Names a specific verb+resource ('List ... services') and narrows scope with 'public, sale-ready Christian Faith and Theology'. It is distinguishable from faith_services_search (querying) and faith_service_detail (single item), though it never names those siblings explicitly.

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 'public, sale-ready' qualifier implies this is the unfiltered catalog listing rather than a query tool, which is implicit usage guidance. However, there is no explicit statement of when to use this versus faith_services_search, faith_services_preview-style tools, or faith_service_detail.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so safety is covered. The description adds two useful behavioral facts not in the annotations: results are limited to public (non-private) services, and the query must be non-personal. It says nothing about result volume beyond the schema's limit or about latency/rate behavior.

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 front-loaded sentence with no filler; the search verb and scope come first. It is arguably too sparse rather than padded, which is a completeness issue, not a conciseness one.

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 explanation is not required, and the tool is a simple two-parameter search. Still, it omits what 'capability query' concretely means, what the limit controls, and how results relate to the sibling detail/evidence tools, leaving gaps for an agent choosing among ten faith_* tools.

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 0%, so the description carries the burden, and it partially meets that burden by defining the query as short, non-personal, and capability-oriented. The limit parameter is left entirely unexplained — no indication it caps result count or interacts with pagination.

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?

States a specific verb (Search) and resource (public Christian services), which reads clearly as a discovery tool. It doesn't explicitly contrast itself with close siblings like faith_services_list or faith_service_detail, so the agent must infer the differentiation from names alone.

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 phrase 'short, non-personal capability query' implies what kind of query to send and hints at appropriate use, which is useful guidance. However, there is no explicit when-to-use versus the sibling list/detail/preview tools, and no stated exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description's 'deterministic' largely restates idempotentHint, while 'source-labelled' is a mild hint about output shape; it adds little behavioral context beyond the annotations.

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 front-loaded sentence with verb, resource and scope and no filler. Nothing could be removed without losing information, and the key constraint (one topic) comes last in a natural reading order.

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 covering return values and annotations covering the safety profile, plus an enum-constrained two-parameter input, the description is nearly sufficient for correct invocation. The remaining gap is that it neither explains the source_id enum values nor distinguishes itself from overlapping siblings like faith_service_evidence.

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 0%, but both parameters are enums that self-document their valid values. The description adds only 'supported topic' for topic and implies a source labelling for source_id, but never clarifies what 'bsb' vs 'web' means or what the topics represent, leaving the cryptic source_id identifier under-explained.

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?

States a specific verb ('Return') and resource ('source-labelled evidence guide') scoped to 'one supported topic', which an agent can distinguish from passage-context or cross-reference siblings. However, it never names an alternative, and 'evidence guide' overlaps semantically with the sibling faith_service_evidence, so differentiation is only partial.

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?

There is no when-to-use guidance, no when-not-to-use, and no mention of any alternative tool among the ten siblings. The phrase 'one supported topic' implies a constrained input but says nothing about when this guide is the right choice over a lookup or search.

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