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

Annotations already declare readOnlyHint and non-destructive behavior. The description adds useful behavioral context beyond those annotations: it returns a count rather than paths and operates on indexed entries. It does not mention possible limits or edge cases, but the annotation coverage lowers the burden.

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

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

A single sentence that front-loads the verb and resource, with the key distinction ('without retrieving their paths') placed prominently. There is no filler, repetition, or unnecessary metadata.

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 six parameters, no output schema, and zero parameter descriptions, the one-line description is not enough for confident invocation. It omits the return type and how filtering options interact, and while the purpose is clear, the operational context is incomplete.

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

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

Schema description coverage is 0% and the description names none of the six parameters. It does not explain query, kind, path, regex, match_path, or case_sensitive semantics, leaving the agent entirely reliant on parameter names, titles, and defaults. The description completely fails to compensate for the schema gap.

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

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

The description states a specific verb ('Count'), a resource ('indexed files/folders'), and an explicit scope qualifier ('without retrieving their paths'). This clearly distinguishes it from sibling search and list tools that return paths or entries.

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

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

The phrase 'without retrieving their paths' gives a clear reason to use this tool when only a count is needed, implying it should be preferred over the search/list siblings in that scenario. It does not explicitly name alternatives or state when not to use it, so it stops just short of full 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 already flag readOnly and non-destructive behavior; the description adds meaningful caveats: results are index-derived, missing index entries are omitted, and recursive=False limits to direct children. This helps agents set expectations about completeness and traversal without contradicting 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?

Two short sentences carry the essential scoping and behavioral warnings, front-loaded with the primary purpose. No filler or repetition of schema 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?

For a tool with six parameters including nested filters and no output schema, this description is too sparse to be fully self-sufficient. It omits any guidance on filters, pagination/limit/offset, kind semantics, and return shape beyond a brief completeness caveat.

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 description does clarify the recursive parameter's default behavior, which is useful beyond the bare schema. However, with 0% top-level schema description coverage and six parameters, it leaves kind, path, limit, offset, and filters completely unexplained.

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

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

Description opens with a specific verb and resource: it browses indexed directory children rather than performing a raw filesystem listing. It clearly communicates the core action, though it does not explicitly name a sibling tool for contrast.

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

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

The phrase 'not a filesystem listing' and 'indexed children' imply that this tool is for navigating the index rather than searching globally or checking raw disk state. It lacks an explicit when-to-use or when-not-to-use statement, and no alternatives are named.

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

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

Adds return-shape disclosure ('Returns paths, size bytes and modification times'), live-index pagination behavior, and a safety guarantee ('Does not read file contents') beyond the readOnly/not-destructive annotations. 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?

Six short sentences, each carrying information; the purpose is front-loaded and the text stays within a compact paragraph. No filler.

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

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

No output schema exists, but the description states the core return fields. Given 11 parameters and many sibling modes, it doesn't cover how the tool relates to sibling search modes or the meaning of the advanced flags, leaving the full picture incomplete.

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

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

With 0% top-level schema description coverage, the description compensates for the key parameters: query syntax examples and path default scope. However, it leaves sort, limit, offset, regex, match_path, case_sensitive, kind, descending, and filters mostly to their schema names, which is a clear gap.

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 action ('Search the local Everything index') and resource, and adds concrete query syntax examples. It does not explicitly differentiate from the many everything_search_* siblings, so it misses the fifth point.

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

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

No sentence tells the agent when to choose this general search over everything_search_typo, everything_search_regex, everything_search_fuzzy, or others. 'No path means all indexed locations' is scope information, not usage routing.

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

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

Annotations already establish read-only and non-destructive behavior, so the description's burden is lower. It adds a meaningful behavioral rule: explicit filters.extensions overrides the category's default extension list. However, it does not disclose return format, sorting, pagination behavior, or indexing limitations.

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

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

