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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral detail beyond them: it names the return contents (summary, findings with confidence, limitations, overview) and explains the chunked-scan state machine with `complete`/`coverage`. It stops short of noting cost or latency for large scans.

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, front-loaded with what the tool does, then the batching caveat. The format enumeration is long but earns its place as a capability boundary; minor density is acceptable for a tool with this many supported inputs.

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, and the description compensates by listing the returned artifacts (summary, findings, limitations, overview, collections). Together with the batch/coverage explanation, an agent has enough to invoke it and know what to do with a partial result.

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

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

Schema coverage is 100%, so baseline is 3; the description adds value by tying `scan`/`batch`/`include` semantics to the "complete is false" loop and clarifying that every list covers only the scanned part. That cross-parameter interaction is not derivable from the per-property schema descriptions alone.

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 ("Run the built-in analyzer") plus the resource and enumerates the supported formats, so an agent knows exactly what class of work this tool performs versus siblings like hexvero_strings or hexvero_collection. The mention of "collections available for paging" also signals the handoff relationship to hexvero_collection.

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 concrete usage rules for the paging case: "when `complete` is false... call again with scan to read more," which is exactly the when-to-call-again condition an agent needs. It does not state when to prefer this over hexvero_check or hexvero_providers, so it falls short of full alternative 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?

The annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds the 64 KiB cap and the return layout, but says nothing about what happens for out-of-range offsets, past-EOF reads, or invalid targets.

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 with the scope limit and the output format front-loaded; nothing is wasted and no reading past the first clause is needed.

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 usefully explains the return shape, which is the main gap it fills. However, offset semantics and edge-case behavior for a read tool that takes raw byte positions are left undefined, which is more than a minor omission.

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 only 33% — just targetId is documented — so the description should carry more weight. 'Bounded window (max 64 KiB)' corroborates the length maximum and 'target' maps to targetId, but offset (absolute byte position from start?) and length (byte count?) get no meaning beyond the schema's min/max constraints.

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?

Names a specific verb (read) and resource (a byte window of the target), and states the output format (hex plus ASCII gutter). It is clearly distinct from siblings like hexvero_strings or hexvero_analyze, though it never explicitly names which sibling to prefer for a similar need.

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 only implied by the verb 'read' — there is no statement of when to choose this over hexvero_strings, hexvero_analyze, or hexvero_export, and no mention that a targetId must first come from hexvero_open (that fact lives only in the schema).

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?

Goes beyond the annotations by disclosing the cost model and statefulness: 'one engine run per target, cached.' It also flags that truncation is surfaced in the result ('levels state what was cut'), which is important behavioral context for a bounded traversal. What remains unstated is timeout behavior and response shape, keeping it off 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?

Two compact clauses with the primary capability front-loaded and the alternate mode immediately after. No filler. The trailing 'levels state what was cut' is slightly terse but still earns its place by explaining truncation reporting.

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

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

This is an 8-parameter, engine-backed analysis tool with no output schema, so the description must carry more of the return contract. It hints at levels/truncation but never describes the node/edge structure returned, caching scope, or what happens when the path is not found. Adequate but with clear gaps for an agent composing results.

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

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

Schema coverage is 75% and the schema already documents goal, root, maxDepth, maxNodes, direction, and targetId in detail. The description only loosely maps 'by depth and node count' onto maxDepth/maxNodes and adds nothing for timeoutMs. With the schema doing the heavy lifting, the baseline 3 is appropriate.

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

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

Names a concrete resource (call-graph neighborhood around a function) and a concrete verb-like behavior (retrieve callers/callees to a depth, or shortest path root→goal). An agent can distinguish the two modes from the sentence alone. It does not compare itself to any sibling, but no sibling overlaps this domain (strings, bytes, export, etc.), so the omission is minor.

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 split between neighborhood mode and shortest-path mode is implied by the parenthetical and the 'or the shortest call path' clause, and the schema repeats the goal trigger. However, there is no explicit 'use this when…' guidance, no guidance on choosing direction/depth budgets, and no exclusions versus hexvero_provider_run or hexvero_analyze.

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

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

