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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds that files are 'decrypted' and how an empty query behaves, but says nothing about permission requirements, result caps, or cost for a broad glob.

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 with zero filler; the search semantics come first, the return fields second, and the special empty-query case last. Nothing is padded.

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?

An output schema exists, so listing return fields is arguably redundant, but the description still omits the meaning of the cpk/ext/game filters and the limit parameter, which an agent needs to narrow results on a 5-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% across 5 parameters, so the description carries the burden. It explains query (path substring or glob) and the empty-query case well, but leaves cpk, ext, game, and limit entirely 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 (search) and resource (decrypted CPK files) with explicit scope over named game builds, so the agent knows exactly what it queries. It does not distinguish itself from the closely related sibling storm_asset_info, leaving the boundary to inference.

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 note 'Empty query = per-game/per-CPK overview' implies a usage mode, and 'substring or glob' hints at query form, but there is no explicit when-to-use guidance or comparison against alternatives like storm_asset_info or storm_find.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description usefully adds what the payload contains (cross-game entry, chunk list), but says nothing about whether max_chunks truncates results or how missing assets behave. Some added value above the annotations, but thin.

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 filler, listing the returned facets compactly. It is appropriately sized, though the density of untranslated jargon (CPK, xfbin, NUCC) slightly reduces immediate readability.

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?

An output schema exists, so the return shape need not be spelled out, and annotations cover safety. However, with 0% parameter coverage and no usage routing, the definition leaves key invocation details unaddressed for a tool with two required inputs.

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% for all three parameters, so the description must compensate. It hints that 'game' relates to cross-game lookups and that chunks are listed, but never explains the required 'path' format or what 'max_chunks' limits. Two required params and one optional param remain semantically undocumented.

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 a resource ('One extracted CPK file') and enumerates what info it carries (paths, cross-game entry, xfbin chunk list for NUCC files), but has no explicit verb and reads as a contents list. It never distinguishes itself from close siblings like storm_asset_find or storm_show, leaving the agent to guess which one to call. Purpose is inferable but not crisply 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?

There is no guidance on when to use this tool, when not to, or which sibling (storm_asset_find, storm_show, storm_resolve) covers adjacent needs. The agent is left to infer usage entirely from the noun-phrase 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 openWorldHint=false, so the safety profile is covered. The description usefully confirms the read-only constraint and exclusion list, but says nothing about error behavior despite a stop_on_error parameter, nor about result aggregation.

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, front-loaded with the core purpose and free of filler. Efficient, though the exclusions clause would be more useful if it named accepted tools rather than just forbidden ones.

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?

An output schema exists so return values need not be described, but for a batch dispatcher the critical missing piece is how to construct the calls array and what stop_on_error does. With 0% schema coverage, the description leaves an agent unable to invoke it 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 description coverage is 0% and the 'calls' array items are untyped objects, so the description needed to explain the shape of each call entry and the meaning of stop_on_error. It does neither, leaving the single most important input for this tool entirely undocumented.

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 ('run several read-only storm-re tools in one call'), which clearly marks it as an aggregator distinct from the single-purpose siblings. It also names exclusions ('export and batch'), though it never clarifies which of the ~20 storm_* siblings are actually permitted.

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 'Excludes export and batch' clause gives partial when-not guidance but no explicit when-to-use framing or named alternative (e.g. 'use storm_explain for a single tool'). Usage must be inferred from the batch nature of the tool.

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 closed-world behavior, so the safety profile is fully covered by structured fields. The description adds no behavioral context beyond what the output schema already provides (the listed fields are return content), leaving no disclosure of scope, filtering, or limits beyond the annotations.

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

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

A single compact sentence with no filler, and the primary operation ('List') is front-loaded. It is a fragment rather than a full sentence, but nothing redundant is included.

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

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

With an output schema present, the description need not explain return values, and annotations cover the safety profile. What remains missing is usage context — what a 'build' is in this domain and when this listing should be invoked rather than a sibling — making it adequate but with a clear 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 empty schema is self-explanatory, which is the baseline 4 for param-less tools. There is nothing for the description to clarify about inputs.

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 ('List') and resource (build aliases/programs) and enumerates returned fields (SHA-256, base, counts). However, it offers no differentiation from the many sibling tools such as storm_resolve, storm_decomp, or storm_show, so an agent cannot tell from the description alone why it would pick this one.

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, no prerequisite context, and no named alternative among the 20+ storm_* siblings. The agent must infer the tool's role purely from the phrase 'build aliases'.

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 read-only, idempotent, closed-world. The description adds cache-first, bounded output, and cost/size trade-offs for detail modes, which is useful context beyond annotations. It does not explain refresh or max_bytes 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?

