The Living Bread

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), but the description adds genuinely non-obvious behavior: content is read live from the house's page at call time, the words are the house's and the Scripture is re-read from stored King James text, nothing is generated, and it is honest when no page matches. That failure-mode and provenance disclosure is exactly the value the description should add on top of 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?

The core purpose is front-loaded, but the middle is a sprawling catalogue of a dozen-plus situations that could have been compressed, and the final sentence about praying by name is confusing rather than informative. Some enumeration helps a free-text retrieval tool, but the sentence structure is not disciplined.

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 needn't be explained, and the description covers source, provenance, and the no-match case well. The remaining gap is sibling positioning: with `pray_for_someone` and `ask_living_bread` present, the description should say how this differs, which it does not.

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 `situation` parameter, so the schema already documents its format and the 120-char bound. The description's example queries restate the same idea as the schema's own example ("my daughter's surgery"), adding no syntax or matching semantics beyond it. 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?

The description states a specific verb and resource: it reads a hand-written prayer keyed to a situation from the house's library, with a concrete source (living-bread.org/a-prayer-for). The enumeration of covered situations makes the retrieval scope unambiguous. It stops short of 5 because it never distinguishes itself from the similarly named sibling `pray_for_someone` or `ask_living_bread`, leaving the agent to infer the boundary.

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 sample user phrasings ("a prayer for my mother in hospital", "a morning prayer", "pray for my marriage"), which helps the agent recognize a matching intent. However, no when-not-to-use condition or named alternative is given, and the closing sentence about praying "with the person by name" actively muddies the line against `pray_for_someone`.

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, open-world. The description adds real behavioral context beyond that: answers are grounded in sourced entities, verses are read from a stored KJV, and "when we do not know, the answer says so" — a useful honesty guarantee. It does not detail latency or any rate limits, which keeps it at 4.

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-loads the core purpose and return content, then usage and examples. The parenthetical entity list is dense but informative, and the closing honesty clause is short. Slightly longer than necessary but nothing is pure filler.

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, the description need not explain return values, and it still summarizes them well (entities, Scripture topic, verses, next steps). Scope, honesty guarantees, and example inputs are covered, making it complete enough for an agent to call it correctly; it only lacks explicit routing to specialized siblings.

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 parameter, so the schema already documents "question". The description complements this with realistic example questions, but adds no format or length guidance (the 300-char cap is only in the schema). 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 clear purpose: return a grounded, sourced answer from the Christian Knowledge API covering entities, Scripture topics with KJV verses, and next steps. The examples ("what is a Methodist", "where is Bethlehem") make the scope concrete. Differentiation from siblings is only implicit via "a feeling with no clean keyword" and no sibling is named, so it stops 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?

Gives clear when-to-use guidance: "Use for any question about Christianity, a tradition, a person of Scripture, a place, or a feeling with no clean keyword." The phrase "no clean keyword" implies it is the fallback when a specialized sibling does not fit. It never names an alternative tool or states explicit exclusions, so it is a 4 rather than a 5.

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 adds only that this is a newcomer entry point and what content appears first, which is useful orientation but not deep behavioral context. Nothing is contradicted, but little is added beyond the structured hints.

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?

Two sentences, no repetition, and the trigger conditions are placed after the content summary. The opening metaphor is slightly decorative but does not bloat the text meaningfully.

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, and the tool is a simple zero-parameter read. The description covers purpose and usage adequately. Only a pointer to a sibling alternative would make it fully 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?

The tool takes zero parameters and schema coverage is 100%, so there is no parameter semantics to explain. Baseline 4 applies; the description correctly spends no space on inputs.

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 what the tool surfaces: the web home, App Store and Google Play links, and first-time newcomer content. It is a clear content-oriented resource, though the metaphorical 'the invitation and the doors in' is less precise than a plain verb+resource statement. It does mark itself as the onboarding/entry point among siblings like journey_next_steps or communities_to_join.

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?