Two sentences with no filler: the first states the core action and resource, the second gives the key override rule. It is tightly written and 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 tool with six parameters, no output schema, and a large sibling family, this is under-specified. There is no result-shape information, no pagination/ordering detail, no relationship to sibling search tools, and no statement of what 'documented extension category' actually means. The annotation covers safety, but the description does not give enough context 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 description coverage is 0%, and the description only clarifies the role of category and the override relationship of filters.extensions. Parameters like path, text, limit, offset, min/max bytes, and date filters are left entirely to their names and defaults. The tool description does not compensate for the missing schema-level parameter 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 states a specific verb and resource: 'Search a documented extension category.' The category enum in the schema makes the resource concrete, and the name distinguishes it from text/pattern-based siblings. It could be sharper by enumerating the categories directly, but it is not vague or tautological.

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

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

There is no guidance about when to choose this tool over the many sibling search variants. With 11 related search tools named everything_search_*, an agent gets no routing help such as 'use for category/extension filtering' or 'use X for text patterns.' Usage must be inferred from the tool name.

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

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

Annotations already mark the tool as readOnly and non-destructive. The description adds meaningful behavioral detail beyond that: matching the whole basename with extension and explicitly rejecting wildcard interpretation. 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 a single sentence that is fully front-loaded and contains no filler. It states the core matching rule and the key exclusion (no wildcards) in the fewest possible words.

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 sufficient for understanding the core matching behavior, but it does not explain return shape, pagination, case sensitivity, or whether path is supported as a scope limiter. Since there is no output schema, the missing return-value context is a real gap. Read-only annotations reduce the safety burden, but an agent would still need to infer some operational details.

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 description clarifies only the `name` parameter by indicating it should be a literal basename including extension. With schema description coverage at 0%, the description is expected to compensate for undocumented parameters, but it says nothing about `kind`, `path`, `limit`, `offset`, or `filters`. The schema and defaults help, but the description itself adds minimal parameter-level value.

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

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

The description clearly states that the tool matches the entire literal basename including the extension, and explicitly disclaims wildcard interpretation. This makes its behavior distinct from wildcard, regex, fuzzy, and typo sibling tools, though it never directly says it searches for files/folders by name.

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

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

The description conveys a clear when-to-use: exact literal basename matching with no wildcard expansion. It also implicitly says not to use this tool when wildcard/pattern matching is needed, but it does not explicitly name alternative sibling tools such as everything_search_wildcard or everything_search_regex.

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 the operation is read-only and non-destructive, so the description only needs to add behavioral nuance. It adds the important trait that literal characters are escaped, and clarifies matching semantics such as subsequence and unordered keywords. This goes beyond the structured fields and meaningfully informs an agent about edge cases like special characters.

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

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

Two compact sentences front-load the core purpose and immediately give a routing rule for a common confusion (typos vs fuzzy matching). Every clause earns its place and there is no redundant wording.

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

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

Given a 7-parameter schema with zero parameter descriptions and no output schema, this description is too thin to fully equip an agent. It lacks guidance on path scoping, result limiting, filter usage, and how this fuzzy search relates to the many sibling search tools. The nested Filters schema has some explanatory text, but the main description does not compensate for the overall low coverage.

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 0%, so the description carries the burden of explaining parameters. It touches on the 'mode' parameter by naming its three values, and the phrase 'unordered keywords' adds a little extra meaning. But it does not explain 'path', 'kind', 'limit', 'offset', or the 'filters' object, leaving most of the tool's parameters underspecified for an agent.

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

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

The description identifies the resource ('filename') and the core behavior ('subsequence, substring, or unordered keywords'), so an agent can tell this is a fuzzy filename search. It also directs spelling-error cases to search_typo, providing one concrete sibling distinction. However, it does not contrast this tool with other close siblings like everything_search_exact, everything_search_wildcard, or everything_search_regex, so differentiation is incomplete.

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 a clear usage context: fuzzy filename matching across three modes, with an explicit exclusion ('use search_typo for spelling errors'). This is helpful but only partially routes among the many sibling search tools; it does not specify when to prefer fuzzy over exact, regex, wildcard, or keyword-specific search variants.

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 the tool read-only and non-destructive. The description adds meaningful matching behavior: all/any keyword semantics, literal-word exclusion, and that space-containing words are treated as phrases. These traits are not visible in the schema and help an agent predict search behavior.

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

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

