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

With no annotations, the description carries the full burden. It usefully discloses two behavioral traits: results are counts only ('no rows returned') and there is a hard limit of 20 queries per call. However it says nothing about permissions, pagination/truncation of counts, or what match_path changes behaviorally.

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

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

A single front-loaded sentence that leads with the core capability and limit, followed by compact illustrative examples. No filler or repetition; every clause 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 2-param, no-output-schema tool the description covers the count-only return and batching limit adequately, so return values need not be explained further. The gap is match_path, which is undocumented anywhere, leaving an agent unable to reason about path-vs-name matching.

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 0%, so the description must compensate. It does add value for 'queries' by documenting the 20-query cap and showing query syntax ('ext:pdf'). But the match_path boolean is never mentioned, leaving one of two parameters undefined in both schema and description.

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 clear verb (count) and resource (matches for queries) and explicitly contrasts with the row-returning sibling by noting '(no rows returned)', which is exactly what distinguishes it from everything_search. It stops short of naming a sibling directly, but the scope is 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?

Gives two concrete usage scenarios (comparing 'ext:pdf' vs 'ext:docx' under a folder, checking whether a file exists anywhere) that make the intended context clear. It does not state when NOT to use it or explicitly route to everything_search for row data, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses the diagnostic categories returned and that 'each issue has a fix,' which tells the agent the output is actionable findings rather than raw metrics. It stops short of stating whether the tool is purely read-only or whether it applies any changes.

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

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

Front-loaded with the purpose, then a compact parenthetical list of concrete misconfiguration patterns. The list is long but each item (double-indexed drive, network-folder monitoring, foreground rescans, unsaved index, 32-bit build) is specific and 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 no-arg diagnostic with no annotations and no output schema, the description covers both what is checked and what the response looks like (issues with fixes). Only the read-only/mutating nature and any cost of running the check are left unstated.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter information is missing because no parameters exist.

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

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

States a specific verb+resource ('Index health and configuration self-check') and enumerates exactly what is inspected: version, build, database state, indexed volumes/folders, database age, and misconfiguration patterns. It is clearly distinguishable from search/count/maintain siblings, though it never explicitly contrasts itself with everything_maintain.

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

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

Usage is implied rather than stated: the mention of slow indexing, RAM bloat and freezes signals a troubleshooting context, but there is no explicit 'call this when X' or routing against everything_maintain. An agent can infer the diagnostic use case but gets no exclusions or alternatives.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It says what kind of result to expect, but it does not disclose read-only behavior, sorting, limit behavior, pagination, permissions, or performance characteristics. For a listing tool with no annotations, this leaves significant operational gaps.

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

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

The description is short, front-loaded, and free of filler. Every clause contributes either purpose, scope, or parameter guidance.

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 three-parameter listing tool with no annotations or output schema, the core purpose and primary filters are understandable. However, it omits limit behavior and does not describe the returned file fields or ordering, leaving some gaps against the lack of structured documentation.

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 0%, so the description must explain the parameters. It gives useful examples for min_size and implies the path_filter usage with “under a folder or share,” but it does not explain limit, which remains undocumented beyond its name and default.

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 resource and result: largest files, optionally scoped under a folder or share. It also gives the intended use, disk-usage triage, which distinguishes it from generic search or count tools. It does not explicitly name a sibling alternative, so it falls short of a 5.

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

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

The phrase “for disk-usage triage” gives a clear use case, and “optionally under a folder or share” clarifies the scoping choice. It does not state when not to use it or name sibling alternatives such as everything_search, so it is clear context without 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?

With no annotations, the description carries the full burden and does disclose real behavioral traits: save_db persists in-memory state, rescan_folders acts immediately on network shares, and rebuild is slow and only warranted on stale results. It does not say whether rebuild discards the current index, whether save_db writes to disk, or whether these operations block, which matters for a maintenance tool with zero 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.

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

Telegraphic and front-loaded: a two-word purpose statement followed by colon-delimited definitions of each action, with the cost caveat placed directly on the expensive option. Every clause carries 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 one-parameter, no-output-schema tool with no annotations, the description covers all actions and their tradeoffs adequately. The remaining gap is the unaddressed relationship to everything_semantic_reindex, which an agent could easily confuse with rebuild.

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 0%, so the description must compensate, and it does: all three enum values are defined with their operational meaning rather than left as bare tokens. It adds no syntax detail beyond that, but for a single enum parameter the mapping is complete.

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 resource (the file index) and enumerates the three maintenance operations with their distinct effects, so an agent knows exactly what class of action this is. It does not, however, differentiate itself from the sibling everything_semantic_reindex, leaving overlap ambiguous.

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?

Each enum value gets a when-to-use cue: save_db for fast restart, rescan_folders for network shares, rebuild only when results look stale, with an explicit slow warning attached to rebuild. What is missing is guidance relative to alternatives, notably when to prefer rebuild over the sibling semantic_reindex.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the meaningful trait that results are sorted newest first, but says nothing about result limits, pagination, or scope/permission requirements for reading files across shares.

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 purpose leads, followed by three tight parameter lines with no filler. Every clause carries information the schema does not already contain, notably the enum-like values for 'within' and the delimiter for 'extensions'.

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 filtered-list tool with no output schema and no annotations, the description covers the discovery-critical semantics: what is returned, its order, and how to filter by path, type, and time. The remaining gap is the undocumented 'limit' parameter and default of 50, which an agent may need to reason about.

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, and it documents three of four parameters well: path_filter's scope ('a folder or share'), extensions' delimiter and example ('xlsx;csv'), and the accepted 'within' values including a concrete month format. Only 'limit' is left entirely undefined in both schema and description.

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

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

