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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral value beyond that: it discloses the dataset breadth (1,100+ persons), the return shape (family tree with generation numbers and relationship types), and an extra artifact (a Mermaid diagram).

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

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

Front-loaded with the core purpose, and the sibling routing note is placed last where it belongs. Slightly verbose in the third paragraph's list of example questions, but every sentence still carries routing or output 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?

No output schema exists, but the description compensates by describing the return (family tree with generation numbers, relationship types, Mermaid diagram). Combined with 100% schema coverage and annotation-declared safety, an agent has enough to call it correctly; only pagination/size limits are unaddressed.

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

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

Schema description coverage is 100% and each parameter (person, direction enum, generations) is already documented, so the baseline is 3. The description reinforces direction ('ancestors and/or descendants') and generational depth conceptually but adds no syntax, defaults, or edge-case rules 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 ('Trace') and resource ('genealogy') with scope spelled out ('ancestors and/or descendants across multiple generations'). It also differentiates itself from the sibling lookup_name by describing that tool's single-generation behavior.

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

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

Explicitly names the alternative ('lookup_name') and the condition that selects it ('For a single generation ... immediate family without the traversal'). It also enumerates the question types this tool is meant for (Abraham-to-David line, tribal ancestry, Messianic lineage), leaving little to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral content beyond that: per-event location and date where known, plus a Mermaid timeline diagram, which tells the agent what the payload looks like. It stops short of noting limits (e.g., sparse dating or large event lists), hence not a 5.

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

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

Front-loaded purpose, then return shape, then disambiguation – a sensible order with no filler. The Moses/Paul enumerations are illustrative rather than essential, so it is not as tight as it could be.

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

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

No output schema exists, so the description correctly carries the burden of describing return values (event, location, date, timeline diagram) and it does. Combined with a fully documented single parameter and clear sibling routing, nothing needed to invoke it is missing.

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

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

Schema description coverage is 100% and the single `person` param is fully documented with examples in the schema. The description adds no syntax, format, or edge-case meaning about the parameter, 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?

Specific verb+resource with scope: 'Retrieve the recorded events of a biblical person's life in chronological order.' The ordering constraint and illustrative returns (Moses, Paul) make the tool's function unambiguous and separable from siblings.

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 claims exclusivity ('the only tool covering event sequence and dating for a person') and routes alternatives by function: `lookup_name` for identity/relationships, `explore_genealogy` for lineage. This is exactly the when/when-not/alternatives guidance the dimension asks for.

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), but the description goes further by disclosing the exact return payload (events, people, geography, Mermaid diagram) and concrete worked examples for Jerusalem and Mount Sinai. This is valuable behavioral context the annotations do not provide.

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

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

Front-loaded with the core action, then returns, then two illustrative examples, then usage context and the sibling pointer. Every sentence earns its place and none is redundant.

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

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

There is no output schema, so the description must carry the return-value burden itself, which it does by specifying events, people, geographic data, and a Mermaid diagram. Combined with the named sibling for scope comparison, an agent has everything needed to call it correctly.

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

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

With a single parameter and 100% schema description coverage (the schema itself supplies examples like Jerusalem, Bethlehem, Egypt), the baseline is 3. The description reinforces what a place yields but adds no new syntax or format constraints 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 (retrieve) and resource (full biblical history of a place), then enumerates exactly what comes back: events, births/deaths, geographic data, and a Mermaid diagram. It also distinguishes itself from the sibling lookup_name, so an agent can select it without opening either schema.

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

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

