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

With no annotations, the description carries the full burden, but it does disclose the key behavioral trait that the operation is an upsert ('add or replace' an existing bookmark at the address). It does not state whether the bookmark persists to the IDB, what permissions are needed, or what the response returns.

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 core action front-loaded and no wasted prose. The second sentence is slightly redundant with the schema's prefix description, which keeps it just shy of a 5.

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, and the schema fully documents the parameters. For a simple mutation tool the description is nearly complete, though the absence of annotations leaves persistence and permission behavior unstated.

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

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

Schema coverage is 100%, so the schema already documents all four parameters including the prefix default and instance_id. The description's only added parameter hint ('Set prefix="" for no prefix') merely repeats what the schema already says, so the 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?

The description states a specific verb and resource ('Add or replace the IDA bookmark at an address'), naming the exact effect and target. No sibling tool overlaps with bookmarking, so no differentiation is required and an agent can select it unambiguously.

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 or when-not-to-use guidance, no prerequisites, and no alternatives named. The only hint is the prefix='' instruction, which is a parameter detail rather than usage routing.

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

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

Annotations declare readOnlyHint=true, so the safety profile is covered, but the description adds no behavioral context beyond that: it doesn't warn that analysis is potentially expensive/heavy, note that output volume scales with the number of queries and enabled sections, or mention any timeout or truncation behavior. For a batch tool with 16 per-function toggles this is a real gap.

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; the purpose arrives immediately. It is efficient but borders on under-specification for a tool with this much configurable surface.

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 the description still omits routing versus analyze_function, guidance on section selection, and any note on cost/limits. For a complex batch tool with rich per-query options, one sentence is not sufficient context.

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% and every field (addr, include_*, max_*) carries its own description, so the baseline of 3 applies. The description adds nothing about how to shape the queries array or what instance_id does beyond the schema's own note.

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 (analyze) and resource (target functions) and conveys batch scope via 'one or more', which distinguishes it from a single-function variant. However, it never names the obvious sibling analyze_function or explain what 'comprehensive' entails, so the agent cannot confirm the distinction from the text alone.

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 guidance at all: nothing about choosing this over analyze_function, when batching is preferable to repeated single calls, or how instance_id interacts with the current target. The agent must infer usage entirely from the name and 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?

readOnlyHint=true already covers the safety profile, so the description's job is smaller. It adds the useful detail that analysis spans a call graph and shared data across functions, but does not state cost, scale limits, or what happens with unrelated addresses, so it only modestly exceeds what annotations provide.

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

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

A single front-loaded sentence with a colon-delimited list of outputs; every clause carries information and there is zero 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, so return values need not be spelled out, and annotations cover safety. However, 'related' is never defined (related by call graph? by address adjacency?) and multi-address grouping behavior is left ambiguous, leaving a gap for a tool whose whole premise is grouping.

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 addrs (comma-separated or list) and the optional instance_id are fully documented in the schema. The description adds no syntax or semantics beyond that, making baseline 3 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?

States a specific verb ('analyze') and resource ('related functions as a group') and enumerates the outputs: per-function summaries, internal call graph, shared data. This distinguishes it from analyze_function (single) and analyze_batch, though it never names those siblings explicitly.

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 word 'group' implies usage (analyze several related functions together), but there is no explicit when-to-use, when-not, or named alternative among the many sibling tools like analyze_function, analyze_batch, or callgraph. The agent must infer the selection condition.

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 only declare readOnlyHint=true, so the description carries the rest and does so usefully: it discloses that this is a bundled summary covering multiple data families (pseudocode, strings, constants, callers, callees, xrefs, blocks) and that output is condensed. That composite, compact nature is real behavioral context an agent cannot get from the annotations or schema.

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 tight sentence with the purpose front-loaded and the payload listed as a colon-delimited set. Nothing is wasted, though the list is terse enough that it functions more as a label than a full explanation.

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 all three parameters are documented in the schema. The description adequately conveys scope and payload for a read-only analysis tool; the missing piece is only routing guidance against sibling analysis tools.

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 addr, include_asm, and instance_id are already fully documented. The description adds nothing parameter-specific beyond the implicit 'compact' framing that relates to include_asm's default of false. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific action (analysis of a single function) and enumerates exactly what it returns: pseudocode, strings, constants, callers, callees, xrefs, blocks. This makes it distinguishable as an aggregate/overview tool versus focused siblings like decompile, callees, or basic_blocks, though it never names those siblings explicitly.

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 or when-not-to-use guidance is given. With close siblings such as decompile, survey_binary, func_profile, and analyze_batch available, the agent is left to infer that this is the lightweight composite option rather than a targeted one. The word 'compact' hints at a token tradeoff but the condition for choosing it is never 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?

With no annotations, the description carries the full behavioral burden. It discloses one trait — deduping exact text by default — which is already present in the schema's dedupe field, but says nothing about persistence, reversibility, permission requirements, or error behavior for a mutating 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 tight sentence with the key distinguishing behavior front-loaded. It is efficient, though arguably too spare for a mutation tool with no annotations.

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 needn't be explained, but for a batched mutating tool with no annotations and an undocumented required 'items' parameter, the description leaves too much unsaid about preconditions, per-item semantics, and effects.

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 50%; the top-level 'items' parameter has an empty description. The description restates address/comment intent and the dedupe default (already in the schema) but adds nothing about scope values (auto|func|line) or instance_id selection.

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 (append), resource (comments) and target (addresses), and 'append' naturally contrasts with the sibling set_comments. It doesn't name or explicitly differentiate itself from set_comments, but the verb choice alone gives a reasonable signal.

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 guidance on when to use this versus set_comments, the obvious sibling, nor any prerequisite (e.g., whether a database must be open and saved). The only usage-adjacent statement is the dedupe default, which is behavior rather than when-to-use 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, so the safe-read profile is covered. The description adds the pagination behavior (offset/max_blocks), but does not disclose anything beyond the schema, such as multi-address batching semantics or ordering of returned blocks. With annotations and a full output schema present, a 3 is appropriate.

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 padding; the resource and pagination scope lead immediately. It is efficient, though almost too terse to carry any routing or behavioral context.

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 a full input schema, an output schema, and readOnlyHint annotations, the structured data carries most of the burden, and the description is minimally sufficient. It still omits any indication of how this differs from disassembly or function-listing siblings, which is the one contextual gap that matters.

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%, with each parameter (addrs, offset, max_blocks, instance_id) documented including defaults, max values, and example formats. The description merely restates the pagination parameters, adding no syntax or meaning beyond the schema, so the 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 ('Return function CFG blocks') plus the pagination mechanism, so the agent knows exactly what comes back. It does not differentiate from nearby tools like disasm, func_query, or list_funcs, which also surface per-function structural data, leaving sibling selection 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 description gives no when-to-use guidance, no prerequisites, and no named alternative for retrieving control-flow information. An agent must infer that this is the CFG-block tool rather than disasm or func_query based on the 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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds that results are unique and capped by limit, but does not disclose anything further about behavior such as instance targeting or output structure. With annotations covering safety, this is minimally adequate.

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. Every clause contributes directly to understanding what is returned and the cap behavior.

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, annotations cover read-only safety, and parameters are fully documented in the schema, so the description does not need to explain return values. However, for a tool with many graph-related siblings, it lacks routing guidance that would make selection unambiguous.

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 addrs, limit, and instance_id are fully documented in the schema. The description only restates the limit cap idea and adds no syntax or format meaning beyond what the schema already provides.

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: returning unique callees per function, with a limit cap. It is clear what the tool does, but it does not distinguish itself from related siblings such as callgraph or xrefs_to.

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

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