Annotations already declare readOnly/idempotent/no-destructive, but the description adds useful non-obvious behavior: status is pass/fail/incomplete, findings are paged by offset, and it 'reads a baseline, never writes one.' It does not clarify how the baseline is produced or whether a missing baseline file is an error, which keeps it short of a 5.

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

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

Front-loaded with the primary action and mode distinction, with no filler sentences. It is dense—one long sentence carrying two modes plus status/paging facts—which slightly hurts scannability but 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 9-parameter, nested-object tool with no output schema, it covers mode selection, output status values, and pagination, which is most of what an agent needs. Remaining gaps (baseline file preconditions, policy vs policyPath resolution, format restriction rationale) are modest but real.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns extra credit by explaining the mode-switching role of targetB and the audit-only nature of single-target checks, which the schema text alone does not frame as a distinct mode. It still does not clarify policy vs policyPath precedence when both are supplied.

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 ('apply a release policy ... to two builds') and explicitly names the two operating modes, including the CLI equivalents (`hexvero check` vs `hexvero audit`). This clearly distinguishes it from siblings like hexvero_compare or hexvero_analyze, which have no policy application concept.

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 conditional: omit targetB to audit a single target against Electron security rules, with policy optional in that mode. This is a concrete when-to-use rule that directly maps to the optional targetB parameter, leaving little to inference.

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

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

Annotations already disclose non-read-only, idempotent, non-destructive behavior. The description adds that the target and its retained analysis are released, which is useful scope, but "release" remains vague about whether analysis is discarded or merely freed from memory.

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 no wasted words. It tells the agent the essential effect immediately.

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

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

For a simple one-parameter close tool with complete schema coverage and rich annotations, the description is nearly sufficient. A small gap remains around the precise meaning of releasing retained analysis, but no crucial calling information is missing.

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

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

The single parameter has 100% schema coverage and the schema explains that targetId is returned by hexvero_open. The description adds no parameter-level detail beyond that, so the baseline of 3 applies.

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

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

The description states a specific verb ("Release") and resource ("a target and its retained analysis"), so the action is clear. It does not explicitly name the sibling tool or the pairing with hexvero_open, though the schema's targetId description supplies that context.

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

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

Usage is implied: close a target after it has been opened and analyzed, releasing its retained analysis. There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance in the description itself.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered without description help. The description says nothing about pagination semantics, byte-truncation of items, or what 'next' means beyond what the schema states. With annotations carrying the safety profile, this is an adequate but unenriched 3.

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, with the verb+resource stated first and the discovery hint last. The long collection enumeration would normally be bloat, but it earns its place because the schema has no enum for that parameter.

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 paginated read tool with no output schema, the description plus the maxBytes parameter text together convey enough to call it correctly. It omits a short note on how to continue paging (using the reported next/index), which is the main remaining 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 83%, so most parameters (text, limit, offset, maxBytes, targetId) are already documented inline. The description adds real value for the one bare parameter, 'collection', by listing its valid values in the absence of an enum, but it gives no extra detail on filtering or paging behavior.

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 ('Page through one named list from the analysis') and enumerates the concrete collections available, so an agent knows exactly what it retrieves. It also implicitly distinguishes itself from hexvero_analyze by naming it as the discovery tool rather than the paging 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?

'Use hexvero_analyze to see which exist' gives explicit routing guidance for discovering valid collection values, which is the main precondition for calling this tool. It does not, however, clarify when to prefer this over sibling hexvero_list or hexvero_export, so the guidance is strong but not exhaustive.

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, idempotent, non-destructive behavior. The description adds meaningful behavioral context beyond annotations: auto-detected key matching, composite keys, per-list paging, unknown-item handling, and the strict=false relocation 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 front-loaded with the core purpose and uses compact clauses without filler. Every sentence contributes to purpose, behavior, or usage context, and the information is organized logically.

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 comparison tool with no output schema, the description explains the two operating modes, matching semantics, paging, and result categories. It could say more about the exact response shape, but it is complete enough for an agent to invoke correctly.

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

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

