extract_blobs

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

Annotations are uninformative (all four hints false), so the description carries the behavioral burden, and it delivers: it discloses the file-writing side effect, the concrete scan cap formula (max(limit*500, 20000) calls), and the silent-failure mode where blobs beyond the walk cap are simply not found. This goes well beyond what the annotations convey, though it stops short of covering file-naming or overwrite 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?

Three sentences, no filler: purpose first, then scoping guidance, then the walk-cap constraint with remediation. Every sentence earns its place and the highest-value operational warning (the scan cap) is positioned where the agent will see it before calling.

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 captures the hardest-won knowledge (the scan walk cap and its failure symptom) and the output schema covers return values, but gaps remain: the expected format of `trace` and `calls` is unspecified, and out_dir's default location/creation behavior is unstated. For a file-writing tool with zero annotation help and zero schema parameter descriptions, these are meaningful holes an agent would hit on first invocation.

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

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

With 0% schema description coverage, the description must compensate, and it meaningfully explains two parameters: `calls` (scope tightly; defines the scanned callset) and `limit` (scales the walk cap via max(limit*500, 20000)). However, `trace` and `out_dir` receive no added meaning — the schema's bare titles "Trace" and "Out Dir" are all an agent gets, and out_dir's default location is critical for a tool that writes files. Partial compensation warrants a 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 states a specific verb and resource: "Write binary arguments (shader bytecode, vertex/index/constant buffers) to files." The concrete payload examples (shader bytecode, vertex/index/constant buffers) distinguish this from sibling dump/list tools, since no other sibling extracts blob payloads to files. It is clearly not a tautology and names the artifact type precisely.

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 clear operational context: "Scope tightly with `calls`" with the reason (buffer uploads are large and many), plus an explicit conditional remediation ("narrow `calls` if the result looks short"). However, it does not name alternatives or state when-not-to-use this tool versus sibling tools, so it stops short of the explicit exclusion guidance that would earn a 5.

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