There is no when-to-use guidance, no alternatives mentioned, and no conditions for choosing this tool over callgraph or other graph/query tools. Usage context is only implied by the tool name and 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=true, so safety is covered. The description adds that the graph is bounded by depth/node/edge limits, which is useful behavioral context beyond annotations. However, it doesn't disclose behavior when limits are exceeded or other operational details. Score 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?

A single, front-loaded sentence with zero waste. It packs the action, source, and constraints into 11 words. Score 5.

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, return values needn't be explained. The description covers the core operation and its bounding behavior. It omits edge-case behavior when limits are hit, but given rich structured data, it's adequately complete. Score 4.

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 all parameters are already documented. The description only mentions 'depth/node/edge limits', which maps directly to existing schema fields without adding syntax or usage details. Baseline 3.

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 specifies a clear verb+resource ('Build bounded callgraph from roots') and indicates the traversal is scoped by depth/node/edge limits. It distinguishes from a simple callees tool by emphasizing multi-level traversal with bounds, though it doesn't explicitly name a sibling. Score 4.

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 guidance or alternatives. It simply states what it does, leaving the agent to infer when a bounded callgraph is preferable to alternatives like callees or xrefs_to. Score 2.

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

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

With no annotations, the description carries the full burden and does well: it discloses that other clients are unaffected, that the final lease cancels orphaned IDA Python execution, that the call blocks until the IDB shuts down, and that GUI-opened databases stay open. The one gap is whether unsaved changes are lost on release, which matters for a close operation.

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

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

Three sentences, front-loaded with the core action and its blast radius, then escalating to the final-lease edge case and the GUI exception. Every sentence adds a distinct fact with no filler.

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

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

An output schema exists so return values need not be explained, and the single parameter is covered by the schema. The description covers the key behavioral edges (final lease, blocking wait, GUI sessions) but omits the unsaved-changes question, which is the main remaining unknown for a close 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?