Schema coverage is high at 89%, giving a baseline of 3, but the description adds value by clarifying key auto-detection and composite syntax, the list/offset paging model, and the optional collection mode. It still leaves some parameters such as ignore and limit mostly to the schema.

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

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

The description uses a specific verb and resource: 'Diff one collection between two targets,' and enumerates the result categories and key-matching behavior. It is clear what the tool does, though it does not explicitly distinguish itself from siblings such as hexvero_collection or hexvero_list.

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

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

It gives useful usage context by explaining the no-collection mode: 'Without collection: counts per shared collection, to pick one,' which implies a discovery-then-compare workflow. It does not name alternatives or exclusions, so it falls short of a full when-to-use/when-not-to-use guide.

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 this is destructive, non-read-only, and idempotent, so safety semantics are covered structurally. The description adds useful context that the tool returns the destination path and file size, which is not in an output schema, but it does not mention the existing-file refusal or overwrite behavior even though those are documented in the schema. With annotations carrying the safety profile, this is adequate but not rich.

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 two tight sentences with no filler. The primary action and return values come first, followed by the routing guidance, so it is well front-loaded.

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

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

For a simple export tool, the description covers what it does, when to use it, and what it returns. The input schema handles all parameter details including overwrite and refusal behavior, and annotations cover the mutation safety profile, so nothing critical is missing from the definition as a whole.

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

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

Schema description coverage is 100%, so the input schema already fully documents targetId, path, and overwrite. The description does not add parameter-level detail beyond what the schema provides, which is appropriate for high coverage but warrants the baseline 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 and resource: writing the complete analysis as JSON to a file. It also front-loads the return values (path and size) and distinguishes the operation from paging, so an agent can immediately tell what this tool does and how it differs from list-style siblings.

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

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

It explicitly says to use this instead of paging when the agent needs everything, which is direct guidance for selecting this tool over an alternative. It stops short of describing when not to use it, such as for small results where paging is sufficient, but the primary routing condition 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety behavior is fully covered structurally. The description contributes the session-scoped lifetime of the list, which is real added context, but says nothing about ordering, size or what a 'target' record contains.

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?

One short sentence with zero filler, front-loaded with the verb and resource. Nothing could be removed without losing meaning.

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

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

No output schema exists, so the description is the only place a caller could learn what a listed target looks like or in what order results arrive, and it does not say. For a simple zero-arg list tool this is a modest but 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?

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate; baseline 4 applies.

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

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

Specific verb 'List' plus resource 'targets' with the scope qualifier 'opened in this session', so the agent knows exactly what comes back. It does not differentiate from nearby siblings such as hexvero_collection or hexvero_unknowns, which also sound like enumerations.

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 statement of when to call this versus hexvero_collection or the other listing-style siblings, and no prerequisites or exclusions. The session scoping is implied by 'in this session' but never framed as a selection criterion.

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, idempotent and non-destructive behavior, so the bar is lower; the description still adds substance by naming the returned fields (id, size, hash, detected format) and explaining that ids are content-stable, which makes the idempotency hint concrete. It omits failure behavior for missing or unreadable paths.

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 short sentences, zero filler, with the action and its scope front-loaded before the return-value and id-stability details. Every sentence carries new 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?

With no output schema, the description usefully enumerates the response fields, and the content-stability note answers the natural 'what happens on re-open' question. Error cases and whether an existing registration is reused are left unstated, which is the only remaining gap for a one-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 coverage is 100% with a single required parameter already documented as 'Absolute or relative path'. The description adds only the hint that a directory is also acceptable, which is marginal value beyond the schema.

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

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

