BibleMCP

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 needs no restating. The only behavioral detail added is the default translation pair (KJV and WEB), which the input schema already states in the translations parameter description, so the description contributes little beyond structured data.

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, front-loaded with the core action before the usage triggers. No filler, hedging, or redundant restatement of the tool name.

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 and annotations are rich, so return values and safety need no explanation here. The description covers purpose, defaults, and usage triggers adequately; a pointer to the list_translations sibling for valid translation codes would close the last gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters are documented in the schema, including accepted reference formats and example translation codes. The description's mention of defaults merely repeats the schema rather than adding syntax, constraints, or edge-case 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?

States a specific verb and resource ('Show one Bible passage side by side in several translations') and the scope of what is returned. The phrase 'side by side in several translations' distinguishes it from the single-translation sibling get_passage without needing to name it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives three concrete triggering scenarios: asking how versions differ, wanting a verse in one version next to another, or comparing Catholic/Jewish/Protestant renderings. It stops short of explicit exclusions (e.g. 'use get_passage for a single translation'), so routing is clear but not fully disambiguated.

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 annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the payload is compact and omits linked verse text, which tells the agent to expect a lightweight result. It does not describe ordering or result limits, but the output schema carries the return shape.

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, zero filler, with the core behavior front-loaded and the sibling routing placed after it. Every clause carries selection-relevant 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?

With one required parameter, an output schema, and full annotations, the description covers what the agent needs to select and call it. The one residual gap is that it does not say whether ranges or whole chapters (allowed by the schema) behave differently from a single verse.

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 reference parameter is fully documented in the schema, including accepted formats and abbreviations, so the baseline is 3. The description adds nothing beyond that and actually says 'one verse' while the schema permits ranges and chapters, leaving ambiguity about whether those inputs are supported here.

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 and shape: a compact list of Bible references cross-linked to one verse, explicitly without their text. It also implicitly distinguishes itself from related_passages, so an agent can tell the two apart 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?

It gives an explicit when-to-use condition ('when you only need references to follow up') and names the alternative (related_passages) along with the tradeoff that it returns more detail. Nothing about tool selection 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, and closed-world, so the safety profile is covered. The description adds genuinely new context: results are citation snippets rather than full texts, and an empty result set is not evidence of absence. It does not describe ranking or ordering of results, which would be the next useful 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?

Three tight sentences: capability first, then when to use, then the follow-up tool and the negative-result caveat. Every sentence carries distinct information and nothing is repeated 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?

With an output schema present and full parameter documentation, the description only needs to cover purpose, selection criteria, and follow-up behavior — all of which it does, including the important caveat about interpreting empty results.

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 'era', 'limit', 'author', and 'reference' are already fully documented in the schema. The description adds nothing about filter behavior or how era interacts with author, so the baseline of 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 ('Find what ... writers said about a specific Bible verse') plus the return shape ('passages that cite it, with snippets'). It also implicitly separates itself from search_writings and get_writing by framing itself as verse-indexed retrieval rather than full-text reading.

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 triggering conditions ('how a verse was interpreted', 'what the early church taught', 'commentary on it') and names the alternative for the follow-up step ('Read a passage in full with get_writing'). It even addresses the negative case: 'No result is not proof a writer never discussed 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 safety (readOnly, idempotent, non-destructive, closed-world), so the description correctly spends its words elsewhere and adds a valuable expectation-setting line: it returns sources and gaps rather than an answer, so the agent must weigh them. It says nothing about how many sources come back or how gaps appear, but the presence of an output schema lowers that burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The routing instruction and the return-behavior caveat are front-loaded and every clause is functional rather than decorative. The middle enumeration is dense with semicolons and would scan better as a list, but no sentence is 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?

For a 14-way multiplexer with full schema coverage, annotations, and an output schema, the description covers most of what an agent needs to choose a kind and supply a query. The missing explanations for the truth and authorship kinds are the one substantive hole, since the schema points back here for that information.

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?

Adds real meaning beyond the schema by mapping each kind to a query format: a reference for text/context/application/word, a Strong's number for lexical lookup, a word or phrase for topic-style kinds, and a verse for reception/tradition/difference. The gap is that the schema's kind field defers entirely to the description, yet 'truth' and 'authorship' are never explained, leaving two enum values opaque.

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?

Specific verb and resource ('gathers the relevant texts in one call') plus an explicit 'Start here' routing signal that separates it from single-passage siblings like get_passage or lookup. The kind enumeration clarifies the scope of the tool, though it omits two enum values (truth, authorship), so the stated scope is slightly narrower than the actual tool.

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?