Two short clauses, front-loaded with the core purpose and followed by parameter cost hints. No filler or repetition.

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 6 parameters at 0% schema description coverage and only detail explained, the description is incomplete for an agent to set target, head, build, refresh, or max_bytes. Output schema and annotations reduce the burden but do not fill the parameter 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 has 0% description coverage, so the description must compensate. It only explains the detail enum (defaults/costs) and ignores target, head, build, refresh, and max_bytes.

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 (decompile) and output (bounded summary), plus cache-first behavior. Distinguishes from generic tools but does not name or contrast with any sibling such as storm_explain or storm_show.

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 operational guidance for the detail parameter (default, cheapest, potentially large) but no explicit when-to-use versus alternatives. Cache-first implies a context for use, yet sibling routing is absent.

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 openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior: the comparison dimensions returned (signature, similarity, callee delta), which tells the agent this is an analytical read rather than a raw text diff. It stops short of saying what happens when the function is missing from one build or how similarity is computed.

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 12-word sentence with the verb and scope front-loaded and the output list as a compact tail. No filler and nothing to trim.

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?

An output schema exists, so return structure need not be restated. But with 4 parameters at 0% schema coverage and no annotations explaining inputs, the definition leaves the agent guessing about 'use_map' and the required identifier formats, which is the main remaining gap for a read-only analytical 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 carries the full burden. 'one function across two builds' loosely maps 'target', 'from_build', 'to_build' for an attentive reader, but 'use_map' is completely unexplained, and nothing clarifies what form build identifiers or the target take (symbol name, mangled name, address).

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 ('Compare') plus a tightly scoped resource ('one function across two builds') and an enumeration of what is produced (signature, similarity, callee delta). It is clearly distinct from a repository-wide diff, though it never names the obvious sibling storm_patch_diff or storm_resolve to sharpen the boundary.

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 statement of when to reach for this tool versus storm_patch_diff, storm_resolve, or storm_show. The invocation context (same-named function present in both builds) is implied by 'across two builds' but never stated as a precondition, and no exclusion or alternative is offered.

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 readOnlyHint=true, idempotentHint=true and a closed world, so the safety profile is covered. The description usefully discloses that this is a composite of five distinct operations, which tells the agent it does more work than a single-step sibling. It does not disclose cost, latency, or whether the stages can be selectively disabled.

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 filler; every token is load-bearing. The terseness is intentional and the compound nature is conveyed efficiently, though it could carry one more clause without becoming bloated.

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?

Output schema exists, so return values need not be described, and annotations cover safety. What remains missing is significant: the meaning of all three parameters, what 'target' accepts, and when to prefer this over the five individual stage tools. For an aggregating tool with 0% schema description coverage, the description leaves too much unresolved.

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 adds nothing about target, build, or max_bytes. An agent gets no guidance on whether 'target' is a binary path, symbol, or address, what 'build' selects, or what max_bytes bounds. With three undocumented parameters and zero schema descriptions, the description fails to compensate.

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 (an explanation of a target) and enumerates the constituent operations (resolve, decompile, symbolize, xrefs, maps), which maps onto the sibling tools storm_resolve, storm_decomp, storm_symbolize, storm_xrefs and storm_map. That implicitly distinguishes it as the aggregating 'one-call' sibling. However, it never states what 'target' is or what the explanation produces, so it falls short of a fully self-contained purpose statement.

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?

'One-call explanation' implies the use case is a convenient combined pass, and the stage names hint at the individual siblings as alternatives. But there is no explicit when-to-use/when-not guidance, no mention of cost or redundancy versus calling storm_resolve/storm_decomp individually, and no prerequisite information. Usage is only implied.

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=false, openWorldHint=false, and idempotentHint=true, and the description's 'Write' is consistent with the write annotation. However, it adds almost no behavioral context beyond that: it doesn't say whether 'out' is a path that may overwrite existing files, what the report covers, or how limit/include_code affect output.

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

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

A single front-loaded sentence with no filler is appropriately sized. It is arguably too terse given the five undocumented parameters, but as pure conciseness it is clean.

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?

An output schema exists, so return values need not be described, but that does not offset the gaps. A mutating, five-parameter tool with zero schema coverage and no usage guidance leaves the agent without enough to call it 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?