Only one parameter, and the schema already documents it fully (100% coverage) including the default and the 'release the current target' fallback. The description adds no format or semantics beyond the schema, so the 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 (release lease) and resource (an IDA database .i64/.idb) with scope qualifiers ('this session's lease', 'without disrupting other clients'). This is immediately distinguishable from open_database, save_database, and idb_save, which all operate on the same resource with different actions.

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 explains the consequences of closing but never routes the agent explicitly — it does not say to use save_database/idb_save first if changes must persist, nor when to prefer close over just letting a session lapse. Usage is implied by the action but no alternative is 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?

With no annotations, the description carries the full burden yet says nothing about mutation semantics: whether declarations overwrite existing stack variables, whether they fail on conflict, or what state the database must be in. It does not even disclose that this writes to the IDB.

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 no wasted clauses, but it is terse to the point of under-specification rather than efficient density.

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 mutation tool with no annotations, an undocumented required array parameter, and sibling tools that overlap in purpose, the description is far too thin; the output schema offsets some of this, but input-side and behavioral gaps remain.

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 50%: instance_id is documented in the schema, but the required 'items' parameter has an empty description and nested field meanings (addr/offset formats) are only terse labels. The description adds nothing about batching, item shape, or offset syntax 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 verb+resource (create stack variables) is identifiable, but 'typed stack declarations' is jargon that only marginally clarifies the operation, and nothing distinguishes it from nearby siblings like stack_frame, declare_type, or add/delete_stack.

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 versus stack_frame, declare_type, type_apply_batch, or delete_stack, and no prerequisites such as needing an open database or defined function.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing beyond the bare action. It does not say whether declarations persist to the IDB, whether they overwrite existing types, what happens on conflicting definitions, or what the output looks like.

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, front-loaded sentence with no filler. It is efficient, though its brevity is partly under-specification rather than disciplined conciseness.

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

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

An output schema exists, so return values need not be explained, and the two parameters are fully covered by the schema. Still, for a mutation tool with no annotations, the description omits persistence behavior, overwrite semantics, and usage context, leaving meaningful 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 100% and both parameters (decls, instance_id) are documented in the schema, so the schema does the heavy lifting. The description adds no syntax, format, or scoping detail beyond what the schema already states, making the baseline 3 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?

The description states a specific verb and resource ('Declare C type definitions'), so an agent knows it writes types into the local library. However, it does not distinguish itself from close siblings such as set_type, type_apply_batch, enum_upsert, or type_inspect, which an agent could easily confuse with this 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?

There is no when-to-use guidance, no statement of prerequisites, and no mention of alternatives among the many type-related siblings. The agent must infer usage entirely from the name and title.

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

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

With only readOnlyHint=true in annotations, the description adds useful behavioral context by stating it returns pseudocode and per-item errors. This tells the agent the output format and that partial failures are possible, though it does not discuss performance or analysis-state prerequisites.

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 redundant or wasted wording. It efficiently conveys the core action and output in one pass.

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 description need not explain return values in detail, and annotations cover the read-only safety profile. However, it provides no usage context relative to the many sibling analysis tools, leaving a meaningful gap for tool 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 100%, so the schema already fully documents all three parameters. The description mentions address(es) but adds no additional syntax, format, or constraint details beyond what the input schema provides.

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: 'Decompile function(s) at address(es); returns pseudocode and per-item errors.' It clearly states what the tool does, but it does not explicitly distinguish itself from siblings such as disasm or analyze_function.

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

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

The description offers no guidance on when to use this tool versus alternatives like disasm, analyze_function, or func_query. It simply states the action, leaving the agent to infer usage context on its own.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does not mention that this mutates the database/IDB, whether the change is reversible, what happens on invalid byte sequences at an address, or any permission requirements. It discloses only the bare conversion act.

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 the action front-loaded and no filler. However, the brevity tips into under-specification rather than true conciseness for a mutating tool.

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 for a database-mutating tool with no annotations and thin parameter documentation, the description omits usage context, mutation semantics, and error behavior that an agent needs before invoking it.

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 50%, and the top-level 'items' parameter has an empty description in the schema. The description only alludes to 'address(es)' and adds no detail about the item object shape, hex/decimal formatting, 'start:end' bounds, or the instance_id targeting parameter, so it 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 verb and resource: converting bytes into code instruction(s) at given addresses. This distinguishes it from the sibling make_data (bytes to data) and define_func, though the differentiation from those siblings is left implicit rather than stated.

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

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

No when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as make_data (the inverse operation) or undefine/disasm. The agent must infer context entirely from the name and siblings.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose one useful trait — that IDA infers bounds unless 'end' is supplied — but says nothing about permissions, whether existing definitions are overwritten, or what happens on invalid addresses.

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 default-bound behavior is front-loaded. However, its brevity comes at the cost of the context the tool actually needs.

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 mutation tool with no annotations and a required parameter whose schema description is blank, the description is too thin. An output schema exists, so return values need not be explained, but batching semantics and usage context should be.

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 50%, and the required 'items' parameter has an empty description in the schema, leaving its array-of-objects shape unexplained. The description partially compensates by clarifying the addr/end relationship, but does not explain the batching nature of 'items'.

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 verb+resource ('Define functions') but the operation is opaque — defining a function from bytes is not self-explanatory, and the description offers no frame like 'converts raw bytes at an address into a recognized function'. It does not distinguish itself from siblings such as define_code or analyze_function.

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, when-not-to-use, or prerequisite guidance is given, and no sibling is named as an alternative despite define_code and analyze_function being adjacent. The agent must infer the entire context of use.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether deletions are reversible, what permissions are required, how batch items are processed, or what happens when a name/offset is not found.

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 waste. It is appropriately terse for the tool's surface-level purpose.

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?

Although an output schema exists so return values need not be described, the definition is incomplete for a destructive mutation tool with no annotations and 50% schema coverage. It omits usage context, deletion semantics, and required parameter structure.

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%, with the required 'items' parameter left undocumented and structured as a confusing anyOf of array or object. The description mentions 'offset', but the schema exposes only 'addr' and 'name', and it does not explain the batch/list semantics.

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 ('Delete') and resource ('stack variables'), and identifies the selectors ('by name or offset'). It does not distinguish itself from sibling tools like declare_stack or stack_frame, 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?

Provides no when-to-use guidance, no prerequisites, and no comparison to alternative tools such as declare_stack or stack_frame. The agent must infer that this tool is used to remove existing stack variables.

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?

readOnlyHint=true already tells the agent this is a non-mutating analysis. The description adds useful context by naming the pattern categories covered and noting it returns per-flag results and details, but it says nothing about analysis cost, timeouts, or limits on functions that can be scanned.

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

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

A single front-loaded sentence that lists the detection scope and the return shape with zero padding. Nothing could be removed without losing 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile; the description covers purpose and detection scope adequately. Minor gap: no note about how this differs from the broader analyze_function report 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 100% and both parameters are documented there, including the optional instance_id fallback and the function_address meaning. The description adds no parameter-level detail beyond confirming the target is a function, 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 (detect) and resource (obfuscation patterns) and enumerates the concrete pattern classes checked (control-flow flattening, string encryption, anti-debugging, dead code). This distinguishes it from analysis siblings, though it never names an alternative tool directly.

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 when-to-use / when-not-to-use guidance and no mention of related siblings such as analyze_function or analyze_batch that also operate on a function. The agent must infer the entry condition (having a function address) from the schema 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?

No annotations are provided, so the description carries the full behavioral burden, and it does disclose the return shape {before, after, action_applied, changes_detected} and the exact effect of each action. What it leaves unstated is whether the edit is persisted/committed to the database or reversible, which matters for a mutation tool with zero annotation coverage.

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

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

Front-loaded with the action-then-observe behavior and tight overall, but the opening clause ('rename a function, set its type, or add a comment') is partially restated by the following 'Actions:' list, so one sentence is somewhat redundant.

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?

Covers the actions, their arguments, the intended workflow, and the return payload; an output schema exists so return values needn't be spelled out, and the remaining schema parameter (instance_id) is self-documented. Nothing required to invoke 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?

The schema documents addr/action/action_args/instance_id at 100% coverage, but the nested action_args is a bare untyped object; the description compensates by enumerating the per-action payloads ('rename_func' -> {name: str}, 'set_type' -> {type: str}, 'set_comment' -> {comment: str}), which is genuine meaning 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 concrete verb+resource: apply a specific edit (rename/set_type/set_comment) to a function and return before/after decompilation. It contrasts itself against the sibling pattern (rename then decompile separately), so an agent can distinguish it from 'rename', 'set_type', and 'decompile' without opening schemas.

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

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

Explicitly names the alternative workflow it replaces (calling rename then decompile separately) and the condition that selects it (verifying a rename or type change improved readability), plus a second scenario (confirming each change during batch renaming). When-to-use is stated, not inferred.

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 readOnlyHint annotation already establishes that this is a safe read operation. The description adds that results support offset/max_instructions pagination and optional total counting, but does not explain output shape, limits behavior, or permissions beyond what the schema provides.

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 wasted words. It names the action and the notable behavioral controls 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?

An output schema exists, so return values need not be explained, and all parameters are fully described in the schema. However, given the large set of disassembly-adjacent siblings, the description should do more to explain when this tool is preferable to decompile or instruction-query tools.

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 schema already documents all five parameters thoroughly. The description mentions offset, max_instructions, and total count, but adds no syntax or semantic detail 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?

The description states a specific verb and resource: disassemble a function, with pagination and total-count features. It is clear what the tool does, but it does not distinguish itself from nearby siblings such as decompile, insn_query, or basic_blocks.

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 explicit guidance on when to use this tool instead of decompile, insn_query, basic_blocks, or get_bytes. Usage is only implied by the word 'Disassemble', with no alternatives or exclusions 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?

readOnlyHint=true already tells the agent this is a safe read. The description adds essentially nothing behavioral beyond that: it does not mention multi-query batching semantics, that count=0 means all, instance_id fallback to the current target, or any rate/size limits. With annotations covering safety, the description contributes only restated structure.

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 padding, which is appropriately sized for a thin wrapper tool. It is efficient, though minimal to the point of under-specification for a tool of this breadth.

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 carry the safety profile. What is missing is the routing context: with ~60 sibling tools, a generic query tool needs at least a pointer to when it is the right choice. Minimum viable 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?

Schema description coverage is 100%, so the schema already documents every flag (kind, filter, regex, sort_by, offset, count, etc.). The description's mention of "typed filters, projection, and pagination" loosely maps to those params but adds no syntax or interaction detail. Baseline 3 when the schema does the heavy lifting.

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 generic verb+resource ("query IDB entities") and hints at capability areas (typed filters, projection, pagination). However, "IDB entities" is vague and never names the concrete kinds (functions/globals/imports/strings/names) that the schema exposes, and it does nothing to distinguish this from the many specialized siblings like func_query, xref_query, insn_query, and type_query.

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 guidance at all. Given the sibling list contains numerous purpose-built query tools, the agent has no signal for when the generic entity_query is preferred over func_query/list_funcs/imports_query. It states what it can do but not when to reach for it.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuine behavioral trait: the operation is idempotent. However it omits other relevant traits for a mutating tool, such as persistence (local to the database, requiring a save), permission needs, or what happens to existing members on conflict.

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 waste. It is arguably slightly under-specified for a mutation tool, but it is not padded or redundant.

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, return values need not be explained, and the parameters are well covered by the schema. Still, for a mutating tool with no annotations, the description should say more about scope and effect (local enum in the current database, non-destructive member upsert) than the single sentence provides.

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 schema already documents 'queries', the nested name/members/bitfield structure, and 'instance_id'. The description adds no syntax or format detail beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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 pair (create/extend) and resource (local enums) and adds the distinguishing modifier 'idempotent way'. An agent can tell it apart from the broader type tools (declare_type, set_type), though it does not explicitly name which sibling is the non-idempotent alternative.

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 when-to-use or when-not-to-use guidance, and no routing to alternatives like declare_type or type_apply_batch. The word 'idempotent' hints at a use case (safe repeated upserts) but leaves the choice between siblings entirely 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?

Since no annotations were provided, the description carries the full burden of behavioral transparency. It details critical operational characteristics such as returning 'the result plus stdout/stderr,' and importantly, that 'Imports, variables, and definitions persist for this agent's database lease.'

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 suffers from being a massive, highly detailed feature list, making it lengthy. However, given the nature of an arbitrary execution tool, the high density of crucial information justifies keeping it from a lower score.

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

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

The description is extremely complete for such a complex execution tool. It defines the operational scope (what can be done), the environment constraints (persistence, APIs), the input format, and the output behavior (result + I/O streams).

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?

Although schema coverage is 100%, the description adds deep semantic value to the `code` parameter. It specifies architectural requirements for writing code, such as using `run(db)` or `execute(db)` for function-style code, and defining the scope of the global variables (`db`, `ida_domain`).

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

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

The description clearly defines the tool as a general execution engine for IDA Python (IDAPython and ida-domain API). It distinguishes itself from specialized sibling tools (like `decompile` or `patch`) by providing a comprehensive list of arbitrary analysis capabilities the code can perform.

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 provides essential usage guidance by advising the agent to 'Look up API names with reference first.' Furthermore, the input schema reinforces this by stating, 'Call reference(query) first; do not guess the API shape,' guiding the agent on workflow.

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?

readOnlyHint=true is the only behavioral signal, and the description adds little beyond it. 'Export' is ambiguous about whether output is written to a file or returned inline, and there's no mention of permissions, limits, or handling of unresolved addresses.

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 efficient sentence with the formats front-loaded and no filler. It is appropriately terse, though it could have used the space to disambiguate the export behavior.

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 needn't be explained, and params are fully documented in the schema. However, the core ambiguity of whether this produces a file or a data payload is left unresolved, which matters for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents addrs, format, and instance_id with examples and defaults. The description only restates the format list, adding no syntax or edge-case detail 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 clear verb+resource ('Export function data') and enumerates the output formats. It doesn't differentiate itself from nearby siblings like decompile, list_funcs, or func_query, so an agent can't easily tell why it would pick this over them.

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 guidance, no conditions, and no alternatives named. The description never explains when exporting is preferable to querying or decompiling, leaving the agent to infer the use case.

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, so the safety profile is covered. The description adds the offset/limit pagination behavior, which is useful, but says nothing about result shape beyond what the output schema carries and nothing about rate or scope caveats.

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

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

A single tight sentence with no filler and the pagination trait placed at the end. It is appropriately sized, though somewhat telegraphic for a 5-parameter search tool.

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, return values need not be explained, and the schema covers all parameters. What is missing is context that would let an agent choose this tool over its many search siblings, so completeness is only minimally adequate.

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 every parameter (type, targets, limit, offset, instance_id) is already documented in the schema. The description only restates offset/limit pagination and adds no syntax or semantics beyond that, 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 concrete verb+resource ('Search strings/immediates/refs for targets'), so an agent knows it retrieves occurrences of specific values inside a binary. However, it never distinguishes itself from close siblings like find_regex, find_bytes, search_text, or xref_query, which an agent could easily confuse with this tool.

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

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

The description gives no when-to-use guidance, no prerequisites, and no comparison to alternatives. Given a large sibling set of similarly named search tools (find_regex, find_bytes, search_text, entity_query), the absence of routing guidance is a real gap.

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 readOnlyHint annotation already declares this a safe read. The description adds the wildcard and pagination context, but the offset/limit behavior is already documented in the schema parameters, so the added value beyond structured fields is thin. Nothing contradicts the annotation.

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, and the key capability is stated first. It is efficient, though arguably terse given the sibling landscape.

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 and full schema coverage, the description need not explain returns or parameters. It is minimally adequate, but missing sibling differentiation and any prerequisite context (e.g. reliance on an open/current database target) given the four related search tools.

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%, covering patterns, offset, limit, and instance_id, so the schema carries the parameter burden. The description's mention of '??' syntax adds a small amount that overlaps with the schema example '48 8B ?? ??'. 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?

States a specific verb and resource ('Search byte patterns') and names a distinguishing capability (?? wildcards, offset/limit pagination). However, it does not distinguish itself from closely related siblings such as find_regex, get_bytes, search_text, or 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?

The description only describes what the tool does, not when to choose it over alternatives. With siblings like find_regex and search_text available, an agent gets no guidance on which search tool applies to which case.

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 only declare readOnlyHint=true (safety profile), so the description adds real behavior: matching is case-insensitive, which is non-obvious and not stated in the schema, and results are paginated via offset/limit. It still omits any note on scope limits (e.g., which database/instance is searched by default) or match-count behavior at the 500 cap.

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

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

A single front-loaded sentence that names the operation, the matching mode, and the pagination model with zero filler. Nothing could be removed without losing 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?

An output schema exists, so return values need not be explained, and all parameters are covered by schema descriptions. The only meaningful gap is the absence of routing guidance relative to the many other search/lookup siblings, which an agent must guess at.

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 all four parameters (limit, offset, pattern, instance_id) are already documented with defaults and ranges. The description only restates the offset/limit pagination concept and adds no format or syntax detail for the regex itself, 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?

States a specific verb (search) and resource (strings) plus the mechanism (regex), so the agent knows exactly what the tool returns. It does not distinguish itself from nearby siblings such as search_text, find_bytes, or find, which leaves ambiguity about which search 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 description gives no when-to-use guidance, no exclusions, and never names an alternative search tool even though the sibling list contains find, find_bytes, and search_text. Usage must be inferred entirely from the name and title.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds genuinely useful behavior beyond that: it locates xrefs TO each address, generates a unique signature per xref site, and returns the shortest ones, which is non-obvious pipeline behavior an agent needs to interpret results.

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 tight sentences: verb/resource first, mechanism second, use case last. Front-loaded and free of filler, though the middle sentence could be marginally 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?

An output schema exists, so return values need not be explained, and the read-only annotation covers safety. The description covers purpose, mechanism, and use case adequately. The only minor gap is that it doesn't hint at how to choose among the related signature-generation siblings.

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 every parameter (top, addrs, format, max_length, instance_id) is already documented in the schema. The description only reinforces that it operates 'for each input address,' adding no syntax or format detail beyond the schema. Baseline 3 applies when the schema does the work.

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: 'Find signatures for code locations that reference an address.' It spells out the mechanism (finds xrefs TO the address, generates a signature at each xref site) which clearly separates it from siblings like make_signature, make_signature_for_function, and make_signature_for_range that operate on directly-signaturable targets.

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?

'Ideal for creating signatures for data addresses, vtable entries, or string references that can't be signatured directly' gives a clear when-to-use condition. It stops short of naming the sibling alternatives (e.g. make_signature for directly-signaturable code) as an explicit fallback, so it is context without exclusions.

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

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

No annotations, so the description carries the bundle and does well: it discloses that this is a state-invalidating side effect whose observable result appears on the subsequent `decompile`. It omits cost/performance implications of a full-cache regeneration and any concurrency or permission notes, which would be the remaining gap for an unannotated mutation-style 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?

Two tight sentences: the action first, then the trigger conditions and rationale. No filler, no repetition of the title.

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, return values need no explanation, and the description covers what the tool does, when to call it, and why. Everything needed to invoke it correctly 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 description coverage is 100%, so both `items` (including the omit-to-recompile-everything default) and `instance_id` are already documented in the schema. The description only echoes the 'one or more functions' scope without adding format or semantic detail, 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?

Specific verb (Invalidate) plus precise resource (Hex-Rays decompile cache) plus scope (one or more functions). Clearly distinguishable from siblings like decompile, which reads the cache rather than invalidating it.

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?

Explicitly names the precondition tools (`set_type`, `rename`, `set_op_type`, `make_data`) that require this call and explains the payoff: the next `decompile` returns fresh rather than stale pseudocode. This is the when-to-use guidance an agent needs, with a named downstream 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?

The readOnlyHint=true annotation already establishes that this is a safe read operation. The description adds useful behavioral context by noting sampled and optional details, but it does not mention permissions, rate limits, or execution cost.

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, front-loaded with the core action and scope. It wastes no words and is appropriately sized given that the schema and output schema carry the detailed structure.

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 handles return values and 100% schema coverage handles parameters, so the remaining need is usage context. The description omits when to choose func_profile over func_query, lookup_funcs, or analyze_function, leaving a routing gap for this profiling 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 100%; fields like addr, count, filter, sort_by, include_lists, and instance_id are all documented in the schema. The description adds no parameter meaning beyond that, so 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?

States a specific verb 'Profile' and resource 'functions' and clarifies that output includes summary metrics plus optional sampled details. It does not differentiate from sibling tools such as func_query, lookup_funcs, or analyze_function, so it earns 4 rather than 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?

Provides no when-to-use guidance, no prerequisites, and no named alternatives. It leaves the agent to infer context from the many sibling tools.

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?

readOnlyHint=true is already provided, and the description adds essentially no behavioral context beyond it — no note on pagination via count/offset, result limits, sorting, or how the multi-clause queries list is combined. For a query tool this leaves real behavioral gaps unfilled.

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 zero filler, and the sibling comparison is placed first. It is arguably too terse for a filtering tool, 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?

An output schema exists so return values need not be described, and the schema fully documents the two parameters. The remaining gap is that 'richer filtering' is undefined and pagination/sorting behavior is never surfaced, leaving the description only minimally adequate.

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 every parameter (count, filter, sort_by, min/max_size, etc.) is already documented in the schema. The description adds nothing about filter syntax or how the queries array/object alternatives behave, so the 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 (Query) and resource (functions) and explicitly differentiates from the sibling list_funcs by claiming 'richer filtering.' However, it never says what 'richer' means, so an agent must open the schema to learn the actual filter dimensions.

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?

Names list_funcs as the comparator, implying this tool is for cases needing more filtering power than list_funcs offers. But it gives no explicit when-to-use/when-not guidance nor states the concrete conditions that select it over the 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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful scope context by noting a full function scan, which signals that the operation may be expensive. It does not say whether the report is returned or written to disk, and it gives no cost, time, or output-location details.

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 front-loads the action (“一键生成结构化 markdown 报告”) and then states the purpose. There is no redundant or filler text.

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 tool has an annotation covering safety and a fully documented optional parameter. However, with no output schema, the description should clarify whether the markdown report is returned, saved, or shown elsewhere, and should distinguish this tool from the closely related get_analysis_report sibling.

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%, and the sole optional instance_id parameter is fully documented in the schema. The description adds no parameter-level guidance beyond the schema. Baseline 3 is appropriate when the schema already does the work.

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 supplies a specific verb and object, “一键生成结构化 markdown 报告,” which clearly states what the tool produces. It adds “帮助快速理解程序核心逻辑（全量函数扫描）” to set scope. However, it never distinguishes this tool from the sibling get_analysis_report, so the agent cannot tell which one to call.

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 “（全量函数扫描）” implies the tool is for a broad analysis pass, and “帮助快速理解程序核心逻辑” suggests a context where the tool is useful. There is no explicit guidance on when to use this tool versus get_analysis_report or analyze_batch, and no exclusions or prerequisites are given.

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?

readOnlyHint=true already establishes this is a safe read operation, lowering the disclosure bar. The description adds that it returns algorithm type and confidence, but that return content is already covered by the output schema, and it discloses nothing about detection coverage, false-positive behavior, or cost. It adds only marginal behavioral context beyond the annotation and schema.

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 the action, the algorithm list, and the return shape, all front-loaded with no filler. It is efficient, though the parenthetical list is somewhat long relative to the payload.

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 readOnlyHint covering safety and an output schema covering the return format (algorithm type and confidence), the description need not explain return values. It adequately frames a read-only detection tool, with the only gap being the absence of routing guidance against adjacent analysis tools.

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 are already documented in the schema (instance_id defaulting to current target, function_address as the target function). The description adds no parameter-level meaning beyond this, 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 (自动识别/automatically identify) and resource (common algorithms, listing md5/sha/aes/des/rc4/tea/xor/base64/crc32/zlib) and indicates the return value (algorithm type and confidence). An agent can immediately grasp what the tool does, though it does not explicitly name which sibling (e.g. detect_obfuscation) it should be chosen over.

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 guidance and no mention of alternatives such as detect_obfuscation or analyze_function, which are adjacent analysis tools. Usage is only weakly implied by the tool's own nature, and the description never says under what circumstances to reach for it.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds that the output is a full/unfiltered inventory spanning multiple entity classes, which is useful, but says nothing about cost or scope of the scan (a whole-database aggregation could be expensive) or whether the report is persisted.

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, front-loaded sentence with the parenthetical content list doing real work; nothing is padded. It is close to a restatement of the title, but it earns its place by naming what the report contains.

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, and the schema fully covers the lone parameter. What is missing is the decision context: with ~50 siblings including generate_analysis_report_md and numerous list tools, an agent cannot tell from this description when this report is the right call.

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% and the single optional instance_id is fully documented in the schema (including the 'use the current target' default behavior). The description adds no parameter-level meaning 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?

States a specific verb (generate) and resource (structured analysis report) and enumerates the contents: functions, globals, strings, entry points as a full inventory. However, it does not differentiate itself from the near-identical sibling generate_analysis_report_md, which leaves an agent guessing which report tool to pick.

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 guidance, no prerequisites, and no routing advice relative to siblings like generate_analysis_report_md, survey_binary, or the many list_* / entity_query tools that also enumerate functions and globals. The agent must infer the choice entirely from the name.

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

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

readOnlyHint=true already tells the agent this is a safe read, and the description adds nothing beyond that — no note on behavior for invalid/unmapped addresses, size limits, or what happens with large reads. It repeats the safety signal rather than extending it.

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 four-word sentence with no padding and the core action front-loaded. It is concise but arguably under-specified for a batched memory-read tool, so it earns only a middling score.

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 no explanation, but the empty description on the required 'regions' parameter and the absence of any usage or failure-mode context leave the definition too thin for a tool that reads arbitrary memory.

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 required 'regions' parameter has an empty schema description, and the tool description does not compensate by explaining that it accepts either a single {addr,size} object or an array of them. Only the nested addr/size and instance_id fields are documented, leaving the most important parameter semantics to inference.

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 (bytes from memory addresses), which separates it from siblings like get_string, get_int, and find_bytes. It is clear but minimal, with no explicit differentiation or scoping detail.

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 guidance on when to use this versus get_int, get_string, or find_bytes, nor any mention of prerequisites such as a loaded database or valid address range. The agent must infer usage entirely.

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, so safety is covered. The description adds useful content context – that the map combines static strings with runtime-recorded dynamic strings – but says nothing about whether a tracing session must have run, how the mapping is keyed, or what happens when no dynamic strings were recorded.

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 waste, and the content scope (static + recorded dynamic) is front-loaded. It is efficient, though arguably too terse to be maximally informative.

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, and the one parameter is fully documented in the schema. However, for a tool whose value depends on runtime recording state, the description omits the precondition and usage context, leaving it only minimally adequate.

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?

There is a single optional instance_id parameter and schema description coverage is 100%, so the schema already explains its meaning and default behavior. The description adds no parameter-level detail, which is the expected baseline when the schema carries the burden.

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 noun phrase naming the resource (a decryption mapping of dynamic strings) without an explicit verb, though the tool name get_dynamic_string_map supplies the action. It does distinguish content scope from siblings like get_string by noting it merges static strings with runtime-recorded dynamic strings, but the phrasing is vague about what is actually returned or produced.

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 get_string, get_global_value, or search_text. No prerequisites, no exclusions, and no indication of what state the target must be in (e.g., after a trace run) for runtime-recorded strings to be present.

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, covering the safety profile. The description adds 'heuristic', signaling approximate/non-exhaustive results, and lists example patterns, which is useful context beyond annotations, but it omits accuracy caveats or return format.

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 sentence, front-loaded with the core action and examples. No redundant words, though it could be slightly more structured with prerequisites or output hints.

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

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

Given 100% schema coverage and a readOnly annotation, parameters and safety are covered. However, with no output schema, the description should ideally describe the return format or prerequisites (e.g., requires decompiled function); it leaves these 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 100% for both parameters (instance_id and function_address), so the schema already documents them fully. The description adds no parameter-level meaning, making 3 the baseline.

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

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

States a specific action (extract flag/check constraint clues) and resource (decompiled pseudocode), with concrete examples (length comparisons, constant ==). Does not distinguish itself from sibling analysis tools like analyze_function or trace_data_flow, so a 4 rather than 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?

Provides no explicit when-to-use guidance, no prerequisites (e.g., must decompile first), and no alternatives among the many sibling tools. The implied usage from 'decompiled pseudocode' is minimal.

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, so the safety profile is covered. The description adds no behavioral context beyond that: it does not mention that multiple queries may be batched in one call, how missing symbols or invalid addresses are handled, or that instance_id retargets a different database.

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 or repetition. It is efficient, though it is arguably too terse to earn a 5 given the tool-specific nuances left unstated.

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 the two params are fully covered by the schema. What is missing is routing context against the many overlapping sibling read tools, which leaves the definition only minimally viable.

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 are already documented in the schema, and the description's 'address or symbol name' wording merely echoes the queries param. Baseline 3 is appropriate since the schema carries this dimension.

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 (global variable values), and the 'by address or symbol name' clause clarifies the lookup mode. It does not, however, distinguish itself from the sibling list_globals tool, so an agent must infer that this reads values whereas list_globals enumerates them.

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 and no mention of alternatives. With siblings like list_globals, get_int, get_string, and get_bytes all plausibly overlapping in purpose, the description never says when to prefer this tool over them.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description's 'Read...' clause is largely redundant with the annotation. It adds nothing about batch behavior (queries accepts an array of read requests), target/instance resolution, or failure modes for invalid addresses.

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 zero padding. It is efficient, though it errs toward under-specification rather than wasteful verbosity.

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, and the schema fully documents both parameters. What is missing is any mention that multiple reads can be batched in one call and any routing against sibling read tools, leaving the definition minimally viable for a simple read 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 100% – ty, addr, and instance_id all carry descriptions, and the queries array/object union is documented. The description adds no format, encoding, or addressing detail beyond what the schema already provides, so the 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: 'Read integer values from memory addresses.' That clearly identifies the operation and distinguishes it from a bare 'get' tautology. However, it does not differentiate from closely related siblings like get_bytes, get_string, get_global_value, or int_convert, which an agent would need to choose between.

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 names no alternative. With siblings such as get_bytes, get_string, get_global_value, and int_convert, an agent has no stated basis for picking get_int over those tools.

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?

readOnlyHint=true already declares this is a safe read, lowering the bar. The description adds value by disclosing the kinds of sites returned (conditional jumps, calls, anti-debug int 0x2d), but it says nothing about scanning scope, cost, or how the function address maps to results beyond what the schema implies.

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

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

A single, front-loaded sentence that gets straight to what is located and gives representative examples. Efficient with no padding, though it is quite terse given the tool's analysis role.

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, return values need not be explained, and the readOnly annotation covers safety. However, the description omits any workflow context (that this precedes patch/patch_asm), leaving a gap for an analysis tool operating among many sibling scanners.

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 (instance_id, function_address) are already documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, so the 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+resource: automatically locating patchable positions, and enumerates concrete categories (conditional jumps, calls, anti-debug int 0x2d). This distinguishes it from siblings like patch/patch_asm (which apply patches) and disasm, though it doesn't name those siblings explicitly.

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 when-to-use guidance, no mention of prerequisites, and no named alternative such as basic_blocks or disasm. Usage is only vaguely implied by the tool's purpose (find sites before patching), which leaves the agent to infer the workflow.

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

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

With readOnlyHint=true already declaring the safety profile, the description adds nothing behavioral: it does not say what encoding/null-termination is assumed, how invalid or unmapped addresses are handled, or whether multiple addrs produce per-address results. It merely restates the annotation-backed read semantics.

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, front-loaded phrase with no filler, which is structurally fine. The terse phrasing, however, leaves key semantics unspecified rather than being economically complete, so it only meets the minimum bar.

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 shape need not be described, and the annotations cover safety. What remains missing is the string-reading semantics a reverse-engineering agent needs (encoding, terminators, failure behavior), which is material for a tool whose whole purpose is decoding strings from raw addresses.

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 addrs and instance_id are already documented in the schema, giving a baseline of 3. The description adds no syntax, format, or batching detail beyond 'memory addresses', so it does not exceed the baseline.

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 verb and resource (read strings) and the source (memory addresses), so the basic action is unambiguous. However, it is essentially a restatement of the title 'Read strings from memory' and offers no differentiation from close siblings like get_bytes, get_int, get_global_value, or get_dynamic_string_map. An agent cannot tell from the text why it would pick this over those.

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 statement of prerequisites, and no mention of alternatives among the many memory-reading siblings. The agent must infer entirely from the name that this is the string-specific counterpart to get_bytes/get_int.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the loose working-file backing, the corruption risk from killing files (issues #446/#498), the deliberate refusal to use DBFL_KILL, and the differing behavior of in-place vs. new-destination saves. It still omits permission/auth requirements and any note about locking or reopen 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 core action is front-loaded in one short sentence, and the behavioral detail follows. The second sentence is long and leans on parenthetical issue numbers, but every clause conveys actionable behavior rather than filler.

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

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

With an output schema present, return values need not be described, and both parameters plus the save semantics are covered. The one real gap is disambiguation from the sibling save_database, which leaves an agent's tool-selection decision under-informed.

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, but the description earns above baseline by attaching mode semantics to 'path': empty means an in-place native save, a non-default value yields a compressed copy while working files are retained. The 'instance_id' parameter is left 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 first sentence states a specific verb and resource ('Save active IDB to disk, optionally to a provided path'), so the agent knows exactly what the tool does. However, it never acknowledges the near-identical sibling 'save_database', so an agent cannot distinguish the two from this definition alone.

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: the description explains what happens with an in-place save versus an explicit destination, which helps the agent choose a parameter value, but it gives no guidance on when to prefer this tool over save_database, close_database, or open_database, and states no prerequisites.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add behavioral context. It mentions offset/count pagination, but that is already spelled out in the schema, and it discloses nothing about ordering, result size, or instance scoping.

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 zero filler. Everything stated is relevant to invoking the tool, and 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 return values need not be explained, and annotations cover the safety profile. Still, for a tool with a near-identical sibling (imports_query), the description omits the one piece of context an agent most needs: how it differs.

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 schema already documents offset, count (including the '0 returns all' semantics), and the optional instance_id. The description repeats the pagination framing without adding syntax or defaults, 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 ('List imports') plus the distinguishing payload detail 'with module names'. However, it never differentiates itself from the sibling imports_query, leaving the agent to guess which listing tool to pick.

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 guidance, no prerequisites, and no mention of alternatives such as imports_query. The agent gets no help deciding between the two import-related tools.

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 readOnlyHint annotation already establishes this is a safe read, so the description must add its own behavioral value. It adds none: nothing about batch/multi-query semantics, glob-vs-regex interpretation, or that count=0 returns everything. Effectively it paraphrases the schema.

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 zero filler and the key differentiator (richer filtering) placed early. It is arguably too terse for a nested batch-query schema, but on conciseness alone it is efficient.

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, the notable structural feature — queries being an array/object of multiple import queries — is left entirely to the schema, leaving the description thin for this complexity level.

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 every parameter (filter, module, offset, count, instance_id) is documented in structured data. The description's phrase "richer filtering" gestures at filter/module but adds no meaning beyond the schema, 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 ("Query imports") and explicitly compares its scope to the sibling tool imports(offset,count). The differentiator "richer filtering" is vague about which filters are richer, but an agent can still tell it apart from the plain imports listing.

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?

Names the alternative (imports(offset,count)) and the condition that selects this one over it, so routing is clear. It stops short of saying when neither tool is appropriate or noting prerequisites such as an open database.

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

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

The description says 'apply likely types', which implies a mutating operation that changes the database's type information. However, the annotations declare readOnlyHint=true, creating a direct contradiction about whether side effects occur. The description does not clarify the discrepancy or describe what is modified.

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 wasted words. It is compact but under-specified, which is reflected in other dimensions.

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 that appears to apply type changes, the description omits critical context: what inferred types look like, whether existing types are overwritten, and why a readOnly annotation coexists with 'apply'. Although an output schema exists, the mutation-vs-readOnly ambiguity leaves the agent without enough behavioral information.

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 are documented in the schema. The description only restates 'target addresses' for addrs and says nothing about instance_id; with full schema coverage, the baseline of 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?

The description uses a specific verb-resource pair: 'Infer and apply likely types at target addresses.' It is clear what the tool does at a high level, but it does not differentiate itself from close siblings such as set_type, type_apply_batch, or declare_type.

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 versus alternatives that also set or query types. It also omits prerequisites or conditions such as whether addresses must belong to a function or stack frame.

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, so the safety profile is covered. The description adds almost nothing beyond that: it does not disclose that scopeless scans require allow_broad, that scanning is bounded by max_scan_insns, or that results are capped at 5000 — all behaviors that materially affect how the tool is invoked.

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 well-formed sentence with no filler and the core capability front-loaded. It is efficiently sized, though the brevity tips into under-specification rather than tight conciseness.

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

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

For a read-only query tool whose schema is fully documented and which has an output schema covering return values, the minimum an agent needs is present. However, the interaction between allow_broad, max_scan_insns, and the count/offset pagination window is left entirely to the schema, which is a meaningful gap for a nested-query 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 100%, with every one of the 15 nested query fields documented inline (mnem, op0-op2, op_any, start/end/func/segment, count, offset, include_disasm, include_fn, allow_broad, max_scan_insns). The description only restates 'mnemonic/operand filters and scoped scans,' adding no meaning beyond the schema, so the 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 ('Query') and resource ('instructions') and names the filter axes (mnemonic/operand) plus scope. It is clear what the tool does, but it never distinguishes itself from the many sibling query tools (func_query, entity_query, xref_query, imports_query), 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?

There is no when-to-use guidance, no mention of alternatives, and no stated prerequisites. The phrase 'scoped scans' hints that scoping matters but never says when a scopeless scan is appropriate or that allow_broad gates it.

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?

readOnlyHint=true already tells the agent this is a safe read-only operation, and the description adds nothing on top — no note on accepted input syntax (e.g., prefixes like 0x), how size/auto-detection resolves, or whether conversion is lossless. With annotations covering the safety profile, the description carries little additional behavioral signal.

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 is front-loaded and wastes no words, but its brevity comes at the cost of substance rather than from trimming redundancy — it largely restates the title.

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 100% schema coverage documents the parameters. Given the low complexity of a pure conversion tool, the definition is workable, though it leaves the agent inferring the tool's intent and scope entirely from structured fields.

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 the inputs object (with text/size) and instance_id are already documented, including the format list. The description adds no syntax or format semantics beyond the schema, which is the expected baseline-3 outcome when the schema does the work.

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 verb ("Convert") and a resource ("numbers") but "different formats" is vague — the actual format set (hex, decimal, binary, ascii) lives only in the schema. It does not distinguish itself from near-siblings like get_int or put_int, which also manipulate numeric values.

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 guidance, no conditions, no named alternatives. Nothing tells the agent whether this is for display formatting versus database value mutation, or how it relates to get_int/put_int.

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 readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful behavioral context by clarifying that it covers both GUI-opened databases and headless idalib workers, and that instance ids are returned, which is more than the annotation alone provides.

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 wasted words. It communicates the resource, scope, and distinguishing context efficiently.

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 zero parameters, a read-only annotation, and an output schema present, the description is complete enough for correct invocation. It explains what is listed and where the databases come from, leaving return-value details to the output schema.

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?

There are zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the schema description coverage is 100%, so the description's role here is appropriately minimal.

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: showing IDA databases currently open in the GUI or headless idalib workers. It also names the concrete artifacts (.i64/.idb) and mentions instance ids, which clearly distinguishes it from open_database and close_database.

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 word 'currently open' implies the tool's usage context, and sibling names like open_database and close_database make the broader workflow inferable. However, the description does not explicitly say when to use this versus alternatives or state any 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?

readOnlyHint=true already tells the agent this is a safe read, and the description adds nothing beyond that — it merely restates that filtering and offset/count pagination exist, which the schema already documents. No mention of result volume, default ordering, or behavior when filters match nothing.

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 lean sentence with no filler and the core action front-loaded. Efficient, though it is nearly a verbatim restatement of the title rather than adding new substance.

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 read-only list tool with 100% schema coverage and an output schema, the description covers what is needed to call it. Nothing critical is missing, though it provides no extra orientation against the many sibling query tools.

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 individual fields (filter, offset, count, instance_id) are already fully explained in the schema. The description only echoes pagination/filtering at a high level and adds no syntax or format detail beyond the structured data, 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 (List) and resource (functions) with a note on filtering/pagination scope. However it does not distinguish itself from siblings like lookup_funcs, func_query, or export_funcs, which an agent could easily confuse it with.

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 guidance, no prerequisites, and no mention of the sibling tools that also query functions. The agent is left to infer that this is the unfiltered-list option versus lookup_funcs or func_query.

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, so the safe read profile is covered. The description adds that filtering and offset/count pagination are supported, which is useful behavioral context, but it omits auth needs, rate limits, or other operational details.

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 no wasted words. It conveys the core purpose and the filtering/pagination capability 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?

An output schema exists and parameter descriptions are complete, so the description need not explain return values or parameter details. It is adequate for a simple read-only listing tool, though usage guidance is absent.

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

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

Schema description coverage is 100%, so the schema already documents all parameters including count, filter, offset, and instance_id. The description mentions filtering and pagination but adds no syntax or format meaning beyond the schema.

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