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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful behavioral context beyond those: the translation table is mostly empty, total_editions is usually 0, text_pali and text_english are always populated, and Thai editions are planned. This clarifies the tool's actual output behavior beyond the safety profile.

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?

Although the description is longer than average, every section earns its place: a one-line summary, usage bullets, a direct sibling comparison, a format spec with example, and a critical data-state warning. The structure uses headings, bullets, and emoji to make scanning easy, and the most important information is front-loaded.

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

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

The description is complete for a single-parameter read-only comparison tool. It covers purpose, when to use, versus siblings, segment_id format, and current data limitations. An output schema exists, so the description does not need to explain return values; instead it adds contextual caveats that are essential for correct interpretation of 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 schema already describes segment_id with examples, but the description adds more: the exact segment_id format `<sutta_id>:<paragraph>.<line>`, a concrete example with meaning (mn1:171.4 – 'Nandī dukkhassa mūlaṁ'), and guidance on finding segment_ids via get_sutta or search results. This goes well beyond the schema's basic example.

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

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

The description opens with a specific verb and resource: 'Compare every available translation for a single segment.' It clearly differentiates from the sibling tool get_sutta by explicitly stating this tool targets a single segment (line level) while get_sutta returns the whole sutta.

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

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

The description provides explicit 'Use this tool when' bullet points and an 'vs get_sutta' section naming the alternative and explaining when to prefer each. It also includes a caveat about the current database state, which helps set expectations about when the tool is useful.

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 it's safe. The description adds useful behavioral context that it returns metadata + citation only (no segments), 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?

The description is concise and well-structured: a single clear opening sentence, a short bullet list for usage, and a sibling comparison. No wasted words, and the most important info is front-loaded.

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

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

For a simple one-parameter tool with a full output schema and strong annotations, the description fully covers purpose, usage, and relationship to siblings. It leaves no ambiguity about when to use this tool.

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

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

Schema coverage is 100% with the parameter description providing examples. The description does not add parameter-specific details beyond the schema, but it doesn't need to; 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 clearly states the tool's purpose with a specific verb+resource: 'Build a proper citation string for a sutta.' It also explicitly contrasts with the sibling tool `get_sutta`, which sets it apart as a citation-only tool.

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

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

The description includes a 'Use this tool when' list with concrete use cases (academic work, canonical location, formatted citation) and explicitly compares to `get_sutta`, clarifying when to use each and when to combine them.

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, destructiveHint=false, and idempotentHint=true. The description adds significant behavioral context beyond annotations: default behavior returns all segments, pagination warnings, coverage of pitakas, behavior of mode parameters, and status of Thai fields. There is no contradiction with annotations.

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

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

The description is lengthy but well-structured with clear sections (⚡, 📑, ✅), emojis, and bullet points. Every section serves a purpose, but some redundancy exists (e.g., repeated emphasis on not fetching full sutta). It earns a 4 for being organized and scannable despite its verbosity.

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's complexity (9 parameters, output schema exists), the description covers all essential aspects: mode selection, pagination, citing guidelines, coverage across pitakas, and parameter restrictions. It includes examples for each parameter and integrates well with sibling tools. The description leaves no gaps for an agent to misuse the tool.

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

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

Schema description coverage is 100%, giving a baseline of 3. However, the description adds substantial value by providing concrete examples for each parameter (sutta_id formats, language options, mode choices), explaining interactions (only one selector at a time), and detailing pagination behavior. This far exceeds the minimal schema descriptions.

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

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

