Server Quality Checklist

Tool Scores

• get_corpus_statisticsC
  2.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool returns 'JSON string containing corpus statistics,' which hints at output format, but does not cover critical aspects like whether it's read-only, performance implications, error handling, or data size limits. For a tool with no annotations, this leaves significant behavioral gaps.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded, with the core purpose stated first. The additional details about args and returns are structured but slightly verbose (e.g., 'JSON string' could be more concise). Overall, it avoids unnecessary fluff, earning a high score for efficiency.

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

  Completeness3/5

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

  Given the tool's moderate complexity (1 parameter, no annotations, but has an output schema), the description is minimally adequate. The output schema likely covers return values, reducing the need for detailed output explanation. However, with no annotations and low parameter clarity, it lacks completeness in behavioral and usage aspects, making it just viable but with clear gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds minimal value: it names the parameter ('urns') and describes it as 'List of URN identifiers for documents,' but does not explain what URNs are, their format, or constraints. This is insufficient to fully clarify the parameter's meaning beyond the basic schema.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Get statistical information about a corpus of documents.' It specifies the verb ('Get') and resource ('corpus of documents'), making the function unambiguous. However, it does not explicitly differentiate from sibling tools like 'ngram_frequencies' or 'search_texts', which might also involve corpus analysis, preventing a score of 5.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description lacks context about scenarios where statistical information is needed over other operations like searching or concordance analysis. Without explicit when/when-not instructions or named alternatives, it offers minimal usage direction.

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