The description is a single, front-loaded sentence with no filler. It efficiently conveys the core search semantics. However, given the complexity of the input schema, the terseness borders on under-specification rather than appropriately sized 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 8 parameters, no output schema, and no per-parameter descriptions, the one-sentence description is not enough for an agent to invoke the tool confidently. It omits how filters behave, what path scoping means, what results look like, and how defaults like limit and kind apply.

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 0%, so the description must compensate. It explains the conceptual semantics behind keywords, match, and exclude, but it ignores the remaining five parameters: path, kind, limit, offset, and filters. For an 8-parameter tool this is a substantial gap in parameter-level guidance.

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

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

The description names a specific verb-resource pair: matching literal filename keywords, with all/any semantics and exclusion. The word 'literal' clearly separates this from the regex, wildcard, fuzzy, typo, and pinyin sibling tools, so an agent can identify it without opening the schema.

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

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

The description implies the intended use case through 'literal filename keywords' and phrase handling, but it never explicitly states when to choose this tool over siblings like everything_search_regex or everything_search_wildcard. Context is present, but exclusions and alternatives are left to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the operation is known to be safe. The description adds meaningful behavioral context beyond that: results come from a bounded candidate page, pagination must continue until candidates_exhausted, and results before that point are not globally exhaustive. The heteronym explanation is also useful runtime detail not present in 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?

Three sentences with no filler; the core purpose is front-loaded and the pagination caveat is placed at the end where it reinforces behavior. The jargon 'ES candidate page' and 'candidates_exhausted' assumes context but does not waste words.

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 for this paginated search tool, so the description should explain response/pagination semantics and key controls. It covers offset continuation and boundedness, but not what a response contains, how candidate_query/candidate_limit work, or how filters and limit interact. For a nine-parameter tool, this is incomplete.

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

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

The description adds meaning for mode (full pinyin, initials, mixed), heteronym, and candidate offset. But with 0% top-level schema description coverage, it must compensate for many parameters; it leaves path, limit, filters, candidate_limit, and candidate_query semantically unexplained. The nested Filters schema has some descriptive help, but the main parameters still rely too heavily on names and defaults.

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

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

The description names a specific operation: match pinyin forms against a bounded candidate page, which clearly distinguishes it from regex, typo, exact, wildcard, and fuzzy search siblings. The verb 'Match' plus the pinyin resource makes the tool's role 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 implies when to use the tool (pinyin queries) and warns that results are not globally exhaustive before pagination completes. However, it never names alternative tools or states when not to use this one, so the routing decision is left to inference from the name.

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

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

Annotations already mark the tool as read-only and non-destructive, so the description carries a lower burden. It adds the detail that patterns use ES regex syntax and target filenames, but does not disclose other behavioral traits such as case sensitivity, indexing scope, or result characteristics.

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

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

A single, front-loaded sentence with a useful example and no filler. Every word earns its place.

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

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

With six parameters, a nested filters object, no output schema, and no parameter-level documentation, this description is not complete enough for an agent to call the tool correctly beyond the simplest pattern-only invocation. Major aspects like filtering, pagination, and return format are 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 description coverage is 0%, so the description must compensate for parameter meaning. It only clarifies the pattern parameter through an example; path, kind, limit, offset, and filters are left entirely unexplained.

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

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

The description clearly states a specific action ('Search filenames') using a specific method ('ES regular expressions') and provides a concrete example pattern. This differentiates it from sibling tools like wildcard, fuzzy, typo, and exact search variants.

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 example implies usage for regex-based filename matching, but there is no explicit guidance on when to choose this over the many sibling search tools. No alternatives or exclusion conditions are named.

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

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