Explicitly names the triggering context ('questions about biblical geography or a location's significance across salvation history') and routes to the alternative, noting lookup_name with type="place" returns only basic info and immediate connections. This is a clear when-to-use plus when-to-use-the-other statement.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: which relationship types are traversed, that the result is a Mermaid flowchart, and that a no-connection case is reported.

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

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

Front-loaded with purpose, then method, then two concrete examples, then routing guidance. Slightly long with two examples, but each sentence earns its place and nothing is redundant.

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

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

With no output schema, the description compensates fully by specifying the return format (Mermaid flowchart), the traversal relationship types, and the empty-result behavior. An agent has everything needed to call and interpret it.

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

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

Schema coverage is 100% with two simple string params, so the schema carries the burden and baseline 3 applies. The description does not add syntax or format detail beyond what the schema already provides for person1/person2.

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

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

States a precise verb (trace) and resource (shortest family relationship path between two biblical people), and explicitly names the sibling tool explore_genealogy as the differentiator. An agent can distinguish it from every other sibling without opening a schema.

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

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

Gives explicit context ('Relevant for questions about how two named figures relate') plus a named alternative with its divergence ('explore_genealogy returns one person's ancestors or descendants rather than a path between two people'). This routes the agent cleanly between the two.

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), and the description goes well beyond them: it discloses the embedding-precondition on the input verse, the ranking by similarity score, and a substantial caveat about what the score cannot distinguish (quotation vs. allusion vs. shared tradition vs. coincidental overlap). That is exactly the kind of epistemic-limit disclosure annotations cannot carry.

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

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

Front-loaded with purpose, then mechanism, then concrete worked examples, then the caveat. The four example pairs are illustrative and earn their space, but the passage is long and the caveat paragraph, while valuable, could be tightened without losing 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?

No output schema exists, yet the description conveys the return shape (passages ranked by similarity score), the mechanism, the precondition, and the interpretive limits of the score, plus where to go next. Nothing needed to call or correctly interpret this tool is missing.

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

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

Schema description coverage is 100%, with 'reference' and 'limit' (default 10) both documented in the schema itself. The description adds the embedding requirement for 'reference', which is meaningful, but gives no guidance on how to choose 'limit' or what values are sensible. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb+resource ('Find passages with similar semantic content to a given Bible verse') and explicitly contrasts the mechanism with siblings: 'Matching is by vector embedding rather than shared vocabulary, so it surfaces connections that explicit cross-reference indexes and word searches miss.' An agent can distinguish it from get_cross_references and word_study without opening a schema.

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

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

Establishes the precondition ('a verse reference with a pre-computed embedding') and routes the agent to follow-up tools (lookup_verse, get_study_notes, get_ane_context, get_cross_references) for interpreting results. It stops short of an explicit 'use this when / not when' rule against graph_enriched_search or find_connection, which are the closest conceptual alternatives.

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/idempotent/non-destructive, so safety is covered. The description adds real behavioral detail beyond that: no-argument calls return the available dimensions and periods, a reference alone returns all matching context, and the ane_methodology dimension returns the derivation hierarchy and confidence calibration. It doesn't describe result size or pagination, but for a local read-only tool this is solid.

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

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

Purpose is front-loaded, but the body is bloated: a 17-bullet list that includes vague catch-alls ('Any passage where modern Western assumptions might obscure the ANE meaning'), plus a full re-enumeration of the 13 dimensions and 9 periods that the input schema already defines as enums. Those enumerations are pure duplication and could be dropped.

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 explains return behavior and detail-level semantics well enough for an agent to call the tool correctly, and annotations cover the operation's safety profile. Only minor gaps remain (result volume, how hits are keyed to a reference).

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 earns above baseline by explaining the default/empty-argument behavior (returns available dimensions and periods), how dimension and period narrow the result set, and the special semantics of 'ane_methodology' — none of which the schema conveys.

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 first sentence states a specific verb and resource ('Get Ancient Near East (ANE) cultural and historical background for a biblical passage') and the scope is unmistakably distinct from most siblings. However, it never names or contrasts with plausibly-confusable siblings such as get_bible_dictionary, get_theology_context, or get_torah_weave, leaving the agent to infer the boundary.

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

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

The 17-item 'Relevant to passages involving...' list is essentially an explicit when-to-use trigger catalogue, which is unusually actionable. It lacks any when-not-to-use or alternative-routing guidance (e.g., 'for lexical data use word_study instead'), so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered structurally. The description adds real value by disclosing corpus size (500+ articles) and the return shape ('full dictionary article with cross-references'), but does not cover lookup-miss behavior or availability constraints.

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

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

Front-loaded with the core action, then a scannable bullet list of article categories, then the return note. The 'Relevant for' sentence partially restates the bullet list, which is mild redundancy but not 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?

For a single-parameter read tool with full schema coverage, annotations covering safety, and no output schema, the description supplies both the corpus scope and the return format. The main gap is routing guidance against the many context/lookup siblings.

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

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

Schema description coverage is 100% and the single 'topic' parameter is documented with four example values in the schema itself. The description adds nothing about matching behavior (exact vs. fuzzy topic match, singular/plural), so the baseline 3 applies.

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

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

States a specific verb and resource ('Look up a topic in the Tyndale Bible Dictionary') and enumerates the corpus scope (people, places, doctrines, customs, history, archaeology). It is clearly a reference-lookup tool, but it does not name which sibling to prefer when the same topic could be served by get_key_terms, get_ane_context, get_theology_context, or get_study_notes.

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 'Relevant for...' sentence gives use cases (background, historical/cultural context, person/place/concept article, theological definition), which implies when to reach for it. However, it names no alternative and no exclusion, so the agent must infer how this differs from the overlapping context tools in the sibling list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds substantial behavioral context beyond them: tier rankings, suppression behavior, source-specific strength scales, scholarly provenance, and the meaning of short result sets. No text contradicts the annotations.

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

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

The description is long but well-structured with bold headers, explicit modes, and front-loaded usage instructions. It is appropriately detailed for a complex multi-dataset tool, though the extensive tier and score-scale explanations push against strict conciseness.

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 five optional parameters, no output schema, and a complex ranking system across four datasets, the description supplies all context needed to call the tool correctly and interpret its results. It covers modes, defaults, caveats, score scales, and alternatives in enough depth to prevent misuse.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema for all five parameters: limit is a cap not a target, min_strength sets a TSK floor and disables default suppression, source restricts to a dataset, theme selects curated doctrinal chains, and reference triggers the primary mode. It also explains how those parameters interact.

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 precise verb+resource: retrieve cross-references for a Bible reference or a curated chain for a doctrinal theme. It distinguishes the two primary modes and names sibling/alternative tools such as find_similar_passages.

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

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

It gives explicit guidance on when to use reference vs theme, when to restrict by source, when to raise limit or set min_strength to reveal the long tail, and when to prefer find_similar_passages or source='ch'. The coverage caveat and adaptive-default explanation remove ambiguity about result counts.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful content context beyond that — the ~200-term scope and the kinds of information returned (definitions, usage, cross-references, translation guidance) — which matters since there is no output schema.

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

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

Front-loaded with the core purpose followed by a scannable list of contents and use cases. The 'Relevant for...' section partly restates the feature bullets above it, so there is mild redundancy, but overall it is well-sized and easy to parse.

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

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

For a one-parameter read tool with annotations covering safety and no output schema, the description supplies adequate content and use-case context to call it correctly. The main missing element is explicit disambiguation from the many sibling lookup 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?

With a single parameter at 100% schema description coverage, the schema already documents 'term' with its own examples ('agape', 'atonement', 'covenant', 'grace'). The description reinforces the example terms but adds no format, casing, or matching semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('look up') and resource ('key theological term in the FIA Key Terms database'), and previews the content type (definitions, biblical usage, cross-references, translation guidance). However, it does not differentiate from closely related siblings like get_bible_dictionary, get_theology_context, or word_study, leaving the agent to infer which source to consult.

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 'Relevant for...' list implies usage (precise definitions, cross-Scripture usage, translation-oriented explanation), which gives contextual guidance. But it never states when to prefer this tool over the many alternative theology/lexicon tools, nor any exclusions, so the routing decision is left implicit.

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

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

Annotations already declare readOnlyHint/idempotent/non-destructive, so safety is covered. The description adds genuine behavioral context beyond that: the content is published scholarship quoted as-is with source attribution, and it is a merged output from three named corpora.

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

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

Front-loaded verb+resource sentence, then a compact bullet list of sources and one relevance sentence. The bulleted source list is mildly verbose but each entry earns its place by distinguishing the corpora.

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 no output schema and 100% schema coverage, the description is nearly complete: it explains content sources, scope, and use cases. Only the return shape/nesting of combined commentary is left implicit, which is minor given the annotations.

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 reference and chapter_only are already documented in the schema. The description's mention of verse-level versus chapter-level overviews loosely corresponds to chapter_only but adds no syntax or default details 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 (Get) and resource (scholarly study notes and translation notes) scoped to a Bible verse or chapter, and enumerates the three distinct source corpora (Tyndale, UW, SIL) so the agent knows exactly what content comes back. This is meaningfully different from siblings like get_key_terms or get_ane_context.

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 'Relevant for...' sentence gives clear when-to-use conditions: published commentary on a specific verse, difficult passages, translation/cultural background, and chapter-level overviews. It stops short of naming alternatives or stating when NOT to use it versus the many sibling context tools.

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

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

Annotations already declare readOnlyHint/idempotent/destructive, so the safety profile is covered. The description adds substantial context beyond that: the exact returned fields (MT reading, variant reading, witnesses, scholarly consensus, HLT preferred reading and rationale), the HLT interpretive principle, and that 'Either side of a pair returns the same variant row' — behavior an agent could not infer from annotations alone.

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?

Long but well-structured with a clear return-value list and front-loaded purpose. The covered-verses enumeration and HLT rationale are relevant, though the HLT discussion is somewhat expansive relative to invocation needs, keeping it short of ideal conciseness.

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, the description carries the return-value burden and does so thoroughly, enumerating every returned field and even the interpretive principle behind the preferred reading. An agent has everything needed to call it correctly and interpret results.

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

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

Schema coverage is 100% and the single 'reference' parameter is fully described there, including the OT/NT examples and the same-row note. The description restates this implicitly but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Retrieve') and resource ('the textual variant record for a verse where the Masoretic Hebrew, the Septuagint, and/or the Dead Sea Scrolls diverge'). This scope is distinct from siblings like lookup_verse and get_cross_references, so an agent can disambiguate without opening schemas.

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

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

Gives clear conditions for use: 'Relevant where a New Testament quotation does not match the modern English Old Testament' and for questions about how Hebrew/Greek/Qumran traditions differ at a verse. It also routes to a sibling by noting 'lookup_verse reports when a verse has a quotation hint or variant row,' though it never states an explicit when-not or names a direct alternative to choose instead.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds non-annotation context: aggregation across authors, the author-omitted comparison behavior, and that results carry verse mappings and theme links. It stops short of describing pagination or result ordering.

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

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

Front-loaded with purpose and return behavior, then the coverage list. The list is long but each bullet pairs a topic with its author and theme key, so it earns its space as query-construction reference rather than padding.

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

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

With no output schema, the description carries the return-value burden, and it does state the content shape (scholarly content per author, verse mappings, theme links). Limits and defaults come from the schema. Adequate for an agent to call correctly, though result ordering/format detail is absent.

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

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

Schema coverage is 100%, so a baseline of 3 applies. The description goes beyond the schema by mapping real topics to the exact 'theme' keys and 'author' values that hold them (e.g., domain_transfer/bradley, penal_substitution/owen), which materially helps an agent compose valid queries.

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

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

States a specific verb and resource ('Get theological scholarship context for a Bible passage or theme') and immediately names the return shape (multiple authors, verse mappings, theme links). The topic coverage list makes it unmistakably distinct from siblings like get_bible_dictionary, get_ane_context, and get_study_notes.

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 explains query modes ('Query by verse reference, theme key, and/or author') and the key behavioral fork: omitting author returns all scholars for side-by-side comparison. It lacks explicit when-not-to-use guidance or routing against the 22 sibling tools, so it stops short of a 5.

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

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

Despite annotations covering read-only, idempotent, and non-destructive behavior, the description adds substantial context: it explains the return format as structural pointers, states that partner text is not included, notes that thematic column labels are absent, and limits coverage to Torah books. This goes well beyond the safety profile declared in annotations.

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

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

The description is long but front-loaded and clearly structured with a WHAT IT RETURNS section. The background and return details earn their place because there is no output schema, and no sentence is redundant.

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

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

For a complex, niche structural tool with no output schema, the description supplies the return shape, limits, source attribution, and an alternative tool for retrieving partner text. An agent has enough context to invoke and interpret the tool 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% for the sole reference parameter, including format examples. The description reinforces the Torah-only scope but does not add syntax, format, or edge-case guidance beyond what the schema already provides, so baseline 3 is appropriate.

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

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

States a specific verb and resource (get structurally-paired verses) and identifies the exact domain: Torah passages under Moshe Kline's Woven Torah hypothesis. It also distinguishes itself from lookup_verse, which returns the actual text, so an agent can separate this structural tool from sibling retrieval 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 lists relevant passages (Genesis through Deuteronomy), use cases (structural pairing, suspected interweaving, law parallels), and the key exclusion that pairings are compositional rather than thematic. It also names lookup_verse for text retrieval and warns that only Torah books have weave data.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful scope behavior beyond the annotations: verse-level granularity only, and that entity lists come with relationships and verse text. It stops short of return-shape, pagination, or failure behavior, so it is strong but not exhaustive.

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

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

Front-loads the core purpose and ends with the sibling differentiation, which is the highest-value sentence. The first line and second paragraph overlap ('its text plus all people, places, events, and family relationships' vs 'Returns the verse text, the people, places, and events'), costing some redundancy, but nothing is off-topic.

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, so the description must explain returns — and it does, listing verse text, people, places, events, and family relationships. Combined with the sibling routing, an agent has everything needed to call it correctly.

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

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

One required parameter with 100% schema description coverage, so the schema already documents the reference format. The description only reinforces this with the 'Matthew 1:1' example, adding no syntax beyond the schema. Baseline 3 applies when the schema carries the parameter semantics.

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

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

States a specific verb (retrieve) and resource (enriched view of a single verse) and enumerates exactly what is returned: verse text, people, places, events, family relationships. It explicitly distinguishes itself from lookup_verse and people_in_passage, so the agent can pick it without reading sibling schemas.

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

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

Names both alternatives and the conditions that separate them: it 'combines what lookup_verse and people_in_passage return separately,' and it is 'verse level only' whereas people_in_passage also takes chapters and omits verse text/relationships. When-to-use and when-not-to-use are both explicit.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds value by disclosing what the entry returns — original-language name, description, key verses, ACAI annotations, and immediate relationships (parents/children/siblings/spouse) — which goes beyond the annotations.

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

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

Front-loads the core purpose and return contents, then ends with precise sibling routing. The relationship bullet list with examples is somewhat verbose but each item clarifies scope, so it largely 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?

With no output schema, the description carries the burden of describing returns, and it does so thoroughly (fields, relationship directions, data coverage). Minor gaps remain around result limits or ambiguity handling when multiple names match, but overall it is complete enough to invoke 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%, so both parameters (name, type) are already documented in the schema. The description's examples ('Abraham, David, Bethlehem') reinforce but do not add syntax or format meaning 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 ('look up') and resource ('general information about a biblical person, place, or thing by name'), with concrete examples and scoping counts (4,000+ persons, 1,000+ places). It clearly separates itself from explore_genealogy, explore_person_events, and explore_place by 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?

Explicitly routes the agent: 'Multi-generation lineages are covered by explore_genealogy, a person's life events by explore_person_events, and a location's full history by explore_place.' Each alternative is paired with the condition that selects it, leaving little 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read operation. The description adds value by detailing the return payload (original language, morphology, Strong's numbers, genre background) and noting availability of related data, but it doesn't disclose caching, rate limits, or errors. With annotations covering the safety profile, the extra return-context is useful but not exhaustive.

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

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

Front-loads the core action and uses a bulleted returns section for scannability. It is slightly longer than necessary due to the detailed list, but every item is informative. No wasted 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?

Given no output schema and a simple read tool, the description provides a thorough description of what is returned, including optional and conditional data. It covers the main use cases. A minor gap is that it doesn't explain what happens with invalid references or how to interpret the availability notes for cross-references, but overall it is complete enough for correct invocation.

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 all three parameters. The description goes beyond by providing concrete reference format examples ('John 3:16', 'Gen 1:1', 'Romans 3:21-26') and notes that include_original is on by default, which reinforces the schema defaults. This adds practical example 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 (look up) and resource (Bible verse/verse range) and enumerates the scope of content returned, including original-language text and word-level breakdown. This clearly differentiates it from siblings like get_cross_references or word_study, which serve different functions.

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 final sentence gives a clear usage trigger: 'Relevant whenever the verified wording of a passage, or its original-language form, is needed.' It doesn't explicitly name an alternative tool or when NOT to use this, but the context is clear enough to route correctly.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description goes further by disclosing the shape of the response — part of speech, person, number, tense, voice, mood, case, gender — which compensates for the absence of an output schema. It stops short of describing error or fallback 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?

Front-loaded with the purpose, then a short per-language format breakdown, then the return fields — every sentence is relevant. The 'V-AAI-3S' example is repeated in both the description and the schema, a minor 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?

For a two-parameter, stateless read tool with no output schema, the definition is nearly complete: it names both supported code systems, the default language, and the grammatical categories returned. Only edge-case behavior (invalid or ambiguous codes, unknown language) is left unaddressed.

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

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

Schema description coverage is 100% and both parameters carry their own descriptions, examples and the greek default, so the schema does the heavy lifting. The description's worked example ('V-AAI-3S' = Verb, Aorist, Active, Indicative, 3rd person, Singular) adds decoding meaning, but it duplicates the schema's example rather than extending it.

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 ('Explain') and resource ('morphological/grammatical parsing code'), and the two formats (Robinson for Greek, Westminster/OpenScriptures for Hebrew) make the scope unambiguous. No sibling tool (word_study, search_lexicon, lookup_verse) does code decoding, so it is clearly distinguishable.

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

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

Usage is implied: call this when you have a morphology code and need it decoded. However, it never states when to prefer this over word_study or search_lexicon (e.g., after retrieving a code from a verse lookup), nor what happens with an unrecognized code. Adequate but with clear gaps.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered by structured data. The description adds genuinely new context: the backing dataset, that scope can be a chapter or a single verse, and an illustrative example of what identities come back for two passages.

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

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

Purpose is front-loaded in the first line, followed by data-source scope, examples, and sibling routing in that order. It is slightly longer than strictly needed — the two worked examples occupy most of the text — but each sentence still carries information an agent would use.

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, the definition correctly compensates by describing what is returned and giving two concrete result sets, which is adequate for a one-parameter lookup. It omits a notable behavioral detail: passages with no tagged entities presumably return empty results, which an agent should know before treating an empty list as an error.

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% with a single documented 'reference' parameter, so baseline is 3. The description's examples (Genesis 22, Acts 15) reinforce the accepted reference format but add nothing the schema description does not already state.

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

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

States a specific verb ('List') and resource ('people, places, and events mentioned in a Bible passage') and names the data source (Theographic Bible Metadata). The concrete Genesis 22 and Acts 15 examples make the scope of output unmistakable and separate it from siblings like lookup_verse or explore_genealogy.

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?

'Relevant for establishing the cast and setting of a narrative passage' gives clear usage context, and it explicitly names graph_enriched_search as the related alternative with its distinguishing property (verse-level, adds verse text and family relationships). It stops short of stating when NOT to use it (e.g., non-narrative passages), so not a full 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered without the description. The description adds some useful context about what the call yields (passages showing author usage and range of senses), but says nothing about result count behavior, ordering, or pagination beyond what the schema states.

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

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

Front-loaded with the core action in the first sentence, followed by provenance and output framing. The second sentence is somewhat elaborate in describing 'range of senses', but each sentence carries usable information and there is no filler.

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

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

With no output schema present, the description correctly compensates by describing what comes back (passages containing the word). Combined with 100% schema coverage for inputs and annotations covering safety, the definition is essentially complete; only result-count/ordering behavior 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%, so both `strongs` (with format examples G26/H430) and `limit` (default 20) are already fully documented. The description reinforces that the number is normally sourced from another tool, which is mild added value, so baseline 3 is appropriate.

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

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

States a specific verb and resource: search by Strong's number across every verse containing that word. It also distinguishes itself from the sibling tools that supply the input (word_study, search_lexicon), so an agent knows this is the concordance-lookup step rather than the lexical analysis step.

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

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

It gives clear context for use by stating the Strong's number is 'typically obtained from word_study or search_lexicon', which routes the agent through the right workflow. It does not state when-not to use it or contrast it against find_similar_passages / get_cross_references, so it stops short of full when/when-not guidance.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is already clear. The description adds useful behavioral context: results are ranked by relevance, typically return several distinct words, and include Strong's numbers, definitions, and semantic ranges. It does not mention pagination or maximum result behavior, but the schema covers the limit parameter.

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?

Well-structured and front-loaded: the first sentence states the action and search axes, the second explains the return format with a concrete example, and the third gives use-case guidance. Slightly verbose with the example, but 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?

Complete for a read-only search tool with annotations covering safety and a fully described schema. It explains what is returned and why the tool is useful, though it does not discuss result limits or how to refine an overly broad search. No output schema exists, but the description adequately describes the return content.

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 fully documents all three parameters, including the language enum and limit default. The description adds conceptual color (e.g., an English term like 'love' maps to multiple Greek words), but no extra syntax or format details beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb (Search) and resource (Greek and Hebrew lexicons) with the axes of search (English word, transliteration, concept). It distinguishes itself from siblings like search_by_strongs (which searches by number) and get_bible_dictionary (which presumably does general dictionary lookup).

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

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

The description clearly states what the tool is relevant for — identifying original-language terms behind an English word or concept, and distinguishing near-synonyms. However, it does not explicitly name alternative tools or when NOT to use this one (e.g., vs search_by_strongs or get_bible_dictionary).

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely useful behavior: matching requires every search token to match (AND semantics) and results are ranked by relevance. It does not state pagination or result-size behavior beyond the schema's limit, but the crucial matching semantics are disclosed.

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

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

Front-loaded with the core action and scope, followed by return behavior, usage contexts, and the optional filter. Every sentence carries information and none is redundant.

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

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

With no output schema, the description still covers what is returned (matching verses, relevance-ranked) and how the book filter narrows results. For a 3-param read-only search this is nearly complete; only an explicit note on default result volume/pagination is absent.

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

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

Schema coverage is 100%, so all three parameters are already documented. The description corroborates the query (Tamil text, quoted phrases allowed) and book filter ('Jhn', 'Psa') but adds no format or syntax detail beyond the schema's own examples.

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

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

States a specific verb+resource with scope: search the Tamil Bible text (Tamil IRV, full 66 books) for words or phrases. It names what it is not by pointing to `word_study` and `search_by_strongs` for original-language follow-up, so an agent can route correctly among the ~22 siblings.

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

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

Gives clear contexts — finding where the Tamil Bible uses a Tamil word, Tamil concordance work, and locating verses from remembered Tamil wording — plus an explicit hand-off to word_study/search_by_strongs. It lacks an explicit 'when not to use' or 'use lookup_verse instead when you know the reference' exclusion.

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, and the description adds meaningful behavior beyond that: the two lookup paths (direct Strong's entry vs. resolving an English word to the most relevant Greek/Hebrew term), plus the source lexicons used (LSJ, BDB, Abbott-Smith). It does not address ambiguity handling or limits on English-word resolution, so it falls short of a 5.

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

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

Purpose is front-loaded in the opening sentence, and the resolution mechanics follow before the returns list. The bulleted return inventory is long but each item is substantive rather than filler, so the length is largely earned.

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, enumerating the returned fields is exactly the right compensation and it is done thoroughly. The one unaddressed point is that all three parameters are optional, so the description never tells the agent that it must supply either 'word' or 'strongs' to get a useful result.

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 each parameter is already documented, and the enum on language is explicit. The description adds only a light implication that 'strongs' and 'word' are alternative entry paths, without stating precedence or that all three parameters are optional, so it sits at the schema-driven 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 first sentence names a specific verb ('look up') and resource ('lexicon entry') and scopes the accepted inputs (Strong's number or Greek/Hebrew/English word). It is clear on its own, but it never distinguishes itself from close siblings such as search_lexicon or search_by_strongs, which is what would push it to 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 closing sentence gives concrete use cases ('questions about a specific original-language term, a theological term's underlying vocabulary, or the semantic range behind an English rendering'), which is real when-to-use guidance. It stops short of naming when NOT to use it or pointing to the sibling tools that overlap.

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