States a specific verb+resource ('Register a local file or directory for analysis') and immediately says what it returns, so an agent knows this is the entry point that produces an id. It doesn't explicitly contrast with siblings such as hexvero_list or hexvero_close, but the open/close pairing is inferable from the names.

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 only implied by the phrase 'for analysis' — an agent can guess that opening must precede hexvero_analyze, hexvero_strings, etc., but the description never states when to use this versus existing handles or what to do if the target is already open. No exclusions or 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?

Annotations already declare idempotent=true, destructive=false, and openWorld=false, so the safety profile is carried by structured data. The description adds genuine context beyond that with 'Output is bounded and cached,' but says nothing about execution cost, which operations are slow, or how results are truncated.

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 tight sentences with the core action and the operation list front-loaded, no filler. The trailing 'Output is bounded and cached' is a single efficient behavioral note.

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 6-parameter dispatch tool over 10 operations with no output schema, an agent still needs to infer the per-operation parameter contract (text only for search, address for disassemble/decompile/xrefs/callers/callees) and the difference between the three provider engines. The description is adequate but leaves meaningful inference work.

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 50%; the description clarifies that 'address' is a function address or symbol used by xrefs/callers/callees and that search takes names and strings, which partially compensates. It gives no mapping of which parameters are required per operation and no mention of provider selection or timeoutMs.

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?

Names a specific verb (run) and resource (engine operation on a target) and enumerates all ten supported operations, so an agent knows exactly what surface the tool covers. It does not, however, differentiate itself from siblings that expose overlapping functionality such as hexvero_strings and hexvero_call_graph, which appear as first-class operations here too.

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 operation enumeration implies when each variant is appropriate, but there is no explicit guidance on when to pick hexvero_provider_run versus the dedicated siblings (hexvero_strings, hexvero_call_graph, hexvero_analyze) that appear to do the same things. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the meaningful trait that engines are optional and environment-dependent, but says nothing about how detection behaves (probing cost, what happens when an engine is absent) or what the response lists.

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 the verb, the resource and the scope of the result. Nothing redundant and nothing that could be trimmed.

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-param, no-output-schema read-only probe, the description is largely sufficient — it tells the agent what is being enumerated and that availability varies. It stops short of describing the shape of the returned provider list, which is the one thing an agent must infer.

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?

Zero parameters, so there is nothing for the description to disambiguate; four is the baseline for a parameterless tool and the description introduces no parameter confusion.

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 (Detect) and resource (optional external engines: radare2/rizin, Ghidra) plus what the result conveys (operations each supports). It implicitly contrasts with hexvero_provider_run, though it never names that sibling to make the execution-vs-detection split explicit.

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 only implied: an agent can infer this is a capability-probe to run before hexvero_provider_run, but the description never says when to call it, whether it is a prerequisite, or what to do if no engines are found.

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 this is a non-readonly, non-destructive, non-idempotent write into a new directory. The description adds meaningful context beyond that: the output artifact layout (one file per module plus hexvero-bundle.json with requires/exports) and that nothing is executed. It does not state what happens if outputDir is non-empty or whether writes are partial on failure.

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, front-loaded with the action and its modes, then a compact safety clause. No wasted text and no repetition of schema or annotation content.

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

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

With no output schema, the description carries the return-value burden and does so by describing the produced files and the hexvero-bundle.json manifest. For a two-parameter write tool with full schema coverage and annotations, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so both parameters (targetId, outputDir) are already documented, including the 'absent or empty directory' constraint. The description adds no per-parameter detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb and resource ('Write recoverable sources into a new directory') and enumerates the two source kinds it handles: bundle modules (webpack/Rspack/browserify/esbuild) and source-map sourcesContent. It is clear what the tool produces, but it never names or distinguishes itself from nearby siblings like hexvero_export or hexvero_sourcemap, which plausibly overlap.

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?

'Write recoverable sources into a new directory' plus the two enumerated cases gives a clear when-to-use context, and 'No engine needed; nothing is executed' reassures about prerequisites. There is no explicit exclusion or pointer to an alternative tool for the overlapping export/sourcemap cases.

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 this a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds that the result includes original source, line, column and name, which is valuable since no output schema exists, but says nothing about lookup failures or missing mappings.

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?

