DumpPeFromMemory

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, and idempotentHint=false, but the description adds genuinely non-obvious behavioral context: writable sections are reset from the bound template so CRT/loader state cannot poison reload, header templates are accepted only after executable-section identity verification, and entry_rva_override is bounded to an executable template section. This extra detail goes meaningfully beyond the safety flags, though it omits what output is produced and error 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?

Front-loaded with a one-line purpose followed by focused sentences about specific parameters and behaviors; each sentence carries domain-relevant content rather than filler. Density is high and appropriate for the complexity, though a couple of clauses (e.g. the reflective-PE note) could be tightened.

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 12-parameter mutation tool with no output schema and 0% schema coverage, the description covers the most subtle behaviors but does not address many parameters, does not state where the reconstructed PE is written or what happens on failure, and does not clarify relationships such as how image_size interacts with source_layout. Adequate but with clear gaps for a tool this complex.

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

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

Schema description coverage is 0%, so the description must carry the burden. It explains several parameters (header_template_path, entry_rva_override, source_layout, and implicitly verify_template_identity and reset_mutable_sections_from_template) with real semantic meaning, but leaves base, output_path, verify, overwrite, image_size, reverse_relocations, and minimum_template_similarity entirely unexplained, leaving half the surface undocumented.

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

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

States a specific verb and resource ('Reconstruct a disk-layout PE from a loaded memory-layout image'), which is far more precise than a tautology and clearly distinguishes the reconstruction task from inspection siblings like GetExports or DisasmRange. It does not, however, explicitly name the closest siblings (DumpModule, ValidateDump) to route the agent, so it stops short of 5.

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

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

The description implies usage context by describing scenarios ('destroyed/headerless images', 'embedded reflective raw PE staged inside a larger private allocation'), which tells the agent when certain features apply. But there is no explicit when-to-use-this-vs-DumpModule/ValidateDump guidance and no stated prerequisites or exclusions, leaving the agent to infer routing.

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