States the entry condition clearly: broader Bible study or theology questions, and implicitly contrasts with narrower lookups by promising everything in one call. It does not name a specific alternative tool or say when not to use it, so an agent must infer that single-verse lookups belong to get_passage.

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 fully covered. The description's only added behavioral detail is the scope of returned data, including that usage is counted for "today", which implies a daily-reset counter. With an output schema present, it need not describe return format further.

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 with no redundant wording, and the payload description comes before the usage triggers, so it is front-loaded. Every clause adds information the agent would otherwise have to infer.

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 zero parameters, a full output schema, and complete read-only annotations, the remaining burden on the description is only what the tool returns and when to call it, both of which are stated. Nothing an agent needs in order to invoke it correctly is absent.

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 baseline is 4 and there is nothing for the description to disambiguate. No parameter-level meaning is missing.

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?

Uses a specific verb ("Show") with a precise resource enumeration: plan, today's lookups and daily limit, and enabled collections of writings. An agent can tell this is the read-side counterpart to set_account_settings from the name and the word "Show", though the sibling is never named 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?

Gives two concrete triggers: when the user asks about plan, usage, or settings, and after a limit_reached error. That error-recovery guidance is genuinely useful. It does not state when not to use it, and does not name set_account_settings as the mutation alternative.

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, closed-world behavior, so the safety profile is covered. The description adds real operational context beyond that: results include a citation, only one translation is returned per call, and the model should not rely on memory. It does not say how invalid or ambiguous references are handled, which is the remaining 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?

Two sentences, front-loaded with the core action, followed by routing guidance. No filler, no restatement of the title, and every clause carries information the agent needs.

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 shape, and the sibling pointer plus single-translation rule cover the main ambiguity for a simple two-parameter read tool. It stops short of describing edge behavior such as unresolvable references or very long chapter requests.

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 schema already defines both parameters and enumerates available translations. The description nonetheless adds a genuine constraint the schema does not express — 'one translation per call' — which shapes how the translation parameter must be used and points to compare_passage for the multi-translation case.

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 concrete verb and resource: 'Get the exact text of a Bible verse or passage, with its citation.' It also names the sibling it is not (compare_passage), so an agent can separate the two without reading 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?

Explicit trigger conditions are given ('whenever the user asks what a verse says, mentions a scripture reference, or wants a passage read'), along with a directive against quoting from memory and a concrete alternative ('for several side by side, use compare_passage'). When-to-use, when-not-to-use, and the alternative are all present.

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, closed-world, non-destructive behavior, so the safety profile is covered. The description does add the useful division of labor — the tool locates appearances, the agent supplies interpretation — but says nothing about coverage limits, what happens for an unrecognized theme, or result size.

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 tight sentences: what it does, when to use it, and the interpretive boundary. Purpose is front-loaded and every clause carries information; no 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 a single required parameter, full schema coverage, and an output schema handling return values, the description covers what an agent needs to select and call it. The only gap is edge-case behavior — unknown or non-listed theme names — which is not addressed anywhere.

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 lists the accepted theme vocabulary (shepherd, vine, potter, lamb, light, temple, etc.). The description's examples largely duplicate that list rather than adding format, normalization, or fallback guidance, so the baseline of 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 — 'Trace a biblical image or theme through Scripture' — and pins down the deliverable as 'key words and passages grouped by role.' Concrete examples (shepherd, lamb, vine, temple) make it unmistakable versus passage-level siblings like get_passage or lookup_word.

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?

'Use when the user asks about a symbol, metaphor, or recurring theme across the Bible' gives a clear triggering condition. It stops short of naming alternatives or exclusions (e.g., when to prefer connections or related_passages for adjacency rather than thematic tracing), so 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, and destructiveHint=false, so safety and repeatability are covered. The description adds useful substance beyond them, namely the underlying textual editions returned, but says nothing about scope limits, coverage of editions, or cost of range requests, which matters for a verse-by-verse 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?