• find_concordancesC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns 'JSON string containing concordance results,' which adds some context about output format. However, it lacks details on permissions, rate limits, error handling, or whether it's read-only (implied but not stated). For a tool with no annotations, this is a significant gap in transparency.

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

  Conciseness4/5

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

  The description is well-structured and appropriately sized, with a clear purpose statement followed by parameter details and return information. Each sentence adds value, and there's no redundant or verbose content. It could be slightly more front-loaded by emphasizing key usage, but overall it's efficient.

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

  Completeness3/5

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

  Given the tool has an output schema (implied by 'Returns' statement) and no annotations, the description covers the basics: purpose, parameters, and return format. However, for a tool with 4 parameters and sibling tools that might cause confusion, it lacks context on differentiation, error cases, or behavioral nuances. It's minimally adequate but has clear gaps in completeness.

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

  Parameters3/5

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

  The description includes an 'Args' section that lists and briefly explains all four parameters, adding meaning beyond the input schema (which has 0% description coverage). It clarifies the purpose of 'urn' and 'word' as required, and provides default values and intent for 'window' and 'limit'. However, it doesn't elaborate on URN format, word case-sensitivity, or constraints, leaving some semantic gaps.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Find concordances (contexts) for a word in a specific document.' It specifies the verb ('find'), resource ('concordances'), and scope ('for a word in a specific document'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'word_concordance' or 'search_texts', which appear related, preventing a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With sibling tools such as 'word_concordance' and 'search_texts' that might overlap in functionality, there's no mention of specific contexts, exclusions, or comparisons. Usage is implied only by the purpose statement, lacking explicit direction.

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

• lookup_word_formsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return format ('JSON string containing different word forms'), which adds some context, but lacks details on error handling, rate limits, authentication needs, or what specific forms are included (e.g., inflections, derivations). This is a significant gap for a tool with no annotation coverage.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded, with the core purpose stated first. The 'Args' and 'Returns' sections are structured but could be more integrated. There's no wasted text, though it could be slightly more polished for readability.

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

  Completeness3/5

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

  Given the tool's low complexity (one parameter) and the presence of an output schema (which handles return values), the description is somewhat complete but has gaps. It covers the basic purpose and return format but lacks behavioral details and usage guidelines, making it minimally viable but not fully helpful for an agent.

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

  Parameters3/5

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

  The description adds minimal semantics beyond the input schema. It states 'word: The word to look up,' which clarifies the parameter's purpose but doesn't provide format details (e.g., case sensitivity, language variants) or examples. With 0% schema description coverage and only one parameter, this is adequate but not comprehensive, aligning with the baseline for low coverage.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Look up different forms of a Norwegian word.' It specifies the verb ('look up'), resource ('Norwegian word'), and scope ('different forms'). However, it doesn't explicitly differentiate from sibling tools like 'lookup_word_lemma', which might provide related but distinct functionality.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools (e.g., 'lookup_word_lemma' for lemmas or 'find_collocations' for word combinations) or specify contexts where this tool is preferred. Usage is implied by the purpose but not explicitly stated.

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

• lookup_word_lemmaC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return format ('JSON string') but doesn't describe error handling, rate limits, authentication needs, or what happens with invalid inputs. For a lookup tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

  Conciseness4/5

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

  The description is efficiently structured with a clear purpose statement followed by separate Args and Returns sections. It avoids redundancy and wastes no words, though the 'JSON string' return specification could be slightly more informative (e.g., mentioning structure or keys).

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

  Completeness3/5

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

  Given the tool's low complexity (single parameter) and the presence of an output schema (which handles return values), the description is reasonably complete for basic use. However, the lack of annotations and minimal behavioral context means users might not fully understand error cases or operational limits.

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

  Parameters3/5

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

  The schema description coverage is 0%, but the description explicitly documents the single parameter 'word' and its purpose ('The word to look up'). This adds meaningful context beyond the bare schema. However, it doesn't specify constraints like word length, character set, or handling of compound words, leaving some ambiguity.

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

  Purpose4/5

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

  The description clearly states the verb ('look up') and resource ('lemma of a Norwegian word'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'lookup_word_forms', which likely serves a related but distinct function.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'lookup_word_forms' or other sibling tools. It states what the tool does but offers no context about appropriate use cases, prerequisites, or exclusions.

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

• find_collocationsB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns 'JSON string containing collocation statistics,' which hints at a read-only operation, but doesn't clarify if it's safe, has rate limits, requires authentication, or what the statistics include. This is inadequate for a tool with computational analysis.

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

  Conciseness4/5

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

  The description is well-structured and appropriately sized. It starts with a clear purpose sentence, followed by an 'Args' section listing parameters with defaults, and ends with return information. Every sentence adds value, though the 'Returns' line could be more specific about the JSON structure.

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

  Completeness3/5

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

  Given the tool's moderate complexity (4 parameters, no annotations, but has an output schema), the description is partially complete. It covers parameters well but lacks behavioral context and usage guidelines. The output schema existence reduces the need to detail return values, but more operational guidance would improve completeness.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'URN identifier for the document,' 'Target word to find collocations for,' 'Size of context window (default: 5),' and 'Maximum number of collocations to return (default: 100).' This clarifies all 4 parameters beyond their schema types, though it could detail units or constraints like window size limits.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Find collocations (words that appear near the target word) in a document.' It specifies the verb ('Find'), resource ('collocations'), and scope ('in a document'). However, it doesn't explicitly differentiate from sibling tools like 'find_concordances' or 'word_concordance', which might have overlapping functionality with text analysis.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where this tool is preferred, such as for statistical analysis of word associations rather than simple concordance searches. This leaves the agent without clear usage boundaries.

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

• search_imagesB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns 'JSON string containing image search results with URLs', which adds some context about the output format. However, it doesn't cover important aspects like rate limits, authentication needs, pagination, error handling, or whether it's a read-only operation. For a search tool with no annotations, this leaves significant gaps.

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

  Conciseness4/5

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

  The description is well-structured and appropriately sized. It starts with a clear purpose statement, followed by organized sections for Args and Returns. Each sentence serves a specific function without redundancy. However, the 'Returns' section could be slightly more concise by integrating with the purpose statement.

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

  Completeness3/5

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

  Given the tool's moderate complexity (4 parameters, no annotations, but with an output schema), the description is partially complete. It covers parameters well and mentions the output format, but lacks usage guidelines, behavioral details, and differentiation from siblings. The output schema existence reduces the need to fully explain return values, but more context is needed for effective agent use.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all 4 parameters: 'query' as a search string, 'limit' as maximum results with default, and 'from_year'/'to_year' as optional year filters. This adds meaningful context beyond the bare schema types, though it could elaborate on query syntax or year format constraints.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Search for images in the National Library's digital collection.' This specifies the verb ('search'), resource ('images'), and context ('National Library's digital collection'). However, it doesn't explicitly differentiate from sibling tools like 'search_texts', which searches texts rather than images, though this distinction is somewhat implied by the resource type.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_texts' for text searches or other tools for different types of queries. There's no context on prerequisites, constraints, or typical use cases beyond the basic function.

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

• ngram_frequenciesB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns 'JSON string containing frequency data over time', which gives some output context, but fails to address critical aspects like rate limits, error handling, data sources, or performance characteristics. For a tool with 5 parameters and no annotations, this is a significant gap.

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

  Conciseness5/5

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

  The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a structured 'Args' and 'Returns' section. Every sentence earns its place by defining parameters and output without redundancy. It's efficient and well-organized for a tool with multiple parameters.

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

  Completeness3/5

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

  Given 5 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It covers parameter semantics well and notes the return format, but lacks behavioral details like data accuracy, limitations, or error cases. The output schema reduces the need to explain return values, but more context on tool behavior would improve completeness.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It effectively adds meaning by explaining each parameter's purpose: 'words' as a list to analyze, 'corpus' with options ('bok' for books, 'avis' for newspapers), and default values for 'from_year', 'to_year', and 'smooth'. This provides clear semantics beyond the bare schema, though it could elaborate on 'smooth' effects.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Get word frequency trends over time using NGram analysis.' It specifies the verb ('Get'), resource ('word frequency trends'), and method ('NGram analysis'), making it distinct from siblings like 'find_collocations' or 'lookup_word_lemma'. However, it doesn't explicitly differentiate from all siblings, such as 'get_corpus_statistics', which might overlap in scope.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It lacks context about scenarios where NGram frequency analysis is preferred over other tools like 'search_texts' or 'word_concordance', and offers no exclusions or prerequisites. Usage is implied through the description but not explicitly stated.

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

• search_textsA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It discloses the return format (JSON string with metadata) and default behaviors (limit default, media_type default), but doesn't mention rate limits, authentication requirements, pagination, error conditions, or whether this is a read-only operation (though 'search' implies read-only).

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

  Conciseness4/5

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

  Well-structured with clear sections (purpose, Args, Returns). The purpose statement is front-loaded. The parameter explanations are efficient, though the media_type explanation could be slightly more concise. Every sentence adds value.

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

  Completeness4/5

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

  Given 5 parameters with 0% schema coverage and no annotations, the description does an excellent job explaining parameters and return format. The output schema exists, so return values don't need explanation. However, with multiple sibling tools and no usage guidance, there's a gap in helping the agent choose between alternatives.

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

  Parameters5/5

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

  With 0% schema description coverage, the description fully compensates by explaining all 5 parameters in detail. It provides clear semantics for query (search query string), limit (maximum results with default), from_year/to_year (search period with optional status), and media_type (type options with default and explanations of each option value).

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

  Purpose4/5

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

  The description clearly states the tool searches for texts in a specific collection (National Library's digital collection) with a specific verb ('Search for'). It distinguishes from sibling tools like search_images by specifying text search, but doesn't explicitly differentiate from other text-related tools like find_concordances or word_concordance.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like find_concordances, search_images, and word_concordance, there's no indication of when text search is appropriate versus other text analysis or image search tools.

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

• word_concordanceA
  4.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the tool returns structured JSON output (not HTML), includes default values for 'window' and 'limit', and specifies max constraints ('max: 24'). However, it does not cover potential errors, rate limits, or authentication needs, leaving some gaps in behavioral context.

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

  Conciseness5/5

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

  The description is appropriately sized and front-loaded, starting with the core purpose and key differentiator. Each sentence earns its place by explaining output format, usage context, parameters, and return values without redundancy. The structured bullet points for parameters and returns enhance readability without unnecessary verbosity.

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

  Completeness5/5

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

  Given the tool's moderate complexity (4 parameters, no annotations, but with an output schema), the description is complete enough. It covers purpose, usage, parameters, and return format in detail. Since an output schema exists, the description does not need to explain return values beyond what's provided, and it adequately addresses the lack of annotations and schema coverage.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must compensate fully. It adds significant meaning beyond the input schema by explaining each parameter's purpose: 'urn' as a 'URN identifier for the document', 'word' as 'Word to find concordances for', 'window' with default and max details, and 'limit' with default. This provides complete parameter semantics not present in the schema.

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

  Purpose5/5

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

  The description clearly states the specific action ('Find concordances') and resource ('structured output'), distinguishing it from siblings like 'find_concordances' by emphasizing 'structured output (no HTML formatting)' and 'clean format with separate before/target/after fields'. This explicit differentiation ensures the agent understands this tool's unique purpose.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool ('useful for programmatic analysis where you need the matched word separated from context'), but it does not explicitly state when not to use it or name alternatives among siblings (e.g., 'find_concordances' might offer HTML formatting). This gives good guidance but lacks explicit exclusions.

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