One front-loaded sentence with no filler; the verb and the mapping direction appear before the returned fields. Nothing is wasted.

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 correctly enumerates the returned components (source, line, column, name), and the single documented parameter is handled in the schema. Minor gaps remain around failure behavior and coordinate conventions, but an agent can call it correctly from what is present.

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 only 33%, and the description does not document targetId (the schema does) or the coordinate bases. It does add real meaning by making clear that line/column are *generated* coordinates being mapped back, which the raw integer schema alone does not convey.

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?

Names a specific verb ('Map ... back') and precise resource (a source map target's generated line/column), which is distinct from any sibling in the list. It stops short of explicitly contrasting with alternatives such as hexvero_analyze, but the narrow source-map framing makes its role unmistakable.

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 explicit guidance on when to use this versus the other hexvero tools, nor on prerequisites or ordering. The only hint of workflow ('targetId returned by hexvero_open') lives in the schema, not the description.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful disclosure that items carry byte offsets and classification tags (url, path, email, ip, format, secret-ish, base64-ish). It says nothing about filtering/pagination behavior, which is where the real behavioral risk of a large output lies.

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 dense fragment with zero filler and the tag vocabulary front-loaded. The tradeoff is that it reads as a label rather than an instruction, but nothing is wasted.

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 pagination controls (limit, offset, maxBytes with truncation semantics), the description says nothing about how results are paged or truncated or what a caller should expect back. The schema handles the mechanics, but the description leaves the agent without an operational picture of this tool.

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

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

Schema coverage is 75%, so the schema already carries most parameter meaning. The description only reinforces the utf16 toggle and names the tag vocabulary that the `tag` parameter filters on, but adds no format, range, or interaction details for limit/offset/maxBytes/minLength.

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 the resource (printable ASCII / UTF-16LE strings with offsets) and the tag taxonomy, so an agent can infer extraction of strings from a target. But it is a noun fragment with no verb and no differentiation from siblings like hexvero_bytes or hexvero_analyze, which also operate on target content.

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 on when to use this instead of hexvero_bytes, hexvero_analyze, or hexvero_unknowns. The agent must infer usage purely from the tag list, and there are no stated preconditions (e.g., that targetId must come from hexvero_open, which only appears in the schema).

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

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

Annotations declare this is not read-only and not destructive, and the description adds real behavioral context: unknowns are exported with the analysis so reports never silently drop them, which explains the durable side effect of 'record'. However, it omits the mutating 'remove' action entirely and says nothing about reversibility or whether resolve requires evidence. Not contradictory, but incomplete for a write-capable tool.

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 dense sentence that front-loads the three primary actions before the rationale. It earns its place, though packing three operations plus rationale into one sentence makes the enumeration slightly harder to parse than a short list would be.

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

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

For a 9-parameter, 4-action tool with no output schema, the description covers the core workflow adequately but leaves gaps: the 'remove' action is undocumented, and there is no mention of how listing paginates or what a resolve returns. An agent could call it, but not without opening the schema to discover the fourth action.

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 67%, so several parameters (id, status, checked, question, resolution, targetId) are already documented in the schema. The description adds some value by mapping 'record' to a question plus 'what was already checked', reinforcing the checked field's intent, but it says nothing about pagination (limit/offset) or targetId, so it does not fully compensate for the coverage 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 pairs a specific resource (unknowns ledger) with the concrete operations: record a material question, list open/resolved unknowns, resolve one. It distinguishes itself from siblings by the 'unknowns' domain rather than analysis or export. It only loses a point because the schema exposes a fourth action, 'remove', that the description never mentions.

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 through the enumerated actions ('record a material question the investigation could not answer'), which gives some sense of when this applies. But there is no explicit when-to-use vs alternatives such as hexvero_export or hexvero_analyze, and no stated prerequisites or exclusions.

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