Two sentences, front-loaded with what is returned before the usage triggers, with no filler. Every clause (word by word, parsing, Strong's numbers, editions) carries information an agent needs.

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 annotations already carry the safety profile. What remains, the original-language content, its source editions, and the situations that call for it, is fully covered 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 100% and the single reference parameter is fully documented, so the baseline is 3. The description adds little syntax guidance and actually narrows scope to 'one Bible verse', while the schema explicitly permits ranges and whole chapters, leaving a small ambiguity about accepted reference width.

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: showing the original Hebrew or Greek behind a verse, word by word, with parsing and Strong's numbers, and names the exact source editions (Hebrew Bible, Westcott-Hort, SBLGNT). That is clearly different from a plain passage fetch such as get_passage and from a single-word lexical tool such as lookup_word.

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: questions about a word's original-language meaning, Greek or Hebrew grammar, or why translations of a verse differ. What it lacks is an explicit when-not or a named alternative ('use get_passage for the English text'), so routing is clear but not fully closed.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond them by naming the returned fields (author, work, section, citation) and by explaining the collection_disabled outcome as a user-disabled collection rather than a bad id, which prevents misdiagnosis of the 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?

Two sentences, front-loaded with the action and scope, then the id provenance and return shape, then the one error condition. No redundant or filler wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with an output schema and full annotation coverage, this is nearly complete: id source, return contents, and the collection_disabled state are all addressed. Only minor edges, such as behavior for an unknown or stale id, are left unstated.

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 parameter is fully documented in the schema, so the baseline would be 3. The description goes slightly beyond it by tying the id to its producing tools, reinforcing that this is an opaque passage id rather than a citation string.

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 (read one passage of a church father or other Christian writing in full) and scopes it to a single id, which cleanly separates it from scripture-reading siblings like get_passage and from search_writings, which only produces the ids.

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 tells the agent where the required passage_id comes from (search_writings or discussions_of), which is the key routing decision for this tool. It stops short of explicit when-not guidance or a direct contrast with get_passage, so it is clear context rather than full alternative 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact beyond that: results are account-specific ('whether this account has each turned on'). It says nothing about ordering or how the enablement flag should be acted upon, and the presence of an output schema removes the need to describe return values.

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 beginning with the verb, with no filler. The parenthetical tradition list is dense but earns its place by defining collection scope; the trailing clause about account enablement is slightly awkward in phrasing but carries real 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?

For a no-parameter, read-only listing tool with full annotation coverage and an output schema, the description supplies what an agent needs to call it correctly. The one gap is not connecting the enablement flag to set_account_settings, which is the natural follow-up action.

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 there is nothing for the description to disambiguate; baseline 4 applies. No parameter text is needed or missing.

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 ('List') and resource ('collections of Christian and Jewish writings outside the Bible') and enumerates the traditions covered, which scopes the result set precisely. It is distinguishable from siblings like list_translations by the 'writings outside the Bible' framing, though it never explicitly contrasts with search_writings or get_writing.

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: an agent can infer this is the discovery step before search_writings/get_writing, and that the 'turned on' flag relates to account settings, but no when-to-use, when-not-to-use, or alternative tool is named. With 18 siblings including set_account_settings and search_writings, explicit routing guidance would materially help.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds context the annotations can't: that the output includes licensing and the exact identifier string to feed into other tools, which is the reason to call this first.

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, zero waste. The resource and payload are stated first, then the usage condition, so the most important routing information 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?

With an output schema present and no input parameters, the description only needs to explain purpose and when to call it, both of which it does. Nothing an agent needs in order to invoke 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?

The tool takes zero parameters, so the baseline is 4. The description nonetheless clarifies the meaning of a returned field (the name to pass as translation), which helps the agent wire this tool to its siblings.

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 ("List the Bible translations and Hebrew and Greek texts") plus the returned payload (name to pass as translation, license). That distinguishes it clearly from siblings like lookup, get_passage, or search_scripture, which consume a translation rather than enumerate 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 two concrete trigger conditions: the user asks which versions are available, or the user names a version the agent doesn't recognize. It does not explicitly name an alternative tool or exclusion, but the when-to-use guidance is unambiguous.

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, closed-world, non-destructive behaviour. Beyond that, the description explains the excerpt-by-default behavior, the full=true escalation, and that shared names surface as a candidate list — non-obvious result-shape facts the annotations do not cover.

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 tight sentences: what is read and from where, when to use it, then what comes back and how to expand it. The return-shape note is front-loaded immediately after usage rather than buried, with no filler wording.

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?

A two-parameter read tool with full schema coverage, an output schema, and complete annotations needs little more. The description covers purpose, trigger questions, and the one meaningful output-size decision (excerpt vs full), leaving no gap an agent must guess at before calling it.

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, including the boolean default and the examples for name. The description restates the full/excerpt trade-off and adds the candidate-selection nuance for name, but adds no syntax or format detail 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?

Uses a specific verb and resource: read dictionary/encyclopedia entries from named sources (Easton's, Smith's, Nave's) about a person, place, object, custom, or subject. That scope is distinguishable from siblings like lookup_word (word definitions) or get_theme, so an agent can route correctly 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 an explicit usage cue — background/history questions or the 'who or what was X in the Bible' phrasing — which is exactly the intent an agent needs. It stops short of naming an alternative tool to prefer for linguistic or passage-based questions, so sibling disambiguation is implied rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered without the description. The description adds the meaningful scope detail that the word is studied across the entire Bible rather than a passage, but says nothing about how results are ordered or capped, which matters for a word occurring hundreds of times.

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 sentences, front-loaded with the core action and output, followed by the use case and the routing rule. The concrete examples (agape, logos, hesed) earn their space by anchoring the abstract 'Strong's number' concept.

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 covers scope, input provenance, and the sibling handoff. The only shortfall is the unmentioned result-limit behavior for high-frequency words like hesed.

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 both parameters are already documented, including the G26/H2617 format. The description reinforces the semantic intent of 'strong' by pairing the tool with named word studies, but adds no new constraint and never mentions the limit parameter's effect.

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 ('Study one Hebrew or Greek word across the Bible by its Strong's number') plus the three things returned (lexicon glosses, occurrence count, verses). It explicitly positions itself against the sibling that supplies input (get_words), so an agent can distinguish the pair 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?

Gives the use case ('word studies' such as agape, logos, hesed) and names the alternative tool with the exact condition that selects it: get_words supplies the Strong's numbers needed as input here. That is an explicit when-to-use plus routing rule, not an 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 establish that this is a read-only, idempotent, non-destructive operation with a closed-world scope. The description adds useful provenance by identifying the two underlying cross-reference sources, which helps an agent understand what kind of evidence it will get. It still does not explain result ordering, ranking, or source weighting, keeping it below 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?

Two sentences, front-loaded with the tool's purpose and immediately followed by when to use it. The sources are named compactly, and there is no redundant restatement of schema details or annotations.

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?

The tool is simple, its annotations are rich, its schema is fully described, and an output schema exists, so the description does not need to explain return values. It covers purpose, sources, and triggering contexts adequately. A brief note on ordering or source weighting 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?

Schema description coverage is 100%, so both the reference format and the limit are already fully documented in the input schema. The description says the lookup is 'connected to a verse,' which is slightly narrower than the schema's support for ranges and chapters. It therefore adds little meaning beyond the structured fields, fitting the 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?

The description states a specific action and resource: finding cross-references, defined as other Bible passages connected to a verse. Naming the Treasury of Scripture Knowledge and OpenBible makes the scope concrete. It does not explicitly distinguish this from similarly named siblings such as connections or compare_passage, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: invoke this when the user asks for related verses, parallel passages, or where else Scripture says something similar. That covers common triggering requests well. It stops short of naming alternatives or stating when not to use it, so a 4 is appropriate.

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, and non-destructive behavior, so the safety profile is covered. The description adds only that the lookup is scoped to a single church father or writing passage; it discloses nothing about result shape, citation granularity, or behavior for an invalid id, which the output schema partially compensates for.

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 sentence with no filler, and the essential input constraint (the id source) is placed where the reader hits it immediately. Nothing could be removed without losing 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?

With a rich annotation set, an output schema, and one fully documented parameter, the description covers what an agent needs to call it correctly. Only the lack of any note on citation format or empty results keeps it from a 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?

There is one parameter with 100% schema description coverage, and the schema states the same provenance ('A writing passage id from search_writings or discussions_of'). The description restates rather than enriches that meaning, 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 ('List the Bible verses that one ... writing passage cites') and bounds the scope to a single writing identified by passage_id. It is clearly distinguishable from siblings like search_scripture (find verses by text) or related_passages, since the resource here is 'verses cited by a given writing'.

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 names the prerequisite input source explicitly ('by its id from search_writings or discussions_of'), which tells the agent this is a follow-up step after locating a writing passage. It stops short of naming an alternative tool or stating when NOT to use it, so it is strong context but not a full routing rule.

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 safety is covered. The description adds a genuinely useful behavioral trait beyond that: matching tolerates inexact names and spellings, which tells the agent to use it as a fuzzy lookup rather than exact retrieval. It does not mention result ordering or limit behavior, but that is minor here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, and the core purpose is front-loaded ahead of the usage hint and next step. Every clause contributes either scope or routing 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 and the input schema is fully described, so the description need not explain return values. The mention of opening results with lookup or get_theme effectively signals that results carry usable identifiers, leaving little an agent needs to infer before calling.

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%, with query and limit both documented in the schema including example values. The description only restates that the query is a name or subject, adding no format or syntax 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 (find) and resource set (Bible people, places, themes, dictionary entries) matched by name or subject. This implicitly separates it from siblings like search_scripture and search_writings, though it never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear trigger ('use when you're not sure of the exact name or spelling') and a follow-up path ('open a result with lookup or get_theme'). It lacks an explicit exclusion, e.g. when to prefer search_scripture or lookup directly, 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond them by disclosing the return shape ('returns the verses with references') and the dual query mode, which an agent would not otherwise know from the annotations. It does not discuss ranking, ordering, or what happens when nothing matches.

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 core action and immediately followed by usage triggers. The sentence 'Returns the verses with references' is slightly redundant given the output schema exists, but it costs little and reads naturally.

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 detailed, and annotations cover safety semantics. For a three-parameter read-only search, the description covers purpose, triggers, and query modes adequately. Minor gaps remain around result count/limit behavior and what is returned when no verse matches.

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 every parameter, including the full translation list and default, is already documented in the schema. The description restates that 'query' accepts words, a phrase, or a reference, which is largely redundant with the schema's own text. Baseline 3 applies when the schema carries the parameter burden.

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 opens with a specific verb and resource scoped to a corpus: 'Search the Bible for verses containing words or a phrase.' The Bible/Scripture scope implicitly separates it from search_writings, and the reference-mode sentence ('A reference such as John 3:16 returns that passage') clarifies exactly what the tool does with each query type.

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?

Three concrete when-to-use triggers are given: the user remembers wording but not the reference, asks where the Bible mentions something, or wants verses on a topic. That is strong positive guidance. What is missing is the negative side — it never says when to prefer get_passage, lookup, or related_passages instead, and the reference-mode behavior overlaps get_passage without acknowledging the choice.

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 a safe, idempotent read, so the description is free to add the useful part: results come back as snippets with ids that must be resolved via get_writing. It says nothing about ranking, snippet length, or behavior under a very broad query, which is the remaining 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?

Three short sentences: scope, when to use, and what comes back. Scope is front-loaded and every sentence carries distinct information with no restating of the title.

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 and the description still summarizes the return shape, so an agent knows it gets ids to follow up on. Only the relationship to the general `search` and `discussions_of` siblings is left unstated.

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 era, author, limit, and query are already documented in the schema (including the early/later split and example author names). The description adds no field-level meaning beyond what the schema states, 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 (Search) and a precisely bounded resource (Christian writings outside the Bible: church fathers, councils/creeds, commentaries, later Catholic/Orthodox/Protestant/Jewish works). The explicit 'outside the Bible' boundary lets an agent distinguish it from search_scripture 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?

Gives a concrete use condition ("when the user asks what early Christians, a theologian, or a tradition wrote about a subject") and hands off the follow-up step to get_writing. It does not address when to prefer the broader `search` or `discussions_of` siblings, so the routing is clear but not exhaustive.

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 not-read-only, idempotent, non-destructive, and closed-world, so the safety profile is carried structurally. The description adds one genuinely useful behavioral fact — 'Changes apply to later lookups' — confirming persistence across subsequent queries, but says nothing about partial-update semantics (omitted keys left unchanged) or what the response reports.

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 short sentences, front-loaded with the action and followed by the persistence note; nothing is redundant. The opening phrasing 'Turn collections of writings on or off' is slightly awkward but costs little.

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 rich annotations, full schema coverage, and an output schema, the description only needs to convey purpose, trigger, and persistence — all present. The remaining gaps (partial update behavior, relation to list_collections for discovering ids) are minor rather than blocking.

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 baseline is 3; the description earns an extra point by mapping user-facing concepts ('traditions', 'collections of writings') onto the collections parameter, helping the agent decide which field to populate from a vague user request. It does not touch the bibles parameter beyond what the schema already documents.

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 ('Turn collections of writings on or off for this account') and grounds it in concrete examples (church fathers, Catholic, Jewish sources). It reads as the write counterpart to get_account_settings without naming that sibling explicitly, which keeps it just 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 an explicit trigger ('when the user asks to include or leave out a tradition'), which tells the agent exactly the user intent that should route here. It does not state the inverse case (read settings via get_account_settings, discover ids via list_collections), so the exclusions are only implied.

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