It gives explicit triggers: someone wants to join, asks what The Living Bread is, or is seeking without knowing where to start. That is concrete when-to-use guidance. It does not name an alternative sibling to prefer in overlapping cases (e.g., journey_next_steps), so it stops short of a 5.

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 (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, and the description still adds real value: content is read at call time from the house's own page, wording is the house's, Scripture is re-read from the stored King James text, and nothing is generated. The no-match behavior is disclosed. It stops short of describing response shape or caching/latency traits.

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 topic enumeration and provenance ('the words are the house's, the Scripture is re-read from the stored King James text, nothing is generated') are load-bearing, but the closing devotional line about Jesus Christ does not help tool selection, and the opening 'One of the house's...' delays the core purpose.

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 values need no explanation, and the description supplies the provenance, honesty-on-miss, and content-scope context an agent needs. Only the choice against near-duplicate siblings is left 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 100% and the single 'topic' parameter already documents its examples and length bounds, so the schema carries the load. The description's topic list and example questions reinforce but do not add format or matching semantics beyond what the schema provides, making the 3 baseline 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?

The description identifies the resource clearly (the house's 'What Christians Believe' pages, short and full) and enumerates the topics it covers, and it distinguishes itself from siblings like what_the_bible_says_about by naming its own page and provenance. It never leads with a clean verb like 'retrieve/read', so the action must be inferred from 'Read at call time', which softens the clarity.

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?

It implies the use case via example queries ('what is grace', 'what do Christians mean by salvation'), which helps an agent match user phrasing. But it never states when to prefer this over close siblings such as what_the_bible_says_about, the_gospel, or christianity_and_other_faiths, nor any exclusion conditions beyond 'Honest when no page matches'.

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 safety is covered. The description adds real context beyond that: it is a "mirror and never a leaderboard", data is shown "by feeling and count only", and output varies with connection state ("when connected as yourself"). It does not describe freshness bounds or pagination.

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?

It is a single dense run-on sentence listing four aggregates, followed by a list of example questions. The information is front-loaded but the framing ("as a mirror and never a leaderboard") adds prose weight before the concrete payload, and the one-sentence structure makes it harder to scan.

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 the description need not document return values, and with zero parameters the input surface is trivially complete. It covers auth-state sensitivity and aggregation scope, but leaves ambiguous whether the parenthetical names are sub-sections of this response or separate tools to 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter syntax to clarify, though the parenthetical references to body_responding_today, family_carrying_today and prayer_in_place_totals are left unexplained about how they relate to this call.

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 specific resource (the family's activity today) and enumerates its constituent aggregates: people prayed for/encouraged, what the family is carrying, prayers at places, and Tables when connected. This distinguishes it from point-in-time siblings like tables_live_now or prayers_left_near. It does not directly name the siblings it is not, so it stops 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?

It supplies concrete trigger phrases in the user's own voice ("what is the family doing today", "is anyone praying right now", "what are people carrying"), which gives an agent solid context for when to call it. However, it never states when NOT to use it or names an alternative sibling for narrower questions.

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, openWorld, and non-destructive, so the safety profile is covered. The description adds content character ("read at call time", "honest, respectful... never an argument"), which is useful context about the payload, but says nothing about what the output looks like or any length/tone constraints beyond that.

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 definition opens with the target audience but then sprawls into a 15-item parenthetical list of traditions and a closing line about "a Table, a shepherd, the family" that does not help tool selection. The content is front-loaded but padded with detail that does not earn its place in a selection-time description.

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 explanation is unnecessary, and the annotations cover the safety profile. The description supplies audience, topic scope, and illustrative queries, which is nearly enough for a one-parameter content tool; only the sibling boundary remains 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 100% and the single background parameter is fully documented in the schema with its own example values. The description's examples restate the same free-text nature of that field rather than adding format or constraint detail, so the schema already carries the load.

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 concrete resource ("the house's Come and See pages") and its scope (Christianity alongside a long list of other faith traditions), so an agent can tell what content is surfaced. However, it never names a retrieval verb and offers no differentiation from overlapping siblings such as the_gospel, denomination_compare, what_the_bible_says_about, or belief.

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 quoted seeker questions ("I'm Muslim, what do Christians believe about Isa", "I grew up Hindu, how is Jesus different") give clear, concrete context for when to invoke this tool. What is missing is any exclusion or pointer to an alternative when the asker is not from another faith, which leaves the boundary with sibling tools to inference.

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, openWorld and non-destructive, so the safety profile is covered. The description adds some behavioral nuance (verified data only 'when the church itself supplied it', plus provenance and sameAs links), but does not discuss error behavior for a missing slug or rate/auth constraints.

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 purpose, then example identifiers, then return contents; no filler sentences. Slightly long on enumerating return fields, but tight overall.

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, the return-field enumeration is partly redundant, and the safety profile is covered by annotations, so the description is sufficient for calling correctly. It would be stronger with explicit routing against find_churches_near and failure behavior for unknown slugs.

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 both params are documented with examples in the schema, so the baseline is 3. The description reiterates country/slug plus the composite id format, which is mildly additive but largely duplicates structured data.

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+resource ('One church ... by country and slug') and gives a concrete composite-id example (lb:church:united-states/saint-josephs), so an agent knows it fetches a single church record. It does not explicitly contrast itself with the closest siblings (find_churches_near, heritage_lookup, denomination_compare), though 'One church' implies a singular lookup.

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: call this when you already have a country and slug for one specific church. There is no explicit when-to-use/when-not or named alternative (e.g. use find_churches_near to discover churches first), leaving the agent to infer routing. The example values help but are not routing guidance.

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 establish readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real context: what is listed (discoverable communities), what is never listed (private family rooms), and that join mode (open or by request) and next gathering are surfaced.

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 scope and exclusion, followed by the usage trigger; no filler sentences. The opening sentence is dense with several clauses, but each carries distinct information (subtypes, join mode, gathering, family-room exclusion).

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 unnecessary, and the description covers scope, exclusions, and join semantics well. The remaining gap is pagination/limit behavior for a paged, cursor-based tool, which neither description nor limit param documents.

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 67% – the query and cursor params carry descriptions, but limit (default 10, max 20) is undocumented in both schema and description. The description adds no syntax or format guidance beyond the schema's examples ('prayer', 'study', 'Atlanta'), so the baseline 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?

States a specific resource ('discoverable communities on The Living Bread a person can join today') plus the concrete subtypes returned (prayer groups, study groups, city/interest communities), and explicitly excludes private family rooms. An agent can distinguish it from siblings like find_gatherings_near or events_this_week without opening the schema.

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?

Gives a clear use trigger: 'Use when someone wants people to pray or walk with, or asks "is there a prayer group".' It covers when to use but names no alternative tool or exclusion condition, so the routing versus nearby gathering/church tools 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.

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantive behavior beyond them: the dataset covers 53 countries, it will never silently return a US number, it is honest when a country is missing, and it falls back to the local emergency-number rule. It also sequences its output relative to pastoral content ('point to Christ only after the line is given').

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 priority directive and the trigger condition, which is exactly what an agent needs first. It is somewhat long and includes pastoral framing ('the Word and the family', 'point to Christ only after') that is not strictly selection-critical, but nothing is wasted outright.

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 single-parameter lookup with an output schema, the description is complete: trigger conditions, precedence, country handling, missing-country fallback, and output ordering are all covered. Return format is left to the output schema, which is appropriate.

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 100% and the schema already documents the country parameter (name or ISO alpha-2, ask if unknown). The description largely repeats this, though it reinforces the operational imperative to ask before returning any number, which is a slight addition over the schema text. Baseline 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?

States a specific verb+resource: returns the real emergency number and crisis line for a given country. The scope (53-country shipped dataset, never a US default) and its priority over all siblings are unmistakable, so an agent can distinguish it from tools like a_prayer_for or the_gospel at a glance.

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?

Explicitly states when to invoke it ('When a person speaks of harming themselves or someone else, or is in danger') and its precedence ('THIS COMES FIRST'). It also gives concrete trigger utterances and an alternative path when the country is unknown (ask the person first), plus the fallback general rule when a country isn't held.

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. The description adds meaningful context beyond that: the data source and licence (OpenBible.info, CC BY), that ranking reflects human reader votes and is 'a human judgement, labelled as such', the 12-result cap with strongest first, and that passages are read verbatim from stored KJV text. No contradiction with 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?

Front-loads what the tool returns before moving to usage and limits. Most sentences earn their place, though the parenthetical source/licence attribution is dense and could be trimmed without loss.

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, the description needn't explain return values, and it still covers origin, ranking basis, result cap, and a caveat that linked verses are human judgement. Nothing needed to invoke the tool correctly 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 coverage is 67%, with reference and include_text already documented in the schema. The description adds semantics the schema lacks, namely that the limit is capped at 12 and ordered 'strongest first', clarifying what the ranking and truncation mean for the result set.

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+resource: the passages most often linked to a verse by readers, sourced from OpenBible.info and ranked by reader votes. The phrase 'Scripture interprets Scripture: use it to follow a thread through the Bible' makes it distinguishable from siblings like scripture_search, verses_for, and what_the_bible_says_about without any schema inspection.

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?

Provides clear usage context ('follow a thread through the Bible') and three example user phrasings ('verses related to Romans 8:28', 'cross references for John 3:16') that map intent to tool. It does not, however, explicitly exclude or name competing siblings such as verses_for or scripture_context, so guidance is clear but not fully routed.

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, non-open-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond them: the delivery timing tied to each person's local 8am and that wording is taken verbatim from the stored KJV, which sets expectations about consistency across callers.

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?

Two sentences, both load-bearing: the first defines what is returned and to whom, the second defines when to reach for it. No filler, and the core identity is 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?

An output schema exists, so return-value detail is unnecessary here, and annotations cover the safety profile. What remains — the shared-per-day semantics, the source translation, and the invocation triggers — is all present, so an agent has everything needed 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 description coverage is 100% and the single 'date' parameter is fully documented in the schema, so the baseline of 3 applies. The description only implies a per-day scope ('a given morning') and adds no format or default semantics beyond what the schema already states.

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 precise resource and scope: 'the one verse the whole Living Bread family receives on a given morning'. That single-verse, shared-everyone framing cleanly separates it from query-oriented siblings like scripture_search, verses_for, and scripture_passage without ambiguity.

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?

Gives concrete trigger phrasings ('verse of the day', 'today's bread') and a use case (praying the same word the family is praying). It stops short of naming an alternative tool or an explicit when-not-to-use condition, so it is strong context rather than full routing guidance.

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 open-world, so the safety profile is covered. The description adds genuinely new behavioral context: the framing 'never a ranking, never an argument' tells the agent the output is neutral/charitable, and it sketches what comes back (family tree, sourced page, links). It does not mention limits or error behavior, keeping it from a 5.

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 core purpose in the first clause, then supporting detail and example queries. The theological flourish ('one Body, many rooms, Christ the head of all') is somewhat decorative, but the 'never a ranking, never an argument' clause earns its place as behavioral guidance. Mostly efficient, minor padding.

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 documentation is not required, and the annotations cover the safety profile. Given the tool's modest complexity (two string inputs), the description plus structured fields are sufficient for correct invocation. Missing only a single-tradition alternative pointer to be fully 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% — both 'a' and 'b' have clear descriptions with examples in the schema itself. The description's examples ('Catholic vs Orthodox') merely echo the schema's examples and add no new parameter semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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 action (comparing two Christian traditions side by side) and what is produced: family tree, sourced page, links, and posture. It is distinguishable from siblings like heritage_lookup because it explicitly handles two inputs compared against each other. It stops short of a 5 only because the core 'compare' verb is implied by the name rather than stated plainly.

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?

Concrete trigger questions ('what is the difference between Baptists and Methodists', 'Catholic vs Orthodox') tell the agent exactly when to reach for this tool. However, it names no alternative sibling (e.g., when to prefer heritage_lookup for a single tradition) and gives no exclusions, so it lacks the 5-level when-not guidance.

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 (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely new behavior: the data is live, results carry UTC times and city-level granularity, and online rooms are included. It stops short of stating freshness guarantees or result caps, keeping it from a 5.

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 core scope statement, then supporting detail and examples; each sentence carries information. The trailing quoted query examples are slightly redundant with the examples given usage, but they ground the tool in real phrasing.

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 documented, yet the description helpfully notes the when (UTC) and where (city level) fields. For a zero-required-param, open-world discovery tool this is nearly complete; only the limit parameter and lat/lng pairing are 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 coverage is 75% and the four parameters are largely self-describing (lat/lng paired, city as fallback when no coordinates). The description only implies location input via 'near a city' and never addresses lat/lng pairing or the limit bound, so it adds little beyond the schema — baseline 3.

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 resource (real gatherings) with a concrete scope (next seven days, near a city), and enumerates what is included (services, prayer nights, studies, meals, online rooms). It explicitly distinguishes itself from the sibling find_gatherings_near as the same live data bounded to one week, so the agent can route between them without opening schemas.

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?

Names the alternative (find_gatherings_near) and gives the selecting condition (bounded to one week / pick a day), plus three natural-language query exemplars that clarify the intended use. It does not explicitly exclude or route to gatherings_tonight, so the when-not guidance is left partly implicit.

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, 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.

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds real value by clarifying that this returns a result 'in full' (versus a search snippet) and by naming the accepted id namespaces; it omits what happens for unknown/malformed ids.

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 delivers purpose, accepted id formats, and audience with no filler. The long inline parenthetical is dense but every token is informative.

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 explanation is unnecessary, and annotations carry the safety profile. Purpose, valid id forms, and audience are all present for a one-parameter read 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 single `id` param has no documented format in the schema, so the description must compensate — and it does, enumerating the verse:/need:/church:/gathering:/community:/lb: prefixes with placeholder shapes. It stops short of saying whether other prefixes are accepted.

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 — 'Read one search result in full by its id' — and enumerates the id namespaces, which an agent can use to recognize valid inputs. It is distinguishable from the generic `search` sibling, though it never explicitly names that relationship.

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?

'Provided for connector clients' is a usage-context hint, and the id-format list implies this is the second step after a search returns an id. But there is no explicit when-to-use, when-not-to-use, or named alternative among the many siblings.

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 read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds real value beyond them: two live sources, ~120,000 entities with stable ids, city-level only granularity, distance in km, and explicit empty-result handling ('Says plainly when nothing is held near the place'). It omits pagination/limit behavior, which the annotations don't cover either.

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 purpose and source facts are front-loaded and the example queries are genuinely useful, but the closing line ('the Body of Christ is the door, and walking in is the step') is devotional flourish that does nothing for tool selection and adds length. Overall it is functional but heavier than it needs to be.

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 explanation is not required, and the description covers sources, geo granularity, result ordering and empty-result behavior adequately. It leaves a minor gap around how coordinate vs city inputs interact and what the limit cap means in practice.

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 80% and the schema documents lat/lng/city/denomination, so the baseline is 3. The description adds the useful constraint that results are city-level and distances in km, but does not clarify the lat/lng-vs-city tradeoff or explain the undocumented limit parameter, so it does not clearly exceed schema-provided meaning.

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 and resource ('Real Christian churches near a person, nearest first') and names the two backing sources, which is clear and concrete. However, it never names or contrasts the nearest siblings such as find_gatherings_near or worship_now, so an agent must infer the boundary between 'churches' and 'gatherings' itself.

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?

It gives explicit trigger conditions ('Use whenever someone wants a church, congregation or Christian community near them') plus several realistic example queries that map user phrasing to the tool. It stops short of stating when NOT to use it or which sibling to pick instead, so it lacks full exclusion guidance.

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 read-only, idempotent, open-world, non-destructive behavior, so the bar is lower. The description adds genuinely useful context not in the annotations: data provenance ("posted by real churches and believers; nothing invented") and that times are UTC, which materially affects how results are presented.

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 purpose and gathering-type list are front-loaded, but the four quoted sample questions repeat the same idea already conveyed by the trigger sentence, padding the description without adding routing value.

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, and the description covers scope, data trust, and timezone. It omits why all seven parameters are optional (no-location browsing / paging behavior), which is a minor gap for a zero-required-param search 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 86%, so the schema already documents lat, lng, city, days, limit, cursor, and online. The description adds no parameter-level meaning (e.g., lat/lng vs city preference, or that cursor pairs with next_cursor), so baseline 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 states a specific verb (find) and resource (real, upcoming Christian gatherings) and enumerates concrete gathering types, so the agent knows exactly what comes back. It does not, however, differentiate itself from close siblings such as gatherings_tonight, find_churches_near, or events_this_week, which an agent must disambiguate.

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 grounded in realistic user phrasings ("is there a Bible study near me this week") and an explicit trigger sentence ("Use when someone asks what is happening near them..."). It stops short of naming an alternative tool or a when-not condition, so routing against siblings 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.

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely useful behavioral context beyond that: only public gatherings are returned, and gatherings with private addresses are withheld from city listings entirely, plus it promises honesty when nothing is listed.

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 core scope statement is front-loaded and clear, but the middle section is padded with quoted user queries and a rhetorical closing ("with the door to every gathering") that adds tone rather than information. Efficient enough but not tight.

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, and it covers scope, privacy filtering, and empty-result behavior. What remains missing is explicit routing against the near-identical sibling find_gatherings_near.

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%, so city, hours, and country are already documented with types, ranges, and defaults. The description only restates the 12-hour default, adding no syntax or semantics beyond the schema. Baseline 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?

States a specific verb+resource+scope: public Christian gatherings starting in the next 12 hours in a given city, with concrete event types enumerated. It does not, however, name or distinguish itself from the close sibling find_gatherings_near or events_this_week, so the agent must infer the boundary.

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 embedded example queries ("is there a prayer meeting tonight in Atlanta", "Bible study tonight near me") give clear usage context for the tonight-window case. No explicit when-not or alternative-tool routing is given, so it falls short of a 5.

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, and destructiveHint=false, so the safety profile is covered. The description adds that it is a shared, one-voice-at-a-time stream — useful context. However, 'a person can... add their own' implies a write capability that the read-only annotation and zero-parameter schema do not support, which muddies rather than clarifies 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?

Only two sentences, but the first is a long, metaphor-laden clause ('The door where believers from many nations pray out loud over the whole Living Bread family, one voice at a time...') that spends words on imagery rather than function. The actionable guidance is relegated to the second sentence.

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 a rich annotation set and an existing output schema, return values and the safety profile are already covered, so the description only needs to convey purpose and usage — which it does. The unresolved 'add their own' claim leaves a small gap about whether the tool has any interactive effect.

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?

Zero parameters, so the baseline is 4. There are no parameter semantics to clarify and the description appropriately does not invent any. Schema coverage is trivially 100%.

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 conveys a specific activity: hearing believers from many nations pray aloud over the Living Bread family, one voice at a time, with the option to listen and contribute. It is metaphor-heavy ('The door where...') but still identifiable as a shared prayer-listening experience, and the 'hear' verb matches the name. It doesn't crisply separate itself from sibling prayer tools like pray_for_someone or a_prayer_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?

Explicitly names triggering situations: 'when someone wants to hear others pray, feels alone, or asks what the family is praying.' That is clear when-to-use guidance. It does not, however, name an alternative tool or state when NOT to use it.

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, open-world, non-destructive, so the safety profile is covered. The description adds real value beyond that: it discloses the return shape (stable lb: id, page, sameAs links, provenance, related ids) and signals partial data with 'where known' for genealogy edges.

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 resource and scope, then examples, then return shape, then the usage directive. Dense but every sentence carries information; only slight redundancy between the enumerated kinds and the enum.

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?

Covers entity kinds, accepted name formats, and a summary of returns; with an output schema present, return details need not be exhaustive. Complete enough to call correctly, with only minor gaps around disambiguating name collisions.

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 only 50% (kind has no description, name is just 'A name or slug.'). The description partially compensates by giving concrete name examples ('Methodism', 'Augustine of Hippo', 'Bethlehem') and restating the five kinds, clarifying accepted input forms. It does not fully document the kind parameter's semantics, so a 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+resource ('one sourced entity from the Christian Knowledge API') and enumerates the five exact entity kinds, which maps directly to the kind enum. An agent can distinguish this single-entity lookup from siblings like denomination_compare or saint_of_the_day without opening a schema.

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?

Gives an explicit directive: 'Use instead of memory for facts about these.' That is clear context for when to reach for this tool. It does not, however, name alternative sibling tools or exclusion conditions (e.g., when to prefer denomination_compare), so it stops short of the 5 bar.

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, openWorld, non-destructive, so the safety profile is covered. The description adds non-obvious behavior: content is read at call time from the house's own page, nothing is generated, the KJV Scripture is re-read from stored text, and it will report honestly when no page matches. Response format is not described, but an output schema exists.

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 sourcing and honesty guarantees are front-loaded and useful, but the description carries promotional padding ("why it still moves us", "Every hymn here sings of Jesus Christ; the worship room is where the family sings them together") that does not help selection or invocation.

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 single-parameter read tool with rich annotations and an output schema, the description covers sourcing, provenance, and the no-match case, which is the main uncertainty an agent would have. It does not need to explain return values, so remaining gaps are minor.

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 title parameter is already documented as accepting a title or a line of it, with examples. The description merely echoes those examples, adding no new syntax, matching rules, or fallback behavior beyond what the schema states.

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 specific resource (a public-domain hymn) and enumerates exactly what is returned: author and date, backstory, lyrics, underlying Scripture, and significance. This is clearly distinguishable from siblings like worship_now, prayers, or saint_of_the_day without opening any schema.

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?

It gives concrete triggering phrasings ("the story of Amazing Grace", "words of It Is Well With My Soul", "a hymn about trusting Jesus") so an agent can match user intent, and it points to the worship room for the communal-singing use case. It stops short of explicitly naming a sibling to use instead or stating when not to call it.

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?

Goes well beyond the annotations (readOnly/openWorld/idempotent/non-destructive) by disclosing result cardinality (at most five), the freshness labeling scheme with the explicit warning that results are 'never available now from an old time', the single link behavior, the empty-result fallback, and that scripture is read from stored text with an evidence label.

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 output shape are front-loaded, and the journey list plus example queries are information-dense rather than padded. The example-query sentence is somewhat long and partly restates the journey list, keeping it short of a 5.

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, yet the description still supplies the essentials an agent needs to interpret and trust results: the cap, freshness semantics, the evidence label on scripture, and the empty-result behavior. Nothing material is left unspecified for a read-only aggregate journey 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 coverage is 100%, so the baseline is 3, but the description adds real meaning by mapping each journey enum value to the parameter it consumes and marking place as optional for two of them ('someone_to_pray_with_tonight (place optional)', 'serve_this_weekend (place or country)'). That is genuinely useful routing information not present 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?

Opens with a specific verb and resource ('Run one of six journeys end to end and get at most five real, well-matched next steps') and enumerates the six journeys by name. This clearly separates it from siblings like find_churches_near or where_can_i_serve_publicly, which cover only one journey each.

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 maps each journey to the user need it serves and gives concrete example phrasings ('find me a church community in Leeds', 'a prayer group in Spanish'), which routes the agent effectively. It does not, however, explicitly say when to prefer a narrower sibling tool over this aggregate one.

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 establish readOnly, idempotent, non-destructive, non-open-world behavior, so the safety profile is covered. The description adds genuinely new behavioral facts: results are counts only, privacy-safe, and never expose a name. It does not describe pagination or how the limit interacts with the returned rows, but for a read-only aggregation tool this is solid supplementary context.

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 core fact and the filter are front-loaded, which is good, but the opening sentence is an overloaded run-on with a nested parenthetical, and the 'so a person can see they would not be alone where they live' framing plus the trailing example questions largely restate the same idea. Tightening would lose no information.

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 need not be explained, and annotations carry the safety profile. What remains thin is the unspecified 'limit' parameter and the absence of any routing hint toward sibling tools for adjacent needs, but an agent has enough to invoke this 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 50%: 'place' is documented in the schema as a city or country word, which the description echoes, while 'limit' has no description anywhere. The description compensates for the filter parameter but leaves the 1-50 result cap (default 12) semantically unexplained, so it neither adds much beyond the schema nor fills the coverage gap.

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 concrete resource and scope: privacy-safe counts of believers by city and country, city-level, counts only, never a name. That is far more than a restatement of the name. It does not, however, explicitly contrast itself with plausible siblings such as find_churches_near or needs_near, so differentiation is left implicit.

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 example questions ('are there believers on Living Bread in Nairobi', 'how many are in Brazil', 'where is the family') make the intended use case concrete and easy to match against a user request. There is no explicit when-not guidance or pointer to an alternative tool for the related 'find people/churches near me' need.

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/openWorld/non-destructive, so the safety bar is covered. The description adds genuinely new behavior: only public data is returned, and non-public objects answer as not found rather than erroring — a useful disclosure about edge-case outcomes.

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 core verb and the URN forms up top, with edge-case behavior and return contents trailing. Dense but every clause carries information; the long URN enumeration is the one stretch that reads as list-heavy.

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 annotations covering the safety profile, the description need not detail return values — yet it still summarizes them (object, protocol kind, JSON Schema) and covers the private-object edge case. Nothing an agent needs to call it correctly 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 coverage is 100% so the single param is documented, but the description goes beyond the schema's single example by listing all valid URN prefixes (gathering, church, ministry, community, need, service, testimony, prayer, profile), which meaningfully expands the agent's understanding of acceptable inputs.

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 (Resolve) plus the exact resource (a Living Bread lb: URN) and the namespace it maps into (Kingdom Protocol v0.1), then enumerates every supported URN kind. An agent can distinguish this URN resolver from the many content siblings without opening a schema.

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?

It clarifies the input domain and the fallback for unrecognized lb: URNs ('resolved through the public Kingdom Graph'), which implies usage context, but it never names an alternative tool or states when NOT to reach for this one. Guidance is inferable rather than explicit.

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 carry readOnly/idempotent/openWorld safety, so the bar is lower, yet the description adds real behavioral context: content is read at call time from living-bread.org, words are the house's, Scripture is re-read from stored KJV text, nothing is generated, and it is honest when no page matches (a no-result contract). That last point is valuable negative-path disclosure.

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 source/verifiability sentences are front-loaded and earn their place, but the closing line ('Each sign points to who Jesus is: God come near, with power and mercy') restates the earlier 'what it shows about who He is' and adds rhetorical padding rather than information.

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, and the description still covers provenance, no-generation guarantees, and the no-match case. It is nearly complete for a single-parameter lookup; only sibling disambiguation 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 coverage is 100% and the single 'name' property already documents accepted miracle phrasings with examples, so the schema does the heavy lifting. The description only echoes those example queries rather than adding format or matching rules, so the baseline 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 states a specific resource (one of the miracles of Jesus) and enumerates what is returned: what happened, where it is written, what it shows about who He is. It does not, however, differentiate itself from close siblings such as parable, teaching_of_jesus, or scripture_context, which an agent must disambiguate on its own.

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?

Sample user phrasings ("did Jesus really walk on water", "the feeding of the five thousand") imply when the tool is a good fit, which is genuine trigger guidance. But there is no explicit when-not and no alternative named against the many parallel sibling tools, leaving routing implicit.

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 read-only, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: content is fetched live from the house's own page at call time, Scripture is re-read from stored King James text, nothing is generated, and it is 'honest when no page matches' (graceful failure).

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 is front-loaded in the first clause and the middle sentence carries the highest-value operational facts (source, non-generation, no-match behavior). The 17-name parenthetical is longer than needed and the closing theological aside about God changing names is decorative rather than decision-relevant, costing a point.

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, yet the description still characterizes what comes back (meaning, origin, Bible story, verse). For a single-parameter read-only lookup it gives an agent everything needed 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 description coverage is 100% and the single 'name' parameter already carries its own examples ('Elijah', 'Hannah', 'Caleb') that the description merely repeats. The description adds no format or constraint detail beyond the schema, so the baseline 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?

States a specific verb+resource (the meaning, origin and Bible story of a biblical name) and scopes it precisely ('about two hundred held'), with concrete examples. An agent can distinguish it from siblings like what_the_bible_says_about or verses_for without opening any schema.

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 embedded user phrasings ('what does the name Elijah mean', 'is Caleb a biblical name') give clear context for when to invoke it. However, no alternative sibling is named and no explicit when-not condition is stated, so it stops short of full routing guidance.

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 read-only, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely non-structured context: results are limited to verified partners, locations are approximate and never home addresses, and remote/fundable needs are surfaced when no local need exists.

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 first sentence front-loads the complete scope and privacy constraint in one dense clause, followed by usage examples and the empty-result behavior. The closing Proverbs quotation is decorative but brief and consistent with the product voice.

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, the description need not explain return values, and it covers the remaining agent-facing gaps: verification status of posters, location privacy, geographic matching inputs, and honest empty-state behavior. Nothing needed to call it correctly 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 80%, so lat/lng/city/country/limit are largely documented in the schema itself. The description implies place-based lookup but adds no syntax, pairing rules, or precedence guidance (e.g., lat/lng vs city vs country) beyond what the schema already says, so the baseline 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?

States a specific verb and resource ('open, verified needs on The Living Bread Serve network that the app shows publicly') and enumerates the returned fields (what is needed, local/remote/funding, the partner). An agent can distinguish this from siblings like where_can_i_serve_publicly or find_churches_near without opening the schema.

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 quoted user questions ('how can I help in my city', 'who needs groceries near Kigali', 'something I can fund') give concrete when-to-use contexts, and it explicitly states the fallback when nothing is near. It never names an alternative sibling tool, so it stops short of a 5.

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 readOnly, idempotent, openWorld and non-destructive behavior, so the bar is lower; the description adds genuinely useful context beyond them — content is read at call time from the house's own page, Scripture is re-read from stored King James text, and nothing is generated. It also promises honesty when no page matches, which sets expectations for misses.

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 first sentence and the example queries are well front-loaded, but the trailing devotional sentence ('Jesus told these so that the heart of God would be seen; He is the Father who runs to meet us') adds no selection or invocation value and bloats the definition.

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 single-parameter lookup with an output schema and full annotation coverage, the description supplies what matters: content source, the no-generation guarantee, and fallback behavior on no match. Return-value detail is correctly left to the output schema.

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 'name' parameter, and the description's example values ('prodigal son', 'good samaritan') essentially duplicate what the schema already documents. Baseline 3 is appropriate since the schema carries the parameter semantics.

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 resource (one of the parables of Jesus) and enumerates what it returns: the story in short, its Gospel location, its meaning, and a link to the full text. This is clearly distinct from generic siblings like scripture_passage or teaching_of_jesus, though it never names an alternative 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?

Usage context is conveyed through concrete example user phrasings ('tell me the parable of the prodigal son', 'what does the good samaritan mean'), which tells an agent exactly what kind of request belongs here. It stops short of stating when NOT to use it or naming a sibling to prefer instead.

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, openWorld, non-destructive, so safety needs no restating. The description adds genuinely non-obvious behavior: only public prayers, location is blurred to the approximate cell centre and 'never the exact spot', and an honest empty result when nothing is nearby. That privacy and completeness behavior is exactly what annotations cannot convey.

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 resource and its scope, then the field list, then motivating queries. The sentence is dense and slightly run-on, but each clause (privacy, kind, honesty) carries information an agent cannot get from the schema.

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 not spelling out return values would be acceptable, yet the description still characterizes them alongside privacy behavior and the zero-result case. Missing only default/radius behavior for the two undocumented numeric parameters, which is minor for a read-only lookup.

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 60%: lat/lng/city carry descriptions, while limit and radius_km have none. The description gestures at place types (street, hospital, school, church, town) which map to the city/coordinate inputs, but adds nothing about limit or radius semantics, so it neither compensates for the gap nor is required to.

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 specific resource (public prayers left by real believers at places) and enumerates exactly what comes back: cell centre, kind, words, Scripture, author, prayer count. It is distinguishable from siblings like pray_for_someone and find_churches_near. The retrieval verb is only implied by 'Prayers left near' rather than stated, which keeps it just short of 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?

Concrete example queries ('has anyone prayed near this hospital', 'prayers left in my town', 'pray where others have prayed') make the intended use case easy to recognize. No sibling is named as an alternative and no exclusion is given, so it is clear context without explicit routing.

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?

The description's core action is writing/recording a prayer that someone else hears and can respond to ('record a prayer in your own voice... they hear it, and may pray one back'), i.e. a state-changing, effect-bearing operation. The annotations declare readOnlyHint=true and idempotentHint=true, which flatly contradicts a tool that records and delivers content to another person. (Note the tension is partly explained by the schema having only a name parameter, but the description as written asserts a write, so the pair is inconsistent.)

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 is front-loaded, which is good, but the prose is loose: 'The exact door to' is marketing filler and 'the honest state of recording' is opaque to an agent. Four sentence-fragments for a one-parameter tool contain more color than usable signal.

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 low-complexity, single-parameter tool with a full output schema and annotations, the description covers purpose, usage scenarios, audience, and return shape, which is largely sufficient. However, the ambiguity between 'records a prayer' and the read-only annotations means an agent cannot reliably predict the tool's actual side effects, leaving a real 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 coverage is 100% and there is a single optional parameter, so the schema already carries the load. The description adds only the soft nuance 'with their name in it' / 'by name', which is essentially a restatement of the parameter's own description; 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?

The description names a concrete verb+resource (record/pray for a person by name) and frames itself as the entry point ('The exact door to pray for a person on The Living Bread'). It is clear about what it does, but it never distinguishes itself from close siblings such as a_prayer_for, hear_the_kingdom_pray, or prayers_left_near, leaving the agent to guess which prayer tool applies.

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?

It gives explicit when-to-use triggers: 'Use when someone wants to pray for a friend, a parent, a stranger, or asks how to send a prayer', and clarifies scope ('Works for a believer on Living Bread or for anyone, by a private link'). There is no when-not guidance and no named alternative, so it stops short of a 5.

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), so the bar is lower. The description adds real context beyond them: the catalogue is the app's own (reinforcing closed-world), plans are returned 'with day one read from the stored text', and each day has a defined shape. It stops short of richer behavioral detail.

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 content is front-loaded with the resource name, but the whole description is one run-on, colon-chained sentence embedding a 15-item plan list plus four sample queries. Much of that list is useful for semantic matching, but the packaging is dense and harder to parse than discrete sentences would be.

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 values need no explanation, and both parameters are fully described in the schema. Purpose, both invocation modes, and trigger examples are covered; only explicit sibling routing is missing, which keeps it below 5.

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%, so both parameters are already documented; baseline is 3. The description reinforces that 'plan' accepts a need as well as a name and implies day defaults to 1, but adds little syntax or matching 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 description states a specific resource (The Living Bread's reading-plan catalogue) and what it returns (each day's title, reference, short word and one step), and the app-catalogue framing scopes it. It never names a sibling tool to differentiate from, so it falls short of the 5 bar for explicit sibling differentiation.

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?

It clearly describes the two invocation modes ('with a name or a need it returns that plan ... alone it lists them') and supplies realistic trigger phrasings ("a reading plan for anxiety", "how do I start reading the Bible"). It gives no explicit when-not guidance or named alternatives among the many sibling tools.

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 safety (readOnly, idempotent, non-destructive, openWorld), so the description's added value is provenance and freshness: sourced from Wikidata and the calendar, read live at call time, and 'nothing invented'. That discloses a real behavioral trait beyond the annotations, though it says nothing about failure modes if the page is unreachable.

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-loads the purpose in the first clause and is generally efficient, with the example queries earning their place by clarifying intent. It is slightly padded by enumerating return content ('what a feast day is, and the cloud of witnesses') that the output schema already carries.

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 annotations, a full schema, and an output schema, the definition needs little more; it supplies provenance and live-fetch behavior, which is the right kind of gap-filling. It stops short of noting what happens on a date with no commemorations or when the source page fails.

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 100% and the single date parameter is fully documented in the schema, including the 'October 4' format. The description only reinforces the UTC default already implied by the schema, adding no syntax or format meaning beyond it, so the baseline 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?

States a specific verb-and-resource: who the church remembers on a given day, drawn from the house's Saint of the Day pages. It is clearly distinct from siblings such as daily_bread, a_prayer_for, or heritage_lookup without needing to open any schema.

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?

Gives clear usage context with real user phrasings ('whose feast day is it today', 'saint of the day for October 4') and states the default (today, UTC). It does not, however, name a sibling alternative or say when not to use this tool versus daily_bread or heritage_lookup.

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, and non-destructive, so the safety profile is covered. The description adds real behavior beyond that: the read is verbatim KJV from a stored corpus, `around` defaults to 3 and caps at 10, and it crosses chapter boundaries within the same book. It doesn't discuss auth or rate limits, but for a read-only lookup that 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?

Front-loads the core purpose in the first sentence, then layers in default/limit behavior and sample queries. The example-question list is slightly long but earns its place by anchoring usage; nothing is redundant.

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, yet the description still succinctly previews the return shape (passage, surrounding verses, evidence label with translation, canon, corpus version, hashes). Combined with annotations and full schema coverage, an agent has everything needed 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 100%, so the baseline is 3, but the description adds meaning the schema lacks: that `around` verses are read both before and after and that they cross into adjacent chapters of the same book. The `reference` parameter is illustrated with example formats, reinforcing 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?

States a specific verb (read) and resource (a verse or short passage with surrounding verses), plus the distinguishing scope: verbatim KJV with surrounding context so a verse is never quoted out of place. This separates it from siblings like scripture_passage or scripture_search even without naming them.

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?

Gives explicit user-question triggers ("what is the context of Jeremiah 29:11", "read Philippians 4:13 in context"), which clearly signals when to reach for this tool. It stops short of naming alternative siblings or stating when NOT to use it, so it is strong context without explicit 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 cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower, and the description still adds real behavioral context: text is returned verbatim from a stored corpus, KJV is complete while WEB is only partially held and silently falls back to KJV with notification. It does not describe error behaviour for unrecognised references, which is the one notable gap.

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 and well organised: purpose, then usage, then input examples, then the anti-hallucination constraint. The closing sentence ("The Word points to Christ, who is its subject (John 5:39)") is devotional flourish that adds no operational value and is the one piece of text that does not earn 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 formatting need not be explained, and the description covers corpus provenance, translation behaviour, accepted reference forms and the hallucination guard. Given only two params and full schema coverage, the definition is essentially complete; failure modes for invalid references are the only unaddressed area.

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%, so 3 is the baseline, and the description adds legitimate meaning on top: reference accepts reader-style and even topical formulations ("the verse about love being patient"), and the translation field's coverage limits and fallback are restated in human terms. It stops short of clarifying malformed or out-of-range reference handling.

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 specific verb and resource ("Read a Bible passage verbatim from a stored text") and states the exact scope (verse, verse range, whole chapter) with worked examples. An agent can distinguish this from siblings like scripture_search or scripture_context without opening any schema.

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?

It gives one very strong routing rule, "Never quote Scripture from memory when this tool is available," plus the range of inputs to use it for (verse, range, chapter) and sample user phrasings. What is missing is explicit signposting away from near-neighbours such as scripture_search or verses_for, so the agent must infer the boundary rather than being told it.

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 (readOnly, idempotent, non-destructive, non-open-world). The description adds genuinely non-structured behavior: results are bounded to at most 20 per page with next_cursor pagination, matches are in canonical order, and whole-word matching is the default unless the query is quoted.

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 core operation and dataset size, then the matching rules, then optional filters, then pagination. The three example questions are slightly padded but earn their place by mapping natural user phrasing onto the query parameter.

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, the description need not explain return values, and it still covers the things an agent needs: matching semantics, KJV wording caveat, scope filters, and the 20-per-page/next_cursor bound. Nothing material is left for the agent to guess.

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 high (83%), so the baseline is 3; the description still adds value by spelling out the conjunction semantics (ALL words must appear), the phrase-quoting syntax, the whole-word default, and the book/Testament narrowing options. It does not enumerate the limit/cursor mechanics beyond the paging sentence.

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 (verses of the stored KJV, quantified as 31102 verses / 66 books) plus the match semantics (ALL given words, canonical order, paged). An agent can distinguish this from siblings like scripture_passage or scripture_context, which retrieve a known passage rather than search by words.

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?

Gives concrete usage context via example user phrasings and a critical precondition (it searches KJV wording, so modern terms may not appear – search "charity" as well as "love"). It never explicitly names an alternative sibling or a when-not-to-use condition, so it stops short of a 5.

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 and destructiveHint=false, so safety is covered. The description adds real value beyond them: results come back as ids that a separate fetch call expands into full reads, which tells the agent this is a two-step retrieval flow. 'Provided for connector clients' hints at intended audience but is vague.

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?

Three short sentences, front-loaded with the search scope followed by the return mechanism. Little waste, though the trailing 'Provided for connector clients' is vague and does not earn much space.

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, and the tool has only one required parameter. However, for a broad search tool in a suite crowded with overlapping search siblings, the absence of any routing guidance leaves a meaningful gap for correct tool selection.

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% for the single query parameter; the schema only constrains it to a 1-300 character string. The description partially compensates by implying accepted query kinds (a need, a Bible reference, an entity name), which is useful semantics, but says nothing about matching behavior, ranking, or how references should be formatted.

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 (Search) and enumerates the resource space it spans: Scripture, Bible references, churches, gatherings, communities and sourced entities. That is a clear purpose, but it offers no differentiation from the many focused siblings (scripture_search, find_churches_near, communities_to_join), so it falls short of the 5 bar.

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 and no mention of alternatives, despite roughly 45 siblings, several of which (scripture_search, find_gatherings_near, find_churches_near) overlap directly with this tool's stated scope. The agent is left to guess whether to use the broad search or a narrower sibling.

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 establish readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context that annotations cannot express: output is auth-dependent, returning only 'the door' on the public endpoint versus the full live hall when connected as /me. The metaphor is opaque, but the disclosure itself is real and useful.

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 is front-loaded in the first clause, but the second sentence ('the hall is seen from inside the family...') is metaphorical and takes effort to parse, and the closing sentence is a list of sample queries rather than tight specification. Some of this earns its place, some is stylistic padding.

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 values need no explanation, and with zero parameters there is little schema surface to cover. The description supplies purpose plus the auth-dependent behavior nuance, which is the main thing an agent could get wrong. It is close to complete for a low-complexity read 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?

The tool takes zero parameters, so the schema carries no semantics to document and the baseline is 4. The description correctly avoids inventing parameters and instead describes what the caller receives.

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+resource set: it returns live tables with host first name, gathering theme, seats, present attendees, and the Scripture on the table. That is concrete enough for an agent to know what comes back, but it never names or contrasts the obvious siblings (gatherings_tonight, events_this_week, communities_to_join), so the differentiation work is left to inference.

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 only through example user phrasings ('is anyone gathered right now', 'where can I sit with believers tonight', 'a table about the Psalms'), which implies the trigger context well. There is no explicit when-not guidance and no alternative tool is named for near-miss cases like scheduled events or joining a community.

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 readOnly, idempotent, openWorld and non-destructive. The description adds genuine beyond-annotation context: content is read at call time from the house's own page, Scripture is re-read from the stored King James text, nothing is generated, and it is 'honest when no page matches'. That sourcing and no-generation disclosure is exactly the extra value expected.

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 topic scope are front-loaded, but the text repeats itself — 'His own words from the stored Gospels', 'read from the stored text', and 'These are the words of Jesus Christ, God and Lord, read from the stored text' say substantially the same thing three times. It is longer than the information content requires.

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 full annotation coverage, the description needn't explain return values, and it does supply sourcing, non-generation, and no-match behavior. For a single-parameter lookup tool this is close to complete, with only sibling differentiation 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 there is a single parameter already documented with the same topic examples the description lists. The description adds no syntax, casing, or matching behavior beyond what the schema provides, so the baseline 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?

States a specific verb and resource — 'What Jesus Himself said about love, forgiveness, prayer...' — sourced from the house's Teachings of Jesus pages. It clearly frames the tool as topic-scoped sayings of Jesus. However, it never names its nearest siblings (what_the_bible_says_about, scripture_search, verses_for), so the agent must infer the boundary itself.

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 sample user questions ('what did Jesus say about worry') and the topic list, which signals when the tool fits. There is no explicit when-not or alternative routing, e.g. no statement that broader Bible topics belong to what_the_bible_says_about. Implied-only guidance lands at 3.

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 genuine privacy trait beyond that: excerpts are opt-in sharing and "never a name they did not choose to show" — useful for an agent handling sensitive personal narratives.

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?

Reasonably front-loaded, but the parenthetical enumerating returned fields is largely redundant since an output schema exists, and the sentence is dense with nested clauses. It reads more like marketing copy than invocation 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?

With an output schema present, return values need not be explained, and the privacy/opt-in nuance plus matching scope give the agent enough to call it correctly. Minor gaps remain around no-match behavior and the `limit` parameter.

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 50%: `word` is documented, `limit` is not. The description reinforces that `word` is matched against excerpt text ("a word to look for in the excerpts") but adds nothing about `limit` semantics, default 8, or whether omitting `word` returns everything. 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 resource (testimonies) and what it retrieves, plus the fields returned via `get_testimony_wall` (excerpt, journey word, city). It is clearly distinguishable from generic search tools, though it does not name a sibling tool to contrast against.

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 quoted user phrasings ("has anyone found faith after addiction", "someone who came back after years away") give concrete intent cues for when to reach for this tool rather than scripture or devotional siblings. However, it names no alternative tool and gives no when-not-to-use condition.

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 (readOnly, non-destructive, idempotent, closed-world), so the bar is lower. The description still adds real behavioral context: verses come only from the stored King James text and "nothing is composed," plus it discloses the shape of the outcome ("ends with the door where a person says yes").

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 core content and source, then the example questions. The semicolon-chained gospel summary is dense but each clause carries meaning; the quoted example queries are slightly padded but serve retrieval matching.

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 zero inputs, the description needn't explain returns, and it covers sourcing, content, and the invitation ending. It is essentially complete for calling the tool, with the only gap being no explicit boundary against sibling 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?

The tool takes zero parameters, which is the baseline-4 case. There is no parameter behavior to clarify and the description correctly spends no words on inputs.

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 resource — the gospel presentation as told by The Living Bread — and enumerates its actual content (creation, sin, Jesus' death and resurrection, gift by faith). It is clearly distinguishable in substance from generic siblings, though it never names a sibling or explicitly routes against near-neighbors like ask_living_bread, belief, or journey_next_steps.

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?

It gives concrete trigger phrases ("what is the gospel", "how do I become a Christian", "is Jesus God"), which gives an agent a clear sense of when to invoke it. It lacks any when-not guidance or explicit mention of the overlapping siblings, so it stops short of a 5.

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 and destructiveHint=false, covering the safety profile. The description adds useful context with 'read from the house's pages at call time', implying live/fresh data, but says nothing about result volume, pagination, or coverage limits.

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 purpose is front-loaded and the example queries are valuable, but the parenthetical 'thousands of campuses, churches near campus, students, a path to follow Jesus' is promotional filler that dilutes the operative information. Overall readable but not tight.

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 carry the safety profile. With a single fully-documented required parameter, the description supplies everything an agent needs to call it, missing only sibling differentiation.

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 parameter's schema already states 'A country, a US state, or a city.' The description merely restates this, adding no format hints (e.g., spelling, abbreviations, city disambiguation) 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 description names a specific resource — 'University Kingdom Network pages: Christian community at universities by country and region' — with a clear retrieval scope. It is distinguishable from generic siblings, though 'churches near campus' overlaps with find_churches_near and find_gatherings_near without acknowledging the difference.

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 only implied: 'Pass a country, a US state or a city' plus example user questions ('Christian groups at universities in Japan') show the intended context. There is no explicit when-to-use guidance, no exclusions, and no named alternatives such as find_churches_near or church for the churches-near-campus case.

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. The description adds genuinely useful context beyond that: verses come verbatim from a stored KJV, a one-line reflection is appended, and a page of named prayer is included, which tells the agent the output is devotional content rather than raw search hits.

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 core capability and then the invocation guidance, with no filler sentences. The long enumeration of needs and the closing line about Christ are slightly expansive for a tool description, but each still carries selection-relevant meaning.

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, the description needn't detail return structure, and it still usefully characterizes the content. Two parameters are documented and the invocation pattern is clear, leaving only sibling disambiguation as an unaddressed 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%, so the baseline is 3. The description goes beyond the schema's terse 'need or feeling' by giving example values in natural phrasing ("I'm scared about surgery", "my mother died") and stressing the person's own words, which materially shapes how the agent should populate the field.

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 and resource: it returns KJV verses plus a reflection for a given need or feeling, with concrete examples (anxiety, grief, loneliness). It does not explicitly distinguish itself from close siblings like scripture_search or what_the_bible_says_about, so an agent must infer the boundary from the emotional/thematic framing 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?

It clearly tells the agent how to invoke it, quoting the kinds of user phrasings that should route here ("a verse for anxiety", "scripture for my friend who lost her dad") and instructing that the need be passed in the person's own words. There is no explicit when-not guidance or named alternative tool, which keeps it short of a 5.

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, openWorld, and non-destructive, so the safety profile is covered. The description adds meaningful provenance and fallback behavior beyond that: content is read at call time from a specific page, the prose is the house's, Scripture is re-read from stored KJV text, nothing is generated, and it is "honest when no page matches" — useful behavioral context.

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?

It is front-loaded correctly (purpose first, provenance and fallback after), but the prose is long and includes example questions and a closing theological aside ("All Scripture testifies of Christ (John 5:39)") that does not help an agent select or invoke the tool.

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 spelled out, and the description supplies scope, provenance, and empty-match behavior. It is complete enough to call correctly, with the only gap being the lack of sibling comparisons.

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 100% for the single 'topic' parameter, so the baseline is 3. The description adds scope ('about three hundred topics') and a list of examples that illustrate acceptable values, but adds no syntax or format 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?

States a specific verb and resource: it returns Bible verses on one of ~300 topics, each with a plain-language meaning, drawn from the house's own pages. The topic-question framing ("what does the Bible say about shame") makes it clearly distinct from raw-search siblings like scripture_search or verses_for without opening either schema.

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 by the example user questions and the topic-based framing, which gives decent contextual signals for when this tool fits. However, it never explicitly contrasts itself with alternatives like verses_for, scripture_search, or scripture_context, nor states when-not to use it, so the routing guidance 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, so the safety profile is covered. The description adds genuine behavioral context beyond that: strict public-only output ('never coordinates, never a contact') and the promise of an honest empty result ('Honest when nothing is listed'), which preempts fabrication.

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 core purpose is front-loaded, which is good, but the description is a single long run-on sentence chained with colons and em-dashes. It conveys the right content but is dense enough that an agent must parse several clauses to extract the triggers and the privacy guarantee.

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 values need no explanation, and the description still covers privacy boundaries, trigger intents, and empty-result behavior. It leaves only minor gaps such as how the filters combine and how large result sets are returned.

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%, so the three filters are already self-documented, which sets the baseline at 3. The description mentions city, country and in-person/remote as returned attributes rather than as filter syntax, so it adds little semantic meaning 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?

States a specific resource (verified, publicly listed needs asking for people) and the fields returned (what, city, country, in-person/remote, ministry). It distinguishes itself from general church/gathering tools via the 'serve' framing, but never names the closest sibling (needs_near) to disambiguate.

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?

Gives concrete user-intent triggers ('where can I volunteer', 'where can I serve this Saturday', 'something I can help with remotely'), which clearly tells the agent when to select this tool. However it offers no when-not guidance and does not route to alternatives such as needs_near.

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 (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.