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

With no annotations, the description carries the full burden of behavioral disclosure. It conveys the core behavior — morphological and root analysis — but does not explain what the analysis returns, whether it is read-only, or any limitations such as supported transliteration systems. The behavior is more specific than a tautology but still minimal.

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

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

The description is a single, front-loaded sentence with no filler. Every phrase contributes to purpose and input scope. It is concise without sacrificing clarity.

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?

Given there is no output schema and no annotations, the description should ideally say more about what the analysis returns and how to choose this tool over similar siblings. It is adequate for basic invocation — the input parameter is fully documented and the tool's domain is clear — but it leaves the output format and sibling differentiation to inference.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by specifying 'raw original language words' in addition to lemmas and transliterations, clarifying that inflected/raw forms are acceptable input, not just dictionary forms. This is a small but useful distinction beyond the schema's 'word, lemma, or transliteration'.

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 tool's function: morphological and root analysis of Greek or Hebrew words, lemmas, or transliterations. The verb is implicit in 'analysis' but the resource and scope are specific. It does not explicitly distinguish itself from sibling tools like get_strongs_etymology or get_strongs_definition, so it stops short of a 5.

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

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

The description implies when to use the tool: when an agent has a raw original-language word, lemma, or transliteration and needs morphological or root analysis. However, it provides no explicit guidance about when not to use it or how it differs from related siblings such as get_strongs_etymology or search_semantic.

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?

With no annotations provided, the description carries the full burden of explaining behavior, but it only makes aspirational claims and gives an invocation directive. It does not disclose what the tool returns, whether it draws on scripture, how it handles unsupported questions, or any side effects or limitations.

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 short and front-loaded, with the core purpose stated in the first sentence and examples embedded. The heavy use of ALL CAPS and 'ALWAYS' is somewhat noisy but does not create significant bloat.

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?

Given 9 parameters, no output schema, nested objects, and a large sibling set, this description is not complete enough. It offers no guidance on parameter selection, no explanation of how the master mode relates to the specialized Bible lookup tools, and no indication of what a caller should expect in response.

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 documents all 9 parameters and the description adds no parameter-level meaning. The tool has redundant-looking fields like question and userMessage, but the description does not clarify their relationship, so it stays at the baseline rather than adding value.

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 identifies the tool as the go-to for general, philosophical, ethical, and conceptual questions, with concrete examples ('що таке любов', 'чому люди страждають'). It distinguishes this from sibling search/verse tools by scope, though 'MASTER TOOL FOR ALL' is overstated and the exact action ('answer from the Bible?') is implied rather than stated.

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 gives an explicit routing rule: 'ALWAYS CALL THIS TOOL ON TURN 1' and lists the question categories it should handle. However, it provides no exclusions, no guidance on when to prefer sibling tools like search_keyword or get_verse, and the 'ALWAYS' instruction is too absolute to be reliable.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal the output shape (JSON with verses, complexity score, sensitivity profile, effective mode), but it does not explain side effects, prerequisites, how mode or warmth affect the result, or whether this operation is read-only or model-backed.

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

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

The description is a single, tightly worded sentence that front-loads the core action and then lists the key output components. There is no filler or redundant material.

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?

Given the absence of annotations and output schema, the description lists several useful output facets but still leaves gaps: it does not explain what 'effective mode' means, how the parameters interact, or when this composite generation is preferred over the many sibling search/retrieval tools. It is adequate for initial understanding but not fully self-sufficient.

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 input schema already provides descriptions for all four parameters, so the schema coverage is 100%. The description adds no per-parameter meaning beyond the schema; it only summarizes the output fields, which is the appropriate baseline for fully documented parameters.

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

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

The description uses a specific verb ('Generates') and names the resource ('structured biblical context JSON') plus the key output fields: relevant verses, complexity score, sensitivity profile, and effective mode. It is clear about what the tool produces, but it does not explicitly contrast with sibling tools like get_chapter_context or find_thematic_scripture_chain.

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

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

There is no guidance about when to use this tool versus alternatives. The description only states what it does, not which situations call for it, when not to use it, or how it relates to the many sibling retrieval and configuration tools.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds useful context by naming the algorithm and the kind of insights the diff produces, which implies a read-only analysis. However, it does not explain the output shape, edge-case behavior, or any side effects, leaving the agent uncertain about what the call returns.

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

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

