Bible by Midvash

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false, indicating safe, idempotent behavior. The description adds transparency by specifying the output format (Markdown) and default version behavior. It is consistent with annotations and provides useful 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 description is very concise at three sentences, front-loaded with the primary purpose, and contains no filler or redundant information. Every sentence adds 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?

Despite no output schema, the description specifies the return format (Markdown comparison). It also distinguishes from 6 sibling tools. The tool's behavior is fully covered: what it does, when to use, parameter constraints, and result format. Complete for a comparison 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?

Both parameters have descriptions in the schema (100% coverage). The description adds extra semantic info: for 'versions', it explains the default behavior (connection URL or small set) and the maximum of 8. This goes beyond the schema's description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it compares the same Bible passage across multiple versions and returns a Markdown side-by-side comparison. It also explicitly distinguishes from sibling tool get_passage: 'For a single version, use get_passage.'

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

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

The description provides explicit use cases (translation comparison, sermon preparation, study questions) and clearly states when not to use it (single version -> get_passage). It also mentions the maximum of 8 versions, guiding proper usage.

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 semantics, so the safety profile is covered without description help. The description adds genuine behavioral context by disclosing the return format (Markdown, numbered verses), which is the useful extra 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 with zero filler: the primary action with its output format first, then the usage condition. Nothing repeats the name or wastes 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 not be re-explained, and rich annotations cover safety. Combined with 100% parameter coverage, the description is nearly complete; the only missing piece is disambiguation from the get_passage sibling.

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 all three parameters (version, book, chapter) are already documented with examples and constraints in the schema. The description only gestures at 'a specific version' and adds no syntax or format meaning beyond that, 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?

Names a specific verb and resource ('Fetches a full Bible chapter from a specific version') and specifies the output format, which is more than the title alone. It differentiates against an isolated verse (implying get_verse), but never addresses the sibling get_passage, so an agent cannot fully disambiguate those two from the text alone.

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

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

Contains an explicit when-to-use clause ('Use this when the user needs chapter-level context instead of an isolated verse') that pairs the tool with the condition selecting it. It stops short of naming the concrete alternative tools (get_verse, get_passage) to route to.

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). The description adds the useful coverage fact (all 1,189 chapters, 9 languages) and the return shape (summary with a link to the full commentary). This is solid added context, but does not go deep on auth, rate limits, or fallback behavior when a language is unavailable.

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?

Four short sentences, heavily front-loaded with the core purpose, then content description, then usage trigger, then sibling routing. 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?

For a read-only lookup with full schema coverage and no output schema, the description is nearly complete: it explains what is returned (a summary plus link) and when to use it. The gap is minor – no note on behavior when the requested language or reference does not resolve.

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 fully documented in the schema, including the language enum-ish list and the reference resolution rule. The description's claim of '9 languages' corroborates but does not add syntax 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 and resource ('Fetches the Midvash commentary for the chapter a reference points to') and elaborates on what the content contains (context, main movements). Explicitly distinguishes the adjacent sibling by routing text queries to get_passage.

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 ('Use this for "what is this chapter about" questions') and names the alternative for text retrieval (get_passage). Clear when-to-use plus when-to-use-something-else.

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 behavior, so the safety burden is lifted. The description adds useful non-obvious context: results are ranked by attestation and include text, reducing a follow-up lookup. It doesn't mention result count limits or pagination, but the schema's limit param covers 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?

Three front-loaded sentences: action, use-case framing, and return shape. No filler, and the return-value summary is placed last where it's most relevant.

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 needn't be explained. The description covers purpose, ranking basis, and downstream utility. Combined with full schema coverage and annotations, an agent has all it needs to invoke 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%, so every parameter is already documented in the schema, including the single-verse constraint and the include_text toggle. The description only broadly mentions 'given verse' and 'each related passage with its text'—no substantive additions beyond structured data. 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?

Starts with a specific verb+resource ('Finds other Bible passages that relate to a given verse') and names the ranking criterion (how widely attested). This clearly distinguishes it from siblings like get_verse, get_passage, and search_bible, which do not return ranked cross-reference lists.

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 standard next step in study after reading a verse" gives a clear usage context, implicitly contrasting with get_verse/read-first workflows. It doesn't explicitly name alternatives or when NOT to use it, but the framing is strong enough to guide selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds only the routing context; batching limits (max 10) and version fallback live in the schema, not the description.

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 purpose, and the examples are compact illustrations rather than padding. Every clause earns its place by showing reference shapes an agent must handle.

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 documented in the schema. The only thin spot is not naming the sibling tools it supersedes, but for a simple two-parameter lookup the definition is essentially 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 parameters are already fully documented in the schema, including the version fallback and the '10 per call' cap. The description restates accepted reference formats already covered, adding no syntax 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 and resource (fetches Bible passages) plus the exact input form it accepts (natural-language references), with concrete examples. The closing sentence distinguishes it from sibling lookup tools like get_verse/get_chapter that take structured book/chapter/verse fields.

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 routing rule: use this as the primary lookup when the user supplies a citation rather than structured fields. It does not name get_verse or get_chapter explicitly as the alternatives, so the exclusion 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 readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, and an output schema exists, so the safety and return-shape burden is largely lifted. The description adds that entries are returned 'translated into the requested language,' which is useful context, but says nothing about result limits, ranking of matches, or what happens on a miss.

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 the purpose and accepted input forms front-loaded, and the parenthetical examples earn their space by showing both scripts. The corpus counts (8,674 / 5,523) are mildly decorative but cheap.

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 full schema, output schema, and rich annotations, the description supplies everything needed to select and call the tool. Only the lookup-mode interaction (number vs. word precedence, ambiguity handling) is left implicit.

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 every parameter (word, number, language, translation_language, limit) is documented in the schema itself, including the H/G prefix and bare-number rules. The description's mention of number-or-word lookup largely restates that; 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?