The description clearly states the tool fetches a sutta's content or table of contents, specifying the verb 'Fetch' and resource 'sutta'. It distinguishes between full content and outline mode, and provides concrete usage examples that differentiate it from sibling tools like search_by_keyword. The purpose is immediately clear and unambiguous.

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 extensive, explicit guidance on when to use each mode and parameter, including when to use outline vs full fetch, around for search context, segment_range for specific slices, and offset+limit for paging. It also warns against fetching entire long suttas and suggests alternatives. This is comprehensive and directly helps the agent decide the correct approach.

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 disclose read-only, idempotent, non-destructive behavior. The description adds meaningful context not captured by annotations: the source is a compilation of multiple primary dictionaries, Thai entries are original scholarly works and therefore always available regardless of ENABLED_LANGUAGES, and the AI client should translate Thai entries if needed. This gives the agent important behavioral knowledge about language availability and fallback handling.

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 slightly longer than necessary but well-structured with a preamble and a dedicated 'About the dictionary sources' section. The emoji and formatting are stylistic but not harmful. Each part contributes: purpose, role, and a critical behavioral note about language availability. It is not bloated, though the source paragraph could be tightened slightly without losing substance.

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 presence of annotations, a 100% schema-described parameter set, and an output schema, the description covers the core information: what the tool does, what sources it uses, and an important caveat about language availability. It does not cover edge cases like multi-word lookups or common failure modes, but those are likely handled by the output schema and the tool's structured response. The description is sufficiently complete for an AI agent to decide when to use it and what to expect.

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 goes beyond schema by explaining the 'language' parameter behavior in a non-obvious way: Thai entries are always available even when Thai is disabled, and the client may need to translate them. This adds meaningful semantic context to the 'language' parameter that the schema alone does not convey. However, it doesn't add details about 'word' or 'limit_context' beyond what the schema already states.

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

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

The description clearly states the action ('Look up the dictionary meaning of a Pāli word') and the added value ('with sutta context'). It distinguishes the tool as a 'Pāli Dictionary Bridge' that pairs definitions with actual usage, which differentiates it from siblings like define_from_suttas and parse_pali_word. The specific verb+resource+scope structure makes its purpose immediately obvious.

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 does not provide explicit guidance on when to use this tool versus alternatives. It positions the tool as a 'Pāli Dictionary Bridge' but never mentions sibling tools, exclusions, or scenarios where another tool would be more appropriate. There is no 'when to use' or 'when not to use' guidance, leaving the AI agent to infer usage from the purpose 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context: server-side filtering by TRIPITAKA_ENABLED_LANGUAGES, the current indexing gap for Thai editions, and the fact that the list may be empty even if editions exist. This goes beyond the annotations and helps the agent set expectations.

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

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

The description is organized with markdown headings and bullet points, front-loading the action in the first sentence. Each section (when, filtering, state, returns) earns its place, and the return field list is compact yet complete.

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's simplicity (no parameters) and the presence of an output schema, the description covers all necessary context: what it returns, how filtering works, and the current state caveat. There are no gaps that would leave an agent guessing.

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, and the schema confirms this with an empty properties object. The description correctly implies no inputs are needed; the baseline of 4 applies per the rubric.

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

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

The description opens with a specific verb and resource: 'List the translation editions available, with coverage stats.' This clearly differentiates it from siblings like compare_translations and get_sutta—it's about enumerating editions, not comparing or retrieving content. The return-field breakdown further sharpens the 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?

A dedicated 'Use this tool when' section explicitly lists two scenarios: before calling compare_translations or get_sutta(edition=...), and when the user asks which editions are loaded. This provides clear context for when to use it, though it stops short of naming explicit 'when not' cases or alternative tools beyond those indicated.

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?

Beyond the readOnly/idempotent annotations, the description discloses important behavioral quirks: legacy vs. active schema codes, the meaning of the 'active' flag, and language handling (returns Pāli/Thai/English labels regardless of enabled languages, while text follows ENABLED_LANGUAGES). This is genuinely useful context that annotations alone 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?

The description is longer than average, but it is well-structured with clear headers ('Use this tool when', 'Current state', 'Known quirks') and front-loaded with the core purpose. Every sentence adds relevant detail—coverage numbers, schema quirks, and output shape—so it earns its length, though it could arguably be tightened.

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 tool with no parameters and only basic annotations, the description is remarkably complete: it explains the full hierarchical structure, current data status, legacy-code issues, the active flag semantics, language behavior, and the return shape. Nothing important about scope or behavior is left ambiguous.

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

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