The description is a single sentence with no filler, front-loading the core operation. The technical phrase 'Myers LCS' is compact but slightly opaque; still, conciseness is strong.

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?

This is a 5-parameter comparison tool with no output schema and no annotations, yet the description is minimal. It leaves undefined the return format, whether the diff covers a single verse or the whole chapter, and how defaults affect behavior. An agent needs more context to invoke this tool reliably.

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 documents all five parameters. The description only roughly maps to the two translation parameters and adds no parameter-specific semantics beyond what the schema provides.

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

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

The description identifies the operation as a word-level Myers LCS diff analysis comparing two Bible translations, which is specific and not a tautology. It conveys the tool's niche among siblings, but does not explicitly contrast it with get_parallel_verses or other alternative tools, so it stops short of full sibling differentiation.

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

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

The description implies the tool is for comparing two translations to surface lexical and philosophical differences, giving an agent a rough sense of when to use it. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named.

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?

With no annotations, the description carries the behavioral burden, but it only adds high-level claims about vector reasoning and hierarchical chunking. It does not disclose whether the operation is read-only, how chunks are returned, what max_tokens affects, or any side effects or limits.

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

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

The core sentence is concise and front-loaded after a flashy preamble. The preamble's '100M Token Vector Reasoning & Hierarchical Semantic Chunker Engine' is redundant with the actual sentence and does not earn its place.

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

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

Even though the schema covers parameters, the tool has no output schema and the description never explains what the caller receives or how chunk extraction behaves on large texts. For a complex vector-chunking tool, this leaves substantial ambiguity.

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?

Input schema coverage is 100%, so all four parameters are already documented, and the description adds no meaning beyond the schema. The generic mention of extracting from documents aligns with full_text but provides no extra detail.

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 target: 'Extracts relevant semantic chunks from large documents/attachments.' This is clear enough to differentiate from sibling scripture-search tools, though the opening phrase '100M Token Vector Reasoning & Hierarchical Semantic Chunker Engine' is marketing-oriented rather than functional.

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

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

The phrase 'from large documents/attachments' implies the tool is for document-scale context extraction, but it never states when to prefer it over siblings like search_semantic or get_chapter_context, nor does it describe exclusions. It gives only implicit 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says the tool matches situations to 'verified scripture anchors,' but it does not explain how matching works, whether results are ranked, how auto emotion detection behaves, what language support does, or what the response contains.

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

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

The description is a single focused sentence with no filler, and the core purpose is front-loaded. It is concise even though it sacrifices some behavioral and usage detail, which belongs to other dimensions.

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 no annotations and no output schema, the description is too thin to fully prepare an agent for selection and invocation. It does not describe what a 'scripture anchor' looks like in the response, when to choose this tool over sibling search tools, or how the emotion and language parameters shape output. The parameter schema makes the call possible, but expectation-setting is incomplete.

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 documents all three parameters. The description adds domain context and example life-situation categories, but it does not explain parameter interactions or formats beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('matching') with a specific resource ('real-world human trials ... with verified scripture anchors') and a clear domain ('Pastoral counseling'). This makes the tool semantically distinct from generic siblings like search_keyword and search_topic, even without naming them.

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

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

The phrase 'Pastoral counseling tool' and the enumerated trials (anxiety, grief, burnout, loneliness, conflict) imply when to use it: when someone describes a life struggle rather than a keyword or topic query. However, there is no explicit statement of when to prefer this over sibling search tools or any exclusion criteria.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that the tool traces a theme's development across covenants, which implies a read-oriented research behavior, but it does not describe the return shape, ordering, default behavior of starting_verse, or any limitation. The transparency is adequate at a high level but has gaps.

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

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

One sentence with no filler, front-loaded with the operation and scope, and followed by clarifying examples. Every part 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 simple two-parameter read tool, the description plus schema is mostly sufficient to invoke it correctly with a theme. However, with no output schema and no annotations, it does not say what the returned chain looks like or when to choose this tool over sibling cross-reference and semantic search tools, so completion is adequate but not strong.

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: theme as a thematic concept and starting_verse as an optional OSIS with a default. The tool description adds thematic examples but no additional parameter syntax or behavior details, 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?

