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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that schema returns 'name:offset' strings, explains the substring filter behavior, the huge unfiltered output, and the distinction between count and total_matched. It does not detail interface-specific behavior or potential errors, but the core behaviors are well covered.

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 compact and front-loaded with 'CS2-specific', then quickly lists operations and key caveats. It avoids wasted words but is a bit dense and run-on, using abbreviations and a dense format that could be more readable. Still, every sentence contributes useful 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?

Given the tool has two operations and no output schema, the description covers crucial return information ('name:offset' strings, count/total_matched) and the major pitfall (unfiltered schema). It omits details about what the interface operation returns and when to use interface vs. schema, but overall it is sufficiently complete for an agent to use effectively.

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 significant value by explaining that filter is a substring match, that unfiltered schema is huge, and that the limit defaults to 100 with a max of 2000. It also clarifies the optional 'all' flag indirectly through the 'ALWAYS pass filter' warning, going beyond the schema's parameter descriptions.

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

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

The description clearly identifies this as a CS2-specific tool for querying interface and schema information, distinguishing it from sibling tools. It lists the two operations (interface, schema) and what they operate on, though it lacks an explicit verb like 'query' or 'get' and leaves the interface return format somewhat ambiguous.

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

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

The description provides clear context: it is CS2-specific, and for schema operations it strongly instructs to always pass a filter because unfiltered results are huge. It does not explicitly name alternative tools or when-not-to-use scenarios, but the 'CS2-specific' framing and operation details serve as effective guidance.

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

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

No annotations are supplied, so the description must disclose side effects and return behavior. It only states diff returns changed offsets and explains the values flag; dump and emulate return/side-effect behavior, snapshot prerequisites, and error cases are absent.

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 compact line that front-loads the high-level purpose and then encodes each op's signature with required vs optional markers. No filler words; every element contributes.

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 14 parameters, nested objects, and no output schema/annotations, the description omits output formats for dump/emulate, snapshot label lifecycle, and prerequisites. It gives signatures but not enough surrounding context for reliable invocation.

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

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

Schema coverage is 100%, so baseline applies; the schema already documents each parameter's purpose/limits. The description adds operation-grouping and shorthand but no substantial parameter semantic beyond what schema properties provide.

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

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

The description names three concrete operations (dump/diff/emulate) with their key arguments, so the agent can tell this is a snapshot/diff/emulation tool. It doesn't explicitly contrast with sibling re_vm/re_disasm, so it loses the top score.

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

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

It implies when each op should be used (dump for snapshots, diff for comparing, emulate for execution) and marks optional parameters with '?'. It never states when not to use this tool or names alternatives, so a capable agent would still need to infer context.

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

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

With no annotations, the description carries the burden; it provides useful preconditions (e.g., rtti "first qword must be its vtable ptr") and operation semantics. However, it does not disclose output format, failure behavior, or explicitly confirm read-only/no side effects.

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 compact line that front-loads the tool's purpose and uses a terse, readable ops syntax. Each operation and optional parameter earns its place; 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?

The tool is complex (6 operations, 10 parameters, no output schema or annotations). The description covers all ops and params but lacks return-value/behavior information for operations like "bounds" and "analyze_fn". It is adequate but 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?

Although the schema already documents each parameter with defaults and op-specific descriptions, the description adds value by grouping parameters into per-operation signatures (e.g., "vtable {address,max_entries?,disasm_preview?}") and clarifying the rtti precondition. This helps agents assemble valid calls beyond the flat 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 clearly states the tool is for "Disassembly & code analysis" and enumerates discrete operations (disasm, vtable, rtti, gensig, bounds, analyze_fn) with their parameters. It is specific about the action and resource, but does not explicitly differentiate from sibling tools like re_read or re_proc.

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 guidance is implied through the operation templates (e.g., "disasm {address,count?,size?,bytes?}"), but the description never says when to prefer this tool over alternatives or when not to use it. It provides no exclusions or scenario-based direction.

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

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

No annotations are provided, so the description must carry the full behavioral disclosure burden. It implies a read operation with 'resolve' but does not explicitly state that it returns information, describe the output format, or note any error conditions. This is a significant gap for a tool with no output 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?