With 5 parameters and 0% schema description coverage, the description carries the full burden but explains none of them. 'out', 'build', 'limit', and 'include_code' are entirely opaque, and even the required 'topic' is not defined in terms of format or scope.

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 (write/export) and resource (compact markdown report from indexed facts), which is clear enough for an agent to understand the action. It does not, however, differentiate itself from plausible siblings like storm_show or storm_explain, 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 description gives no when-to-use guidance, no prerequisites, and never names an alternative among the many storm_* siblings. An agent must guess when export is preferable to storm_show or storm_explain.

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 openWorldHint=false, so the safety profile is covered. The description adds 'local, cheap', which is genuine non-obvious behavioral context about cost and locality, but it discloses nothing about result shape, ranking, or pagination limits.

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 short sentence with the verb and resources front-loaded and zero filler. It is efficient, though the brevity borders on under-specification rather than deliberate compression.

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?

An output schema exists so return values need not be explained, but with 0% parameter coverage, three undescribed parameters, and no usage guidance, the definition is too thin for a four-parameter tool with twenty-plus siblings competing for selection.

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% across four parameters. The description's 'symbols, strings, or code' loosely mirrors the mode enum (redundant, since the enum values are already in the schema) and says nothing about query syntax, build, or limit, leaving three parameters effectively undocumented.

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 ('Search') and three concrete resources (symbols, strings, code), so the agent knows the tool's domain immediately. It does not, however, distinguish itself from near-neighbors like storm_asset_find or storm_resolve, so an agent must guess which search-family tool applies.

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 parenthetical '(local, cheap)' vaguely implies a preference for this tool when a fast local lookup is acceptable, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many siblings (storm_asset_find, storm_resolve, storm_xrefs). Routing guidance is 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 this a safe, idempotent, closed-world read. The description adds only the notion that it 'flags 60 FPS risks,' with no detail on what a flag looks like, what thresholds trigger it, or whether the constants are project-specific or engine defaults. Minimal context beyond structured fields.

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 short sentence with no padding, front-loading the topic and the flag behavior. But it is telegraphic to the point of under-specification, and the semicolon-joined fragment reads as notes rather than a coherent instruction.

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?

An output schema exists, so return-value explanation is not required. Still, a tool with three undocumented parameters, no usage condition, and one vague behavioral claim is not complete enough for an agent to invoke it confidently.

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?

Three parameters (build, limit, seeds) have 0% schema description coverage, and the description never mentions any of them. Nothing explains what 'seeds' contains, what 'limit' bounds, or how 'build' scopes the analysis, so an agent cannot fill these meaningfully.

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 subject matter (timer idioms, per-frame constants) and one output behavior (flags 60 FPS risks), which is more than a restatement of the name. However, it uses no verb describing the operation itself (extract? list? analyze?) and gives no indication of how it differs from siblings like storm_stat or storm_explain.

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, no prerequisites, and no mention of any sibling alternative in a tool family of 21 similarly-named 'storm_*' tools. The agent must guess at the trigger condition for this tool.

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, openWorldHint=false, and idempotentHint, covering the safety profile. The description adds only an opaque chain of internal symbols without explaining what the trace does, what data it returns, or any behavior beyond what the annotations state, so it adds little useful context.

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 very short, but its brevity reflects under-specification rather than useful conciseness. The single symbol chain does not front-load a clear purpose, and the agent cannot tell what the tool is for from this fragment.

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 three parameters and no schema descriptions, the definition is severely incomplete. Although an output schema exists and need not be explained, the description still omits purpose, usage, and parameter semantics, leaving the agent without enough information to invoke the tool correctly.

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

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

Schema description coverage is 0%, and the description does not mention any of the three parameters (build, depth, limit). The agent gets no semantic meaning for these parameters beyond their names and types, so the description fails to compensate for the absent schema documentation.

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 gives a cryptic sequence of symbols ("Pad poll -> ccPlayerPad -> CtrlInputPad -> vfunc gates -> ChangeAction") rather than a clear verb and resource for the tool. It hints at an input-processing pipeline but never states what the tool actually does or returns, leaving the agent to infer its function from the name and title.

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 tool, when not to use it, or which sibling tools (such as storm_state_surface, storm_frame_tick, or storm_scene_dispatch) are alternatives. The description provides zero usage context.

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 a closed-world scope, so the safety profile is covered. The description adds no further behavior: it does not explain the effect of refresh, whether results are cached, how matches are ranked, or what happens when a mapping fails. The phrase 'across builds' hints at scope but nothing more.

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 a single front-loaded sentence with no filler, so it is structurally tight. However, the terseness tips into under-specification, and the mixed method/argument list reads as a fragment rather than a purposeful statement.

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?