The description names a specific verb ('Traces') and resource ('progressive revelation of a biblical doctrine or theme across covenants'), with concrete examples like 'Living Water' and 'Seed of the Woman' that clarify what counts as a theme. It differentiates from generic search tools by emphasizing covenant progression, but it does not explicitly name or distinguish a sibling tool like get_cross_references.

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 phraise 'progressive revelation... across covenants' implied the intended use case, but the description gives no explicit when-to-use or when-not-to-use guidance and does not mention alternatives. An agent has to infer when this is preferred over search_semantic or get_cross_references.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the operation is a read, but does not disclose output size, pagination, language default behavior, or whether the text includes verse numbering/formatting. Important behavioral traits are left unstated.

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

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

The description is a single, efficient sentence with no filler. It states what is retrieved and why, and every word contributes to understanding the tool's role.

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 3-parameter retrieval tool, the description is reasonably complete about the action and result. However, with no output schema and no annotations, it should clarify what 'complete chapter text' includes and what happens if language is omitted, leaving a clear gap.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning beyond what the schema provides, but it does not need to for book and chapter. The optional language parameter still lacks default or format explanation.

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 ('complete chapter text') and a clear purpose ('immediate context understanding'), which distinguishes it from sibling tools like get_verse or get_commentary. However, it does not explicitly contrast itself with any sibling, so it stops short of full differentiation.

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

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

The description gives no guidance about when to prefer this tool over alternatives such as get_verse, get_commentary, or build_biblical_context. The phrase 'for immediate context understanding' weakly implies a use case, but there is no when-to-use, when-not-to-use, or 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?

With no annotations provided, the description carries the full burden. 'Retrieve' indicates a read operation, and the named authors give a sense of content scope. However, it does not disclose any behavioral traits such as result format, whether multiple commentaries are returned, or limitations like coverage gaps.

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

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

One sentence with no padding, front-loaded with the verb and resource. Every word contributes to meaning.

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

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

For a simple retrieval tool with three clear parameters, the core function is stated. However, with no output schema, the description does not explain what the returned commentary data looks like (e.g., plain text, structured objects, multiple authors), leaving some uncertainty for the agent.

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 schema already provides 100% parameter descriptions, though minimal. The description adds the context that parameters refer to biblical passages for commentary retrieval, but it does not elaborate on accepted book abbreviations or how verse/chapter are interpreted. This meets the baseline but adds little beyond the schema.

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

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

The description uses a specific verb ('Retrieve') and names a concrete resource ('patristic and classic historical commentaries') with example authors. This clearly differentiates it from sibling tools like get_verse or get_cross_references, which target different content types.

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

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

No explicit guidance is given about when to use this tool versus alternatives. It does not state conditions such as 'use when you need historical interpretations' or exclude tools like search_topic or get_chapter_context. The use case is only implied by the resource name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add useful behavioral context via 'PageRank ranking' and 'anti-flooding diversity', plus the scale of the graph, but it says nothing about output shape, defaults, or operational caveats.

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 that efficiently communicates the action, resource, graph scale, ranking algorithm, and diversity behavior. Every phrase earns its place and there is no filler or repetition.

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 retrieval tool with fully documented parameters, the core 'what' and 'why' are clear. However, there is no output schema and the description never explains the shape of the returned cross-references or any default result-count behavior, leaving some ambiguity when an agent consumes the response.

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 input schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds no parameter-level meaning beyond what the schema provides, but it does not need to because book, chapter, verse, category, and max_results are already documented.

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

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

The description names a specific verb ('Retrieves'), a clear resource ('theological cross-references from the 344,000+ TSK graph'), and adds ranking and diversity behavior. It clearly distinguishes from plain verse retrieval, though it does not explicitly contrast with sibling tools like get_parallel_verses or find_thematic_scripture_chain.

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 intended use is implied: call this tool when theological cross-references for a verse are needed. However, the description provides no explicit when-to-use or when-not-to-use guidance and does not name any alternatives among the many sibling lookup/search tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals what data is returned but omits key behavioral details such as how the original language is selected per book (Old Testament vs New Testament), whether parallel_translation is always applied, and any limitations like unsupported books or missing morphology for certain texts.

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

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

The description is a single sentence that front-loads the verb and object, then efficiently lists the returned data elements without repetition or filler. Every phrase contributes useful 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?

Without an output schema, the description does list the content elements returned, which is helpful, but it does not describe the response envelope, the language-selection rule, or the meaning of the parallel_translation default. Given the simple parameter set, the description is minimally viable but leaves notable gaps for an agent deciding among many sibling Bible tools.

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

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