There are zero parameters, so the baseline is 4. The description compensates by detailing what the returned structure looks like (pitakas → nikayas, fields included) and clarifies the meaning of key output fields like segment_count and active, which adds value beyond the empty 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 opens with 'Show the structure of all three pitakas with coverage statistics', which is a specific verb+resource combination that clearly distinguishes this tool from search and retrieval siblings. It also indicates the unique value proposition (coverage statistics) and the scope (all three pitakas).

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 includes an explicit 'Use this tool when' section listing three concrete triggers: user asks for overview, checking coverage before promising search, and verifying scope when compiling artifacts. This gives clear guidance on when to select this tool over alternatives like survey_corpus or 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?

Annotations already declare readOnlyHint and idempotentHint, but the description adds substantial behavioral context: it is rule-based, not a full morphological analyzer, does not reverse sandhi, and returns possible stems that need verification via get_word_definition. This goes beyond the structured annotations and gives the agent accurate expectations about the tool's limitations and output.

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 well-structured with a one-sentence summary, emoji-supported sections, and explicit bullet points for usage and limitations. It is longer than necessary but each section earns its place. The minor internal contradiction adds noise and slightly detracts from conciseness, so it does not reach a perfect 5.

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

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

Given the presence of an output schema, the description does not need to explain return values. It covers when to use, recommended workflow, limitations, and verification steps, making it quite complete. However, the compound-splitting contradiction leaves a gap in understanding, preventing a perfect score.

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 has one parameter 'word' with a clear description ('An inflected Pāli word') and examples, achieving 100% schema coverage. The main description reinforces this with additional examples and context about what constitutes an inflected word, but it does not add meaning beyond what the schema already provides. 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 clearly states the core function: 'Strip Pāli inflectional suffixes to find the root form (basic stem).' This specifies the verb (strip), resource (Pāli word), and the result (root form). It also distinguishes itself from sibling tools like get_word_definition by focusing on morphological analysis rather than 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 explicitly provides 'Use this tool when' bullets, a recommended workflow, and limitations. It names get_word_definition as the alternative for looking up stems. However, there is an internal contradiction: the second bullet claims you can 'split a compound,' while the Limitations section states 'Compound words (samāsa) are NOT split.' This inconsistency undermines the clarity of usage guidance, though the overall context is still helpful.

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

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

The annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds substantial behavioral context: it searches only enabled languages, uses trigram similarity, and explains two quirks that affect results (section headings differ from teaching-body verbs, and stock phrases cause broad ranking). It even illustrates with DN22 segment counts. This goes well beyond the structured 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?

Though longer than typical, the description is extremely well-structured with emoji headers, bullet points, and a summary line up front. Every sentence carries useful information (translation hints, tool selection, search limitations). No filler or repetition exists; the density is high but purposeful.

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 complex nuances (language enablement, translation needs, and differences between keyword and hybrid search). The description addresses all of these comprehensively, including examples and counterexamples. Since an output schema exists, the absence of return-value details is not a gap. For a tool with this complexity, the description is 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 descriptions cover 100% of parameters, establishing a baseline of 3. The description adds meaningful guidance for the keyword parameter by instructing the agent to translate user terms to Romanised Pāli or English when needed, and it provides usage tips for limit (set ≥30 for surveys). It also clarifies that edition is used only with language='thai' and enabled, which augments 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 opens with a clear one-sentence definition: 'Keyword search across the Pāli Tipiṭaka (trigram word-similarity).' It names the specific verb (search), the resource (Pāli Tipiṭaka), and the method (trigram word-similarity). It also explicitly differentiates from sibling tools by stating this tool is best for exact term lookup and directing concept searches to search_hybrid.

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?