Specific verb+resource ('looks up a word in Strong's lexicon'), scoped with concrete corpus sizes and both accepted identifier forms, and clearly distinct from the passage/verse/commentary siblings. An agent knows exactly what this does 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?

It states the selecting condition explicitly: 'Use it when the question is what an original-language word means.' That routes the agent well, but it names no alternative sibling (e.g. search_bible) for the adjacent case of finding where a word occurs.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds the range-versus-natural-reference behavioral distinction, but says nothing about error behavior for invalid verses or version-enablement failures.

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 tight sentences with zero waste, front-loading the primary capability and then the sibling routing rule. Every sentence earns its place.

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

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

An output schema exists, so return-value shape need not be restated. With 100% schema coverage and full annotation coverage, the only open question for an agent, which tool to pick, is answered explicitly.

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 every parameter, including the optional verse_end range bound, is documented in the schema itself. The description only echoes the range concept and adds no syntax or format detail beyond what the schema provides, 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?

States a specific verb ('Fetches'), a precise resource ('one exact Bible verse or a contiguous verse range'), and scope ('from a specific version'). It is immediately distinguishable from get_passage and get_chapter.

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 precondition ('when the book, chapter, verse, and version are already known') and names the alternative with the selecting condition ('For natural references such as "John 3:16-18", prefer get_passage'). No inference required.

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, so the agent knows it's safe. The description adds context that it returns 66 canonical books and specific fields (names, slugs, etc.), which is beyond the annotations. No contradictions.

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: first describes what the tool does, second gives usage guidance. No unnecessary words, front-loaded with key information. Every sentence is essential.

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

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

For a simple list tool with two optional parameters and no output schema, the description is complete. It explains the returned fields and the tool's role in the workflow (providing identifiers before lookups). The annotations cover safety and idempotency, so no additional behavioral context is needed.

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 baseline is 3. The description adds value by explaining that 'language' affects localization of names, slugs, and abbreviations, and 'testament' allows filtering, reinforcing the purpose of the parameters beyond the schema's basic descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Lists' and the resource '66 canonical Bible books'. It specifies the returned data: localized names, slugs, abbreviations, testament grouping, and chapter counts. It also distinguishes from sibling lookup tools by saying 'before calling lookup tools'.

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 says 'Use this when an agent needs valid book identifiers or localized display names before calling lookup tools.' This indicates when to use. Although it doesn't explicitly state when not to use, the context of sibling tools like get_chapter and search_bible implies the tool is for enumeration and identifier retrieval, not direct lookups.

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 the safe read-only, idempotent profile, but the description adds real behavior: it automatically respects URL filters like ?v=onbv,kjv and ?lang=pt-br,en. That explains why results may be narrower than the full corpus, which no annotation conveys. It does not describe the shape of the returned list.

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, and the filter behavior is front-loaded before the usage instruction. Every clause earns its place.

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

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

For a zero-required-param, read-only listing tool with full schema coverage, the description covers purpose, usage routing, and filter behavior adequately; the absence of an output schema means the return format is only implied by 'Lists versions'.

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 'language' parameter is fully documented in the schema, including the pt/pt-br/pt-pt nuance. The description's ?lang example only loosely reinforces this, 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?

States a specific verb (Lists) and resource (Bible versions) scoped to 'the current MCP connection', which clearly separates it from list_books and the get_/search_ siblings. An agent can identify exactly what this returns 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?

Explicitly says when to use it: 'before lookup, search, or comparison when the user has not specified a version', which maps onto get_passage/get_verse, search_bible, and compare_passage. It stops short of naming the alternative tools directly or stating any when-not-to-use 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 cover read-only, idempotent, and non-open-world traits, so the bar is lower. The description adds meaningful behavioral detail beyond them: case/accent/vowel-mark normalization and the double-quote exact-phrase convention that changes what matches. It does not cover pagination or result-size behavior, but the output schema exists to carry 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?

Three tight sentences with zero filler, front-loading what the tool does before the normalization rules and the sibling routing. Every clause earns its place.

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

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

For a search tool with full schema coverage, an output schema, and annotations covering the safety profile, the description supplies everything an agent needs to select and invoke it correctly, including the alternative tools for the citation case.

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 parameters are already fully documented, giving a baseline of 3. The description restates the exact-phrase quoting and normalization behavior already present in the query parameter description rather than adding semantic 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 ('Searches the Bible text for words or an exact phrase') and immediately names the resource returned ('matching verses ranked by relevance'). It distinguishes itself from siblings by contrasting with get_passage/get_verse in the same paragraph.

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 when-to-use ('discovery questions like "find verses about love"') and a when-not-to-use with named alternatives ('For a known citation, use get_passage or get_verse'). Nothing 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 useful behavior beyond that: results are summaries rather than full articles, with a link out to the full content — an agent needs that to set expectations.

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, front-loaded with the resource and scope, followed by the disambiguation and the result-format note. Every sentence earns its place with 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?

No output schema exists, but the description compensates by stating that results are summaries with a link to the full article. Combined with complete param coverage and clear routing to siblings, an agent has everything needed to call 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 description coverage is 100%, so all four parameters including the type enum, limit range, and language codes are already documented in the schema. The description's mention of '9 languages' and the four content types restates what the schema conveys; 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 (searches) and resource (Midvash's Bible study library) and enumerates the four content types it covers in 9 languages. It clearly distinguishes itself from siblings like search_bible and get_passage.

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 frames the use case ('background and explanation — who a person was, what a term means, what a chapter is about') and names the alternatives (search_bible, get_passage) for when the biblical text itself is wanted. Nothing 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.