Annotations already cover read-only safety, and the description adds genuinely useful behavioral context beyond them: ranking is page-local, all matches on the page are returned, and pagination is driven by next_candidate_offset. These are non-obvious traits an agent could easily get wrong. 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?

Four short sentences, each carrying distinct information: core purpose, exclusion, page-local behavioral trait, and pagination instruction. There is no filler, no repetition of schema defaults, and the most important fact 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?

With no output schema, the description should say what the response contains (filenames, scores, or both), but it does not. It also fails to explain candidate_query's strange 'file:' default or the filter semantics, and it doesn't route to the closely related fuzzy search sibling. Core ranking and pagination behavior is covered, but meaningful gaps remain for a 7-parameter 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 0%, so the description must compensate. It does add meaning for threshold (the 0..100 scale), candidate_limit (the 'bounded page'), and candidate_offset (pagination). However, candidate_query (default 'file:') is unexplained and the filters object's semantics are left entirely to the schema, which itself provides only metadata-level 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?

States a specific verb ('Rank'), resource ('a bounded page of filenames'), and method ('SequenceMatcher similarity (0..100)'). The 'Not semantic search' clause adds a useful exclusion. However, it does not name the closest sibling (everything_search_fuzzy) or explain how this differs from it, so sibling differentiation is partial.

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 offers one exclusion ('Not semantic search') which tells the agent what this is not, but it gives no positive when-to-use guidance and names no alternatives among the 11 siblings. The intended use case (typo-tolerant fuzzy filename ranking) must be inferred from the tool name and the SequenceMatcher mention.

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

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

The description clearly explains that * matches zero or more characters and ? matches exactly one character, and that the pattern matches the full basename rather than a substring. This goes beyond the readOnly/openWorld/destructive annotations, which are not contradicted.

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

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

The description is a single concise sentence that directly explains the tool's matching behavior with no unnecessary words. It is well structured and easy to scan.

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 covers the core matching semantics but does not mention result ordering, pagination behavior, case sensitivity, or how filters interact with the pattern. For a search tool with several filter options, this leaves some contextual gaps, though the schema provides some details.

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 description explains the key pattern parameter semantics fully, but does not add meaning for path, kind, limit, offset, or the filter object. Most of these are self-explanatory from their names and schema types, so the gap is modest, but parameter explanations are still sparse.

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 that the tool matches full basenames using * and ? wildcards, which distinguishes it from exact, regex, fuzzy, and similar sibling search tools. It is concise and conveys the core search behavior, though it does not explicitly say it searches files/folders.

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

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

The description implies usage for wildcard-based basename matching, but it does not explicitly mention alternatives or conditions such as 'use for wildcard patterns; use regex for regex patterns.' The intended use case is understandable from the wildcard semantics but not fully 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 readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'No changes to the service.' It also adds behavioral context beyond annotations by specifying exactly what is checked: ES version and Everything IPC connectivity. No contradiction exists.

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

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

The description is a single front-loaded sentence that states the purpose and the safety behavior without any filler. Every word earns its place.

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

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

For a zero-parameter, read-only status check, the description is complete: it states what is checked, that no changes are made, and its scope is clear relative to the sibling tools. No output schema exists, but the expected result is sufficiently implied by 'Check ES version and Everything IPC connectivity.'

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 schema description coverage is 100%, so there are no parameter meanings for the description to clarify. Per the baseline for zero-parameter tools, this receives a strong score.

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

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

The description states a specific verb ('Check') and precise resources ('ES version and Everything IPC connectivity'), and clearly distinguishes itself from the sibling search/list tools. An agent can immediately understand this is a health/status tool, not a data-retrieval 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 implies this is for verifying service health and connectivity before or instead of searching, but it does not explicitly state when to use it versus alternatives or when not to use it. The safety note 'No changes to the service' is useful but does not provide direct routing guidance.

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