The input schema already documents all four parameters with descriptions, so the baseline is 3. The description adds no additional parameter-specific guidance, such as the valid format for 'parallel_translation' or how book names map to Hebrew versus Greek source texts.

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 ('Retrieves'), a well-defined resource ('word-by-word original Hebrew (WLC) or Greek (NA28/LXX) interlinear text'), and enumerates the exact data elements returned (Strong's numbers, transliterations, lemmas, grammatical morphology). This clearly differentiates it from sibling verse retrieval tools like get_verse or get_parallel_verses, even without naming them explicitly.

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

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

The description implies usage when word-by-word original-language interlinear data is needed, but it provides no explicit when-to-use or when-not-to-use guidance. It does not contrast with related tools such as get_strongs_definition, analyze_greek_hebrew_word, or compare_translations_diff, so an agent must infer the appropriate selection context.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Exposes' implies a read-only introspection operation, but the description does not mention side effects, response structure, or any operational caveats. It is not contradictory, but it is minimal.

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

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

The description is a single front-loaded sentence with no filler. Every phrase contributes to identifying the resource and the kind of information exposed.

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 introspection tool with two schema-documented optional parameters, the description is adequate at a high level. However, since there is no output schema and no annotations, a brief note on return format or intended use would make it complete enough for an agent to call confidently.

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 optional parameters (client_host, client_name) are already clearly documented in the schema. The tool description adds no information about how these parameters affect the returned capabilities, but it does not need to restate the schema.

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

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

The description uses a specific verb ('Exposes') and names the resource ('holy-bible-mcp') with three scoped facets: active capabilities, mode profiles, and status. It does not explicitly differentiate from siblings like get_p2p_swarm_status or get_model_recommendations, but it is clear enough about the general purpose.

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

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

There is no guidance on when to call this tool versus the sibling tools, no use-case framing, and no stated prerequisites. The description only says what the tool exposes, leaving the agent to infer when it would be relevant.

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?

No annotations are present, so the description carries the transparency burden. 'Calculates' indicates a non-mutating computation, which is useful, but the description does not explicitly state the return format, confirm no side effects, or explain how optional inputs like warmth influence results.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes either the output set or the input basis.

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 calculator with no output schema, the description names its outputs but does not describe the return object shape or clarify how the optional warmth parameter factors into the calculation. Sufficient for basic invocation, but not 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 coverage is 100%, providing the baseline of 3. The description adds meaning by mapping 'LLM parameter size' to parameter_size_b and introducing 'query complexity' as the role of user_message, which the schema labels only as 'User's prompt message'. Warmth's role remains unexplained.

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

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

The description uses a specific verb ('Calculates') and names a precise resource: adaptive sampling parameters, listing five concrete outputs. This makes the tool clearly distinct from sibling scripture/context tools despite the broad 'model recommendations' name.

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

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

The intended use is implied: when an agent needs sampling parameters derived from model size and query complexity. However, the description never states explicit when-to-use conditions, exclusions, or alternatives (though no sibling tool appears to overlap).

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?

No annotations are provided, so the description carries the behavioral burden. 'Retrieve' implies a read-only operation and 'real-time' indicates freshness, but the description does not disclose potential network activity, latency, or any operational caveats of accessing a P2P swarm.

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, focused sentence that front-loads the core action and then lists the returned data. No filler or redundant 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?

Given the tool has no parameters, no output schema, and no annotations, the description adequately identifies what the tool returns. It could be slightly more complete by mentioning that no input is required, but the context is simple enough that this is a minor omission.

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 has zero parameters, so there is no parameter ambiguity to resolve. The description doesn't need to explain parameter semantics, and the baseline of 4 applies.

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

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

The description uses a specific verb ('Retrieve') with a clear resource ('P2P WebTorrent Swarm status') and lists concrete outputs (active peer seeders, Magnet URI). It is clearly distinguishable from the sibling tools, which are all Bible/scripture related.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives, and no alternatives are mentioned. The intended use must be inferred from the tool name and the technical domain, which is not described.

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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It reveals the tool is a read operation ('Retrieves') and mentions translation limits, but it does not disclose what is returned, how alignment is handled, whether defaults apply, or any ordering/pagination behavior.

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

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

A single, grammatically complete sentence that front-loads the core action and scope. Every word contributes: the verb, the resource type, the alignment feature, the translation limit, and the language set. No filler or redundancy.

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 no output schema and no annotations, the description leaves significant gaps: no return format, no mention of default translations, no guidance on end_verse behavior, and no clarification of how 'aligned parallel' differs from sibling tools. An agent would need to inspect schemas or invoke the tool to understand expected outcomes.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value for the translations parameter by specifying a maximum and example languages, but it does not elaborate on book, chapter, verse, or end_verse semantics beyond what the schema already provides.

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

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

The description uses a specific verb ('Retrieves'), a clear resource ('aligned parallel scripture text'), and a concrete scope ('across up to 15 translations'). It clearly states what the tool does, though it does not explicitly distinguish it from similar siblings like compare_translations_diff or get_interlinear_verse.

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

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

No guidance is given on when to use this tool versus alternatives. With 27 siblings including several scripture-text retrieval tools, the description offers no selection criteria, exclusions, or context hints, leaving the agent to infer usage from the name alone.

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

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

There are no annotations, so the description carries the full burden. It indicates a read-only retrieval operation and that the result is paired data, but it does not go beyond that to mention behavior around the 'all' topic value, result limits, or error handling. This is adequate but thin for a tool with no annotation support.

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

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

The description is a single, front-loaded sentence with the verb first and no filler. Every word contributes to conveying the tool's specific purpose.

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

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

For a simple one-parameter tool with full schema coverage and no output schema, the description gives enough functional understanding. The result shape is only described as 'matched pairs,' which is sufficient, though slightly more detail about the 'all' option 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%; the single parameter is fully documented with examples and the 'all' sentinel. The tool description adds no additional parameter-level meaning, 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?

The description uses a specific verb ('Retrieves') and names the exact resource: matched pairs of Old Testament Messianic Prophecies and their New Testament fulfillments. This is a distinct function that clearly separates it from siblings like get_cross_references or search_topic, and it is not a tautology.

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 intended use is implied through the purpose statement, but there is no explicit guidance on when to choose this tool over alternatives like get_cross_references or find_thematic_scripture_chain. No exclusions or when-not-to-use conditions are provided, so guidance exists only by 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?

With no annotations provided, the description carries the disclosure burden. It clearly indicates a read-only lookup and names the returned data types, but it leaves out behavioral details such as how invalid or unsupported Strong's numbers are handled and whether both Greek and Hebrew entries are always available.

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

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

The description is a single, focused sentence that front-loads the action and resource. Every phrase contributes meaning, with no wasted words or repetition of schema details.

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 one-parameter lookup with no output schema, the description adequately names the returned content: etymology, transliteration, and definition. It is slightly incomplete because it does not clarify the boundary with get_strongs_etymology or describe behavior for unrecognized word_id values.

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 input schema already documents word_id thoroughly with a description and examples ('H1254', 'G26'), and schema description coverage is 100%. The description's mention of Greek/Hebrew and Strong's reinforces the parameter meaning but does not add meaningful new semantic information.

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

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

The description uses a specific verb ('Look up') and a clear resource: original Greek/Hebrew root etymology, transliteration, and definition via Strong's Concordance. It is clear about what the tool returns, but it does not explicitly distinguish itself from overlapping siblings such as get_strongs_etymology or analyze_greek_hebrew_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?

There is no guidance on when to use this tool versus alternatives. It does not mention related tools like get_strongs_etymology or explain which scenarios favor this lookup, so the agent must infer usage from the tool name alone.

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

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

No annotations are provided, so the description carries the full burden of describing behavior. It mentions data sources and examples, but does not disclose what the tool actually returns, whether it is read-only, how results are structured, or any limitations. The examples hint at word distinctions, but that is not enough to predict the tool's behavior.

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

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

The description is a single compact sentence with no filler and includes useful examples. However, it is structured as a marketing-style resource list rather than a function description that opens with a verb and expected result.

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 no output schema and no annotations, the description should explain what happens when the tool is called. It does not clearly state that this is a lexical/etymological lookup, what response the agent can expect, or how it differs from the many sibling tools. The ambiguity of 'Comprehensive Strong's Concordance' could mislead an agent into thinking this is a concordance search rather than a word-study lookup.

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

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

The schema already provides 100% coverage for the single parameter with clear examples ('G26', 'G0025', 'H1254', 'H7225'). The description adds no parameter-specific meaning beyond reinforcing the Strong's context, so the baseline 3 is appropriate.

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

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

The description identifies the resource domain—Strong's Concordance, BDB/Thayer lexicons, and Trench's Synonyms—and gives helpful examples, so an agent can infer what content is involved. However, it never states the action 'get etymology' or explicitly says what the tool returns for a given strongs_id; it is more of a content summary than a behavioral description.

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

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

No guidance is given about when to use this tool versus the closely related siblings get_strongs_definition and analyze_greek_hebrew_word. The agent must infer usage from the tool name and vague resource description.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly implies a read-only retrieval operation and reveals the special 'all' catalog behavior, which is useful. However, it does not describe return shape, pagination, error behavior for unknown translation IDs, or any other operational details.

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

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

The description is a single well-structured sentence that places the core purpose first and appends the 'all' behavior in parentheticals. There is no redundancy or wasted 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?

The tool has one optional parameter and no output schema, and the description gives a reasonable overview of the returned metadata. However, without annotations or output details, the description stops short of fully preparing the agent for the response structure or edge cases. It is adequate for basic invocation but not fully complete.

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

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

The schema already fully documents the single parameter with examples ('UBIO', 'UKRK', 'KJV', 'all'), and schema coverage is 100%. The description does not need to repeat parameter meaning, but it also does not add any additional semantic insight beyond what the schema provides.

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

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

The description uses a specific verb ('Retrieves'), names an exact resource ('historical, philosophical, and textual basis metadata for Bible translations'), and adds the special 'all' behavior for a complete catalog. This gives the agent a clear understanding of what the tool does and distinguishes it from sibling tools like get_verse or compare_translations_diff.

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 explains what the tool does but does not state when to use it versus alternatives. It provides no explicit conditions, exclusions, or references to sibling tools, leaving the agent to infer when translation metadata is needed instead of verse content, commentary, or cross-references.

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?

With no annotations, the description carries full behavioral disclosure burden, but it only states the inputs and not the output, required parameter combinations, or language default behavior. The mention of a 'full reference string' is ambiguous because no corresponding reference parameter exists in the schema, leaving the agent uncertain how that input mode is expressed.

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

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

The description is a single, front-loaded sentence with no wasted words. It communicates the core operation and the two accepted input modes efficiently.

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

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

The tool is simple, but the description omits which parameters are actually required to perform a retrieval and does not clarify the language default or response shape. The schema marks all parameters optional, so an agent still needs guidance on minimal valid calls; the description does not fully provide this.

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 documents book, chapter, verse, and language clearly. The description adds the full-reference-string concept, but this is not reflected as a schema parameter, so its added value is neutral at best and potentially confusing.

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

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

The description uses a specific verb ('Retrieve') and resource ('exact verse') and clearly identifies the inputs: book abbreviation, chapter, verse number, or a full reference string. This makes it distinct from sibling tools like get_chapter_context or get_parallel_verses, which target different retrieval scopes.

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

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

The phrase 'Retrieve exact verse' clearly implies this tool is for precise reference-based lookups, not for searching or thematic exploration. It does not explicitly name alternatives or exclusions, but the intended use case is reasonably clear from the description.

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?

With no annotations provided, the description carries the full responsibility for disclosing behavior. It clearly states the normalization behavior and illustrates it with an example. It does not discuss edge cases or side effects, but for a simple text transformation tool, the description adequately reveals what happens.

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 that front-loads the core purpose and includes a helpful, specific example. Every word earns its place; there is no filler or redundant restating 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?

For a one-parameter transformation tool with no output schema, the description covers the input and the transformation. It does not explicitly state the return value (sanitized Markdown), but that is strongly implied by the name and description. The example clarifies the expected output format sufficiently.

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 input parameter is already documented. The description adds a transformation example but does not introduce any additional parameter semantics beyond what the schema provides. This matches the baseline for fully-covered schemas.

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 ('Normalizes') and resource ('LLM response text') and gives a concrete before/after example of the broken bold asterisk syntax it fixes. This clearly distinguishes it from all sibling tools, which are biblical content retrieval tools rather than text-formatting utilities.

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 indicates this is used to clean up LLM-generated Markdown, which implies post-processing scenarios. No explicit exclusions are given, but since no sibling tool performs similar sanitization, there is no real alternative to confuse it with. The usage context is reasonably clear.

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?

With no annotations, the description carries the full behavioral burden. It discloses the exact-text FTS5 behavior and OT/NT scope, which is useful, but remains silent on default translation, ranking, case/accent handling, and result 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?

One sentence with no filler, and the core mechanism and scope are front-loaded. Every word earns its place.

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

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

The tool sits among many search-related siblings and has no output schema, yet the description gives no usage differentiation and no return-format notes. The schema covers parameters, but the operational context is incomplete for an agent choosing among similar tools.

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

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

All three parameters are described in the input schema (100% coverage), so the schema does the heavy lifting. The description adds only the context that the search spans the Old and New Testaments, not parameter-level detail beyond the schema.

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

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

The description uses a specific verb ('search') and resource ('Old & New Testaments'), and the FTS5 qualifier makes it distinct from sibling semantic/topic search tools even without naming them. The operation and scope are immediately clear.

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

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

No sentence indicates when to choose this tool over search_semantic, search_topic, or search_scripture_hybrid, and no exclusions are given. The only usage signal is the implicit keyword-vs-semantic distinction, which an agent must infer.

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?

No annotations are present, so the description carries the full burden of explaining behavior. It reveals the internal search mechanism (FTS5, lemmatization, vector search) but fails to state key operational traits: whether it's read-only, how results are combined or returned, any rate limits, or what happens with language-specific queries. The mechanism is described, but the observable behavior is not.

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

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

The description is a single, dense sentence with no filler. The core term 'Hybrid search' is front-loaded, and the rest of the sentence efficiently enumerates the distinguishing technical features. Every word provides substantive 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?

Given no annotations, no output schema, and over 25 sibling tools, the description is notably incomplete. It does not explain how to choose this over search_keyword or search_semantic, does not describe the return format, and omits behavioral details an agent would need to invoke it correctly. The mechanism-oriented text cannot compensate for missing operational and decision-making context.

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 effectively 100%, with all four parameters having descriptions. The description adds useful context for the 'language' parameter (Ukrainian morphology lemmatization) and 'mode' (hybrid components), but it does not explain parameter interactions or provide format details beyond what the schema already states. Baseline 3 is appropriate.

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

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

The description states a specific verb ('search') and identifies the resource implicitly via the tool name, then distinguishes the tool by naming its three technical components (FTS5 BM25, Ukrainian lemmatization, vector relevance). This clearly separates it from lexical-only and semantic-only siblings, though it never explicitly says 'scripture' or what the output looks like.

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 gives no guidance on when to use this tool versus alternatives like search_keyword or search_semantic. The hybrid nature implies a use case combining lexical and semantic needs, but no explicit when-to-use, when-not-to-use, or alternative routing is provided.

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?

With no annotations, the description carries the full burden. It discloses the conceptual search behavior, but does not explain whether results are ranked, how many are returned, whether exact concept matching is required, or whether it handles related terms. This is adequate but not detailed.

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

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

One sentence with examples; every element earns its place. The examples clarify the intended thematic space without extra fluff.

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

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

For a simple single-parameter search tool without an output schema or annotations, the description covers the core purpose and parameter semantics. It lacks return format/pagination/ranking details, but the simplicity of the tool makes the description minimally viable.

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

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

Schema coverage is 100%, so the schema defines the necessary parameter. The description adds semantic context by framing the parameter as an existential or theological theme and gives examples (anxiety, grief, forgiveness), which helps the agent choose appropriate values.

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

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

The description identifies a specific verb ('Search') and resource ('canonical verses') with thematic scope ('existential/theological themes'), which is clear. However, it doesn't explicitly differentiate from siblings like search_topic or search_keyword, so it isn't a full 5.

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

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

The description implies when to use it: when searching for verses by existential or theological themes. But it provides no explicit guidance about when not to use it or alternatives like search_topic or find_scriptures_by_life_situation, leaving selection partially 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It only states the basic retrieve action; it does not mention output format, default limits, read-only safety, or any constraints beyond being 'canonical' and 'major' topics. This is a meaningful gap for a tool with no annotation 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 a single, tight sentence with no wasted words. It is concise and front-loaded, though it omits some potentially useful context that would make it fully self-contained.

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 two-parameter retrieval tool with no output schema, the description gives a minimally workable high-level idea of what is returned. However, it does not clarify the return shape (e.g., verse text, references, counts) or default pagination behavior, leaving some ambiguity for an agent.

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

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

Schema description coverage is 100% (both 'topic' and 'limit' have descriptions), so the baseline is 3. The tool description adds no additional meaning about parameter usage or formatting beyond what the schema already provides.

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

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

The description uses a specific verb ('Retrieve') and resource ('canonical verses categorized under major biblical topics'), clearly indicating what the tool does. It does not explicitly name or differentiate from sibling search tools like search_keyword or search_semantic, so it stops short of a 5.

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

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

The description gives no guidance on when to use this tool versus the many sibling search tools. There is no mention of alternatives, conditions, or exclusions; usage is only implicitly tied to the 'topic' parameter.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it clearly indicates a mutation ('Set'), it does not explain what the score actually affects, whether the setting persists, or what higher versus lower values mean for behavior.

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

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

The description is a single sentence, front-loaded with the action verb, and contains no wasted words. It is appropriately minimal for a one-parameter setter.

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 and the schema covers the parameter, so the description is not grossly incomplete. However, it lacks value semantics (what does 0 versus 100 mean?) and does not clarify the practical effect of setting the score, which an agent would need to use it confidently.

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

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

Schema coverage is 100%, so the schema already documents the single parameter and its range. The description essentially repeats the 0-to-100 range without adding meaning about how the score is interpreted.

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 ('Set') and a specific resource ('pastoral/ethical warmth sensitivity score') with a clear numeric range. It is distinguishable from sibling setters like set_response_mode and set_show_metrics by naming the setting it changes.

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

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

There is no guidance about when to use this tool versus other configuration tools, nor is there any context about how it interacts with response mode or metrics settings. The intended use must be inferred from the tool name and sibling context.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states that a mode is set. It does not explain whether the setting persists, whether it affects only subsequent responses, or whether it resets to a default, leaving the actual side effects and scope ambiguous.

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

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

The description is a single, front-loaded sentence with no filler words. It is appropriately sized for a simple one-parameter configuration tool, and every word contributes meaning.

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

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

For a one-parameter tool with full schema coverage, the description plus schema is minimally sufficient for an agent to call it, but the lack of annotations and output schema leaves the behavior and effect scope under-specified. A brief sentence about what 'active' mode applies to would complete the context.

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 mode parameter's allowed values are already fully enumerated in the schema. The description adds 'active' and 'response depth' context but no additional syntactic or semantic detail beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description 'Set active AI response depth mode' clearly identifies a specific verb and resource: it changes the AI response depth mode. It is distinguishable from the many search/retrieval siblings, though it does not explicitly differentiate from other setter tools like set_relevance_sensitivity or set_show_metrics.

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

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

The description provides no guidance on when to use this tool, when not to use it, or how it relates to sibling configuration tools. The mode values in the schema imply intent, but there is no explicit usage context or alternative mention.

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?

With no annotations at all, the description carries the full disclosure burden. It does disclose the core toggle behavior and the visible suppression effect, which is the essential trait. However, it leaves unstated whether the setting persists across responses, which parameter wins if both status and enabled are passed together, and what happens when neither is supplied — gaps an agent would want for a state-setting 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 with zero filler. The primary purpose is front-loaded in the first sentence, and the second carries the single operational instruction an agent needs. Every word earns its place.

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

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

For a simple two-parameter toggle with a fully documented schema and no nesting, the description is nearly complete: it states the function, the affected UI element, and the suppression path. The minor omissions — persistence scope and parameter precedence — prevent a perfect score, but an agent can invoke this tool correctly with very high confidence.

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 and the baseline is 3. The description does add a genuinely useful insight beyond the schema — that enabled:false and status:'off' are interchangeable ways to suppress the footer — which clarifies the relationship between the two parameters. This is helpful but modest, so it does not exceed the baseline.

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 (enable or disable) on a specific resource (the end-of-response metrics badge footer) and enumerates exactly which metrics are affected: 'Complexity', 'Mode', 'Accuracy'. This avoids ambiguity and cleanly separates it from sibling config tools such as set_response_mode and set_relevance_sensitivity, which target different settings.

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 usage context is explicit and self-contained: invoke this tool when the end-of-response metrics footer needs to be toggled on or off. It stops short of naming alternatives or giving explicit when-not-to-use conditions, but the precisely named resource and action make the intended use unambiguous against its set_* siblings.

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