The description is a single sentence that front-loads the core purpose and compactly lists the operation variants. Every word is functional, with no redundancy or 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?

The tool has no output schema, so the description should explain return values and potential outcomes, but it only lists input parameters. It does not describe what 'resolving' a module or export yields (e.g., addresses, structures, success/failure), leaving the agent without adequate expectations for the result.

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

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

The schema already provides descriptions for each parameter (100% coverage), but the description adds value by mapping ops to parameter groups (module uses name, export/import use module_base with export_name/import_name). This clarifies the conditional relationships between parameters, going slightly beyond the schema's basic descriptions.

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

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

The description clearly states the tool resolves module internals and lists three specific operations (module, export, import), which distinguishes it from sibling tools like re_disasm or re_scan. The operations are specific enough to infer the tool's function, though 'module internals' could be slightly more explicit about what is returned.

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 op templates provide clear usage context for each operation (module {name}, export {module_base,export_name}, etc.), telling the agent exactly which parameters to use. However, it does not explicitly mention when not to use this tool or point to alternatives among the 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only lists operations without explaining side effects, permissions, error conditions, or whether operations mutate state. For example, 'attach' and 'detach' likely affect process handling, but the description does not disclose any of these consequences.

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

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

The description is a single, concise line that front-loads the purpose and lists operations compactly. It is efficient and skips unnecessary words, though a structured list could improve readability slightly. The brevity is a strength, not a weakness.

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 the tool's complexity with five distinct operations and no output schema, the description is under-specified. It does not explain what each operation returns or what 'tebs' stands for, and it lacks any context about expected behavior or edge cases. A multi-operation tool like this benefits from more detail per operation.

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 input schema already provides descriptions for all parameters (100% coverage), so the description adds limited value. It does offer a compact mapping of parameters to operations (e.g., {name?|pid?} for attach), but this information is largely present in the schema's parameter descriptions. The notation does clarify that name/pid are optional, which is a slight addition.

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

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

The description clearly states the tool's domain as 'Process lifecycle & validation' and enumerates the available operations (attach, detach, info, is_valid, tebs). This distinguishes it from sibling tools focused on modules, disassembly, etc. However, it does not elaborate on what each operation does, leaving some ambiguity (especially 'tebs').

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 usage context is implied by the operation list (e.g., attach for process attachment, is_valid for address validation), but there is no explicit guidance on when to choose this tool over alternatives or any exclusions. The description does not mention situations where other tools would be more appropriate.

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 burden of behavioral disclosure. It only says 'Read memory' and lists operation signatures; it does not describe return formats, side effects (e.g., that it is strictly read-only), error handling, or permission requirements.

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 dense sentence with no filler and is front-loaded with 'Read memory'. However, the long list of operations in one line is less scannable than a structured list, though it remains appropriately concise overall.

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

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

For a tool with 16 parameters and no output schema or annotations, the description provides compact signatures for all nine operations and the supported types. However, it does not describe the shape or format of returned data (e.g., how bytes or values are formatted), nor does it address error cases, leaving the agent to infer behavior from operation names.

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 already documents all 16 parameters with 100% coverage, but the description adds meaning by mapping each operation to the parameters it accepts (e.g., 'ptr_chain {base,offsets[],final_type?}', 'values {address,type,count?}') and marking optionality with '?'. This op-to-parameter mapping is not present in the schema itself.

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 opens with 'Read memory', a specific verb and resource, then enumerates the distinct read operations (bytes, values, string, ptr_chain, etc.). This makes the tool's scope unmistakable and differentiates it from sibling tools like re_write, re_disasm, or re_scan.

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

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

Usage is implied from the operation list and the phrase 'Read memory', but there is no explicit statement about when to use this tool versus siblings like re_scan or re_disasm. No exclusions or alternative tool references are provided.

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 fully discloses key behaviors: the 256MB default scan range when module_name/start+size are omitted, that page_limit/max_results cap returned results not scan cost, the 120s caller-side timeout with no cancellation of the AS loop, and heap_regions chunking with overlap and alignment default. These are non-obvious and crucial for an agent to invoke the tool correctly.

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 dense and information-rich but well-structured: it lists ops in a compact notation, then provides critical notes. It could be more scannable with bullet points, but it avoids waste and efficiently conveys a lot of required nuance for a complex 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?