A dedicated section 'Pick the right search tool for the question shape' gives explicit decision criteria: use this tool for term lookup, use search_hybrid for concept search, and for general keyword surveys set limit≥30 or call multiple related forms. It also advises translating keywords to Romanised Pāli when the user speaks an unsupported language, including concrete examples.

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, but the description adds substantial behavioral context: RRF merging, ranking by similarity vs. canonical importance, language-specific quirks, and limit behavior. This goes well beyond annotations with no contradiction.

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 with a front-loaded definition and clearly labeled hints for the AI client. Slight redundancy between the first two sentences, but every section earns its place given the tool's complexity.

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 output schema exists and the tool's moderate complexity, the description covers usage scenarios, language handling, ranking caveats, and next-step actions. It is complete for an agent to select and invoke 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?

Although schema coverage is 100%, the description enriches parameter meaning: it advises increasing limit for topic surveys, notes English queries work best, and explains Thai stop-word weaknesses — all valuable guidance 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?

Description uses specific verb+resource: 'Hybrid search — combines keyword + semantic search via RRF.' It clearly distinguishes itself by being the recommended tool for concept queries, differentiating from keyword-only and semantic-only 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 states when to use (recommended for 'discourses about X' / concept queries), provides practical exclusions and alternatives (e.g., translate Thai queries, call get_sutta for canonical references), and gives tuning guidance like limit=15-20.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint false. The description adds valuable behavioral context: the index is Pāli-only, English queries embed better than Thai, similarity scores cluster due to stock phrases, and users should read the top 10 rather than trust rank 1. This goes beyond the structured annotations and discloses limitations honestly.

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 well-structured with a clear opening statement, a usage section with bullets, and a limitations list. It is longer than minimal, but each sentence contributes useful information; the scannable formatting keeps it efficient.

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

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

With an output schema present and annotations covering safety, the description fully addresses purpose, alternatives, limitations, and operational advice. There are no significant gaps in understanding when and how to invoke this tool.

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

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

Schema coverage is 100%, and each parameter (query, language, threshold, limit) already has a descriptive comment in the schema. The description reinforces threshold tuning and language effectiveness, but it does not add new parameter-level meaning beyond what the schema provides; 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 clearly states the tool performs semantic search by meaning rather than exact words, and specifies vector similarity over text_pali with a multilingual MiniLM model. It distinguishes itself from siblings by explicitly naming search_hybrid and search_by_keyword as alternatives.

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 explicit guidance: 'In most cases you should use search_hybrid instead' and enumerates exact conditions for using this tool (pure semantic results, fine-grained threshold tuning, debugging). It also notes when search_by_keyword is preferable for specific Pāli terms, providing clear exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description goes further by disclosing the exhaustive guarantee, exact count, per-pitaka breakdown, matched surface forms, `complete: true` flag, and the crucial caveat that semantic mode is approximate and NOT exhaustive. No contradiction with annotations.

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

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

The description is well-structured with a bolded lead guarantee, bulleted example questions, and clear separation of lexical vs semantic promises. It is concise enough for the complexity of a 9-parameter tool, and every sentence serves a distinct 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?

This is a complex tool with rich annotations, a detailed input schema, and an output schema. The description fully covers when to use it, how it differs from alternatives, its safety profile, completeness guarantees, semantic limitations, pagination behavior, and offline/hosted constraints. Nothing critical is missing.

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

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

Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds strategic context beyond the schema: the lexical guarantee holds in both modes, semantic mode is hosted-only, and `match_scope` over-matching can be audited via `matched_forms`. This elevates the parameter understanding beyond bare 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 opens with 'Exhaustively survey the WHOLE Tipiṭaka for a term — guaranteed complete', which clearly identifies the verb, resource, and scope. It immediately distinguishes the tool from its sibling `search_by_keyword` by stating it is for coverage/counting questions rather than best-passage retrieval.

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

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

Explicitly states 'Use this (not `search_by_keyword`) when the question is about coverage or counting' and provides concrete example queries. It also explains the difference in behavior (ranked, capped at 50, no total) and differentiates the lexical vs semantic modes, giving clear selection criteria.

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