States a specific verb and resource ('Most recently modified files') plus the sort order ('newest first'), which is enough to distinguish it from siblings like everything_largest or everything_count. It never names those siblings explicitly, so differentiation is inferred rather than stated.

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

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

Usage is implied by the name and the sort-order statement, but there is no explicit 'use this when...' guidance and no mention of when to prefer everything_search or everything_semantic_search instead. The only routing-adjacent content is parameter-value guidance for 'within', which is not the same as usage guidance.

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

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

No annotations, so the description carries the full burden. It usefully discloses return behavior ('total' tells you whether to narrow, folders end with '\', details=false returns bare paths) and that name sort is instant, but never states the operation is read-only, nor covers rate limits, errors, or index-staleness caveats.

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

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

Front-loads the core purpose in one sentence, then a tight per-parameter legend with zero filler. Dense but every line earns its place; only minor cost is the legend-style layout.

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 9-parameter, annotation-free, output-schema-free tool, the description covers the query dialect and the most-used flags well, but leaves four parameters and all safety/response-envelope details to inference. Adequate but with clear gaps.

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 0%, so the description must compensate. It meaningfully explains query (with syntax examples), limit range, three sort values, details, and match_path, but leaves offset, regex, match_case, and whole_word entirely undocumented — roughly half the parameters carry no semantics anywhere.

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

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

States a specific verb and resource ('Search file and folder names across every drive and network folder Everything indexes'). The 'names' scope implicitly separates it from everything_semantic_search, but no sibling is named explicitly, so it stops short of full differentiation.

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

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

Usage is implied rather than stated: the sort guidance ('date_modified_desc for "latest"', 'size_desc for "largest"') gestures toward everything_recent/everything_largest, and 'An empty query matches everything (use with filters)' gives one concrete tip. There is no explicit when-to-use/when-not statement or named alternative.

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

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

No annotations exist, so the description carries the full burden and does well: it discloses that the job is long-running (3-7 min per million names), that it is asynchronous unless wait=true, and how to monitor it. It omits whether the existing index is unavailable during rebuild and whether the operation is idempotent/safe to interrupt.

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 dense sentences with zero filler; the async default and the wait override are front-loaded, and the polling pointer closes the loop.

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

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

For a one-parameter, no-annotation, no-output-schema maintenance tool, the description covers action, timing, async behavior, and follow-up. Minor gaps remain around index availability during rebuild and failure/interruption semantics.

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 0% and the single 'wait' parameter has no schema description, but the description compensates by defining exactly what wait=true changes (foreground/blocking vs background) and giving a duration estimate. That is the key semantic an agent needs.

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

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

States a specific verb+resource: (re)build the local semantic index, and names the source (live Everything database). It is clearly distinguishable from the sibling everything_semantic_status, which it explicitly routes polling to.

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?

Explains the operational context: background by default, and points to everything_semantic_status for polling. It does not state when a reindex is warranted (e.g., index stale) or when not to run it, but the async workflow guidance is clear.

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

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

With no annotations, the description carries the full burden and does well: it discloses the multilingual and fully-local (no network) execution model, and explains how to read relevance output ('>0.6 strong, 0.4-0.6 related'). It also warns that folders end with '\'. It omits latency/performance or empty-result behavior, so not a 5.

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

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

Four tight sentences, front-loaded with purpose then the trigger, then result interpretation, parameter note, and a follow-up tip. Every clause earns its place, including the examples which efficiently convey query style.

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 4-param tool with no annotations and no output schema, the description covers the important behavioral ground: nothing about return shape is required, and it explains scores, path_prefix, folder convention, and the chaining pattern. The missing kind/limit semantics are the only real gap.

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

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

Schema coverage is 0%, so the description must compensate and only partially does: it explains path_prefix ('restricts to a drive or share') and the query semantics via examples, but never explains the kind enum (any/folder/file) or the limit parameter. Half the parameters remain undocumented in both schema and description.

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

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

States a specific verb and resource: meaning-based search over folder names and document file names, plus the multilingual/fully-local scope. It distinguishes itself from the sibling everything_search by framing the use case as 'describes WHAT they want rather than a literal name', so an agent can route without opening schemas.

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

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

Gives an explicit trigger condition ('use when the user describes WHAT they want rather than a literal name') with three concrete multilingual examples, and references everything_search for the folder-listing follow-up. The selection logic against the literal-search sibling is clear.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does hint that the call can report 'any running or failed build', which is a useful behavioral detail, but it never states that this is a non-mutating read, whether invoking it has side effects, or what it costs on a large index.

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?

It is compact with no wasted words, but it is a bare fragment rather than a complete sentence and is not front-loaded with a verb, which makes it read like a field list rather than a tool definition.

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 does the right thing by naming the returned fields (count, built_at, model, location, build status), which is genuinely useful. However it omits all usage context and any statement of read-vs-write behavior for a tool with no annotations to fall back on, so it is only minimally complete.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema description coverage is 100%.

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 enumerates what the tool surfaces (index count, built_at, model, location, build state), which identifies the resource, but it is a noun-phrase fragment with no verb — an agent must infer 'get/read status' rather than being told. It is distinguishable from everything_semantic_search and everything_semantic_reindex only by implication, not by explicit 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?

There is no when-to-use guidance at all: nothing says whether to call this before a reindex, to diagnose a failed build, or how it relates to the sibling everything_health. The agent is left to infer the trigger condition from the tool name alone.

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