For a tool with 7 operations and 19 parameters, the description covers all ops, parameter relationships, and key behavioral constraints. It does not explicitly state the return format or types, but with no output schema, the description's scope is reasonably complete for an agent to make correct invocations.

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 each parameter is already documented. The description adds value by mapping parameters to operations, clarifying defaults (e.g., alignment default=val_size), and explaining behavior like page_limit not affecting scan cost. This goes beyond schema text and helps the agent understand interactions.

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

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

The description clearly states 'Search process memory' and enumerates seven distinct operations (pattern, pattern_all, value, ptr_to, heap_regions, xrefs, string_refs), each with its parameters. This makes the tool's purpose unmistakable and differentiates it from sibling tools like re_read or re_write.

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 does not explicitly list when to use this tool vs alternatives, but it implies usage context by detailing operations and parameters. It includes important usage caveats (e.g., page_limit caps returned results, heavy scans have a 120s timeout) but lacks explicit 'when not to use this' or alternative tool references. This is minimum viable 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?

Given no annotations are provided, the description carries the full behavioral burden. It discloses key operational details: compact defaults to TRUE, pagination has a default/max limit of 500/5000, and responses include has_more/total_matched. It also reveals alloc creates RWX memory regions, which is critical safety context. However, it omits error behavior and side effects for free/vquery.

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 extremely concise, front-loading the domain and then structuring each operation in a compact syntax. Every element (ops, parameter lists, defaults, pagination note) contributes value. The shorthand notation is dense but not wasteful, though the occasional ambiguous punctuation (e.g., question marks in braces) could be clearer.

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 10 parameters, four operations, and no output schema, so behavioral and return-value details are important. The description covers pagination and response fields for vad, but does not explain return formats for vquery, alloc, or free, nor how errors or invalid addresses are handled. While it is comprehensive for a terse reference, the lack of output schema means more return/error context would be expected.

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 the input schema covers all parameters with descriptions (100% coverage), the description adds crucial semantics by mapping each operation to relevant parameters and noting defaults (compact TRUE, limit 500). It also documents response fields (has_more/total_matched) not present in the schema. This significantly helps an agent choose and fill parameters correctly for a multi-op tool.

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 identifies this as a virtual memory tool and enumerates four distinct operations (vquery, vad, alloc, free), each with its own parameter list. This distinguishes it from sibling tools like re_read/re_write that handle memory directly, and the operation-specific syntax clarifies what the tool does, though the verb is implied rather than explicitly 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 explicit guidance is given about when to use this tool versus alternatives. The description does not mention exclusions or preferred contexts, nor does it compare to sibling tools like re_read or re_scan. The only usage hints are the operation list, which implies the scope but does not state when this tool is the right choice.

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 of behavioral disclosure. It reveals the supported operations and data formats, but fails to mention that memory writes are destructive and irreversible, may corrupt the target process, require attached permissions, or have alignment/endianness constraints. This is a critical gap for a mutation 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?

The description is extremely compact, using shorthand notation to convey operation signatures and supported types in a single line. Every word contributes; there is no filler or redundancy.

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 adequately summarizes the core functionality and parameter mappings, but it omits important contextual details such as destructive side effects, process requirements, alignment/endianness, and error behavior. Given the lack of annotations and output schema, more behavioral context is needed for safe autonomous use.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by mapping each operation to its required parameters (e.g., bytes uses address+data, values uses address+type+values) and providing a compact type enumeration, which helps the agent understand parameter combinations beyond the schema's isolated property descriptions.

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

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

The description opens with 'Write memory,' a specific verb+resource phrase that immediately identifies the tool's purpose. It distinguishes from sibling read/disasm/scan tools by being the write operation, and it enumerates four distinct operation modes (bytes, values, string, wstring).

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 statement of when to use this tool versus alternatives, nor any exclusions or prerequisites. The name and sibling context make it obvious that this is the write counterpart to re_read/re_scan, but the description itself provides no guidance on selection or situational use.

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