An output schema exists, so return values need not be described. But for a tool with four undocumented parameters and a cryptic two-part purpose, the description omits the build-pairing semantics and refresh behavior an agent needs to invoke it 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 0% across four parameters, so the description carries the full burden and fails it. It mentions 'name and RVA,' but RVA is not even a parameter, while the required name and the optional to_build, from_build, and refresh 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 verb 'Map' plus resource 'symbol across builds' gives a rough sense of the operation (locating a symbol's counterpart in another build), but the trailing 'via direct BSim, Trilogy-mediated, name and RVA' is method jargon that muddies rather than clarifies purpose. It never distinguishes itself from close siblings like storm_resolve or storm_symbolize, so an agent cannot confidently tell them apart.

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 statement of when to use this tool, when to prefer storm_resolve/storm_symbolize instead, or what prerequisites (e.g., two build IDs) are needed. The only hint is the implicit 'across builds' scope, which is not framed as 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 declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered without the description. The description adds only a vague scope statement ('send/recv/tick surface and Steam imports') and says nothing about what the build/limit/seeds controls do or what gets returned.

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 a single short sentence, so it is not bloated, but the brevity reflects under-specification rather than economy — the one sentence does not convey the tool's operation or scope.

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?

An output schema exists, so return values need not be described, but with four undocumented optional parameters and no usage guidance, the definition is not complete enough for an agent to invoke it correctly. The only compensating factor is the annotation-provided safety profile.

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 mentions none of the four parameters (build, limit, seeds, include_imports). With zero coverage, the description must carry the burden, and it contributes nothing about their meaning, format, or 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 is a bare noun phrase ('Steam/net-session send/recv/tick surface and Steam imports') with no verb stating what the tool actually does — inspect, list, resolve, extract? It gestures at a domain but never commits to an operation, so an agent cannot tell whether it retrieves code, lists symbols, or exports data. It is marginally more than a restatement of the 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?

There is no when-to-use guidance, no exclusions, and no routing among the many siblings (storm_xrefs, storm_symbolize, storm_find, etc.). The only usable signal is the implied domain of net-session/Steam code, which an agent must infer.

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 as read-only, idempotent, and closed-world, so the safety profile is covered. The description adds a behavioral hint about byte mode finding call-site patches, but does not explain modes, limits, or result semantics beyond that.

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, which is structurally efficient. It is arguably too terse for a tool with six opaque parameters, but it avoids padding.

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?

An output schema exists and annotations cover the read-only safety profile, so return values need not be explained. Still, with six undocumented parameters and no alternative-tool guidance, the description is not complete enough for reliable 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?

With six parameters and 0% schema description coverage, the description must document parameter meanings. It never names or explains from_build, to_build, seeds, limit, include_same, or no_byte_diff; 'byte mode' only vaguely gestures at one parameter.

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, 'batch function diff between builds', and hints at a mode via 'byte mode finds call-site patches'. However, it does not distinguish this tool from sibling tools like storm_diff or storm_batch, and 'call-site patches' remains unexplained.

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 a batch diff across builds but gives no explicit guidance on when to choose this over storm_diff or other siblings, nor any prerequisites or 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?

The annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safe/offline profile is covered. 'Cheap and local' is consistent with these and adds a mild performance signal, but no error behavior, confidence semantics, or fallback behavior is disclosed.

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, front-loaded with the action before any detail. The second half enumerating return fields (build/program/sha/rva/va/name/confidence/source) is largely wasted space given an output schema already exists.

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 3-param resolution tool with an output schema, the core purpose and locality are covered, but 'build' is undocumented, the return-field list duplicates the output schema, and there is no routing guidance among the many storm_* siblings. 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 description coverage is 0%, so the description carries the burden. It compensates partially by stating the accepted target forms (VA, RVA, or full symbol name), which maps to the target param and the addr_kind enum, but the 'build' parameter is never explained and no format syntax (e.g., hex prefix) is given.

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 (resolve) and resource (symbol name / VA / RVA) and scopes it to 'one build', which is more precise than the bare title. It does not, however, distinguish itself from nearby siblings like storm_find or storm_symbolize, so an agent must infer the boundary.

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?

'Cheap and local' implies this is the lightweight first choice and hints at preferring it over heavier resolution paths, but no explicit when-to-use, when-not, or named alternative is given. Usage is implied 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=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not explain what 'dispatch' means here, whether anything is cached, or what the operation actually returns. The word 'dispatch' is ambiguous against a readOnly hint but not clearly contradictory.

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 fragment, so it wastes no words, but this is under-specification rather than conciseness. Nothing is front-loaded because there is essentially no content to front-load.

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?

An output schema exists, so return values need not be described. However, with three fully undocumented parameters, zero usage guidance, and an opaque purpose statement, an agent cannot reliably call this tool correctly.

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

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

Schema description coverage is 0% and the three parameters (build, limit, seeds) are completely undocumented. The description's mention of 'stage strings and boss ids' does not correspond to any of those parameter names, so it does not compensate for the coverage gap at all.

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 phrase 'Story scene/message dispatch' largely restates the tool name storm_scene_dispatch rather than stating a verb+resource action. 'Stage strings and boss ids' hints at the domain but never says what the tool actually does or produces, leaving it indistinguishable from siblings like storm_resolve or storm_frame_tick.

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, when-not-to-use, or alternative guidance at all, despite 21 sibling storm_* tools. An agent has no basis for choosing this over storm_resolve, storm_state_surface, or any other sibling.

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, and closed-world, so the safety profile is covered. The description usefully adds that reads come from a local SQLite hot-set cache with no Ghidra call, which explains latency/isolation behavior, but says nothing about pagination, result limits, or what the max_bytes build/symbolized options affect.

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 single clause is front-loaded with the verb and free of filler, which is good structure. But for a five-parameter tool with zero schema documentation it is arguably too terse to be 'appropriately sized', leaving the definition under-specified rather than lean.

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?

An output schema exists, so return values need not be described, and annotations cover safety. Still, the description omits any guidance on the five undocumented inputs and does not clarify what a 'hot-set entry' or 'build' means, leaving an agent unable to construct a correct call beyond the single required 'query'.

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 schema description coverage at 0% for five parameters, the description carries the full burden of explaining them, and it explains none. Terms like 'query', 'build', 'symbolized', 'limit', and 'max_bytes' are left entirely to the agent's guesswork, and 'hot-set' is never defined.

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 ('Read') and resource ('pre-decompiled hot-set entries from SQLite'), and the 'no Ghidra call' clause implicitly separates it from the Ghidra-backed siblings like storm_decomp. It stops short of naming those siblings explicitly, but the core purpose is clear.

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 'no Ghidra call' remark hints at the use case (fast lookup of already-decompiled data rather than invoking Ghidra), which is implied routing guidance. However, it never states when to prefer this over storm_decomp, storm_resolve, or storm_find, so the agent must infer the selection rule.

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 openWorldHint=false, so the safety profile is fully covered by structured data. The description adds genuine scope information beyond that (the five statistic domains), but nothing about freshness, cost, or aggregation behavior. With annotations carrying the safety burden, this is adequate but thin.

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 compact sentence with no filler, and the domain list is front-loaded. It is efficient, though the fragment style gives the agent less to anchor on than a full verb-led clause would.

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?

An output schema exists, so return values need not be described here. Still, for a multi-domain aggregate-statistics tool sitting among 21 siblings with overlapping map/state/diff concepts, the description leaves it unclear which subsystem question this answers and how granular the results are. Adequate but with a real routing 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, so there is nothing for the description to disambiguate; the baseline of 4 applies. The enumerated domains are the only semantic content and they map to output sections rather than inputs.

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 (statistics) and enumerates the domains covered (database, cache, BSim, map, index), so the agent knows roughly what comes back. However, it is a bare noun phrase with no verb and no differentiation from siblings such as storm_map, which plausibly also reports map-related information. Purpose is inferable but not sharply 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?

There is no when-to-use guidance at all: no indication of what question this tool answers, when to prefer it over storm_map or storm_state_surface, or what its output would let the agent do. The agent must infer intent purely from the label 'statistics'.

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 the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower. The description adds one genuinely useful behavioral fact — that results come from static inference rather than runtime observation — but says nothing about cost, build sensitivity, or confidence semantics despite listing 'confidence' as an output.

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

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

Two terse sentences with no filler, and the core capability is front-loaded before the static-inference caveat. It is dense but not padded.

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?

An output schema exists so return values need not be described, but for a seven-parameter static-analysis tool sitting among twenty-plus siblings, the definition provides no usage routing, no parameter meaning, and no filtering behavior. An agent cannot confidently construct a call from this description alone.

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?

Seven parameters at 0% schema description coverage, and the description explains none of them: build, limit, param, seeds, max_offset, and min_writes are entirely opaque. 'For a root object' loosely gestures at root, but the other six filters are undocumented in both schema and description, so the description fails to 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?

States a specific resource (field-access surface for a root object) and enumerates the returned data (offsets, sizes, r/w, functions, confidence), so an agent knows what it produces. However it never differentiates itself from siblings like storm_xrefs or storm_write_sites, and the noun 'surface' is jargon that only the enumeration rescues.

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 only guidance is the constraint 'Static inference only,' which hints at the static-vs-dynamic distinction but never says when to pick this tool over storm_xrefs, storm_map, or storm_write_sites. No prerequisites, no exclusion criteria, no 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and the description adds that output includes a mapping plus confidence values. However, the verb 'Rewrite' sits in tension with readOnlyHint=true and the description never clarifies whether renames are persisted or merely proposed, which is precisely the ambiguity an agent needs resolved.

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?

Single front-loaded sentence with zero filler, which is good, but for a 4-parameter tool with 0% schema coverage it is under-specified rather than genuinely concise.

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?

An output schema exists, so return shape needn't be explained, and annotations cover the safety profile. The remaining critical gaps are the undocumented parameters and the read-only-vs-persisted rewrite ambiguity, neither of which the description resolves.

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% across 4 parameters (build, target, addr_kind, max_bytes), so the description carried the full burden and adds essentially nothing: no explanation of what 'target' points at, what build means, or when to choose va vs rva. Only the placeholder prefixes hint at the address space being worked on.

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+resource: rewriting FUN_/SUB_/DAT_ placeholders into Storm names. An agent knows exactly what class of operation this is, though it doesn't explicitly distinguish itself from similarly-themed siblings like storm_map or storm_resolve.

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, no prerequisites, and no mention of alternatives (e.g., storm_map / storm_resolve). The agent must 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.

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, covering the safety profile. The description adds only 'with evidence and confidence,' a mild hint that results carry supporting evidence and confidence scores; it says nothing about format, limits, or how seeds/include_calls influence 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?

A single short sentence with no filler, but for a 9-parameter tool the terseness reads as under-specification rather than efficient front-loading, and its clipped grammar costs clarity.

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 output schema means return values need not be described, but with 9 undocumented parameters and no behavioral or selection guidance, one vague sentence is far too thin for a tool of this complexity. Key toggles like include_calls/include_reads and limit behavior are unaddressed.

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% across 9 parameters, so the description carries the full burden and largely fails. It loosely signals two addressing modes ('an address or root+offset'), which faintly touches target/root/offset, but leaves build, param, seeds, limit, include_calls, and include_reads 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?

The fragment 'Who writes an address or root+offset' conveys the resource (write sites) and the query shape, and pairs with the name storm_write_sites to suggest a write-reference lookup. However the question framing is grammatically awkward and never states plainly 'find code that writes to this location,' so the purpose is inferable rather than stated, and it draws no boundary against siblings like storm_xrefs or storm_find.

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, when-not-to-use, or alternative-tool guidance. With ~20 sibling storm_* tools covering resolution, xrefs, and symbol lookup, an agent gets no signal on why it should pick write-sites over xrefs for a reference question.

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 openWorldHint=false, covering the safety profile. The description adds that results are deduplicated and scoped to one function, but does not discuss permissions, rate limits, or pagination despite a limit parameter. It adds some context beyond annotations, but not rich behavioral detail.

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 sentence, front-loaded with the core output, and free of filler. It is terse but not bloated.

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 4 parameters at 0% schema coverage and no parameter detail in the description, an agent cannot determine how to set direction, limit, or build. Output schema handles return values and annotations handle safety, but invocation semantics remain underspecified.

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% for all 4 parameters. The description only implies the target is a function; it does not explain build, limit, or direction's to/from/both enum values. It mentions callers/callees but does not map them to direction, so it 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?

States a specific resource (xrefs: callers, callees, data refs) and scope (one function) with a qualifier (deduplicated). It does not distinguish from siblings like storm_find or storm_show, 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?

No when-to-use, prerequisites, or alternatives are given. The description simply states the output; it gives no guidance on choosing this over storm_find or storm_map.

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