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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context by explaining that apitrace requires no host application but requires a build matching the game's bitness. This goes beyond the structured annotations and helps the agent understand operational constraints.

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 two sentences with no filler. It front-loads the core purpose with 'Preflight:' and immediately lists the three key output areas, then adds a concise usage note. Every sentence earns its place.

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 zero-parameter status/preflight tool with an output schema and strong safety annotations, the description is complete. It states what information will be retrieved, when to call it, and the key prerequisite regarding bitness. An agent has enough context to invoke it correctly.

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

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

The tool has zero parameters, so parameter-level documentation is not needed. The baseline of 4 applies because the description appropriately focuses on what the status call reports rather than parameter details that do not exist.

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 apitrace_status as a preflight/status tool covering installed builds, trace storage locations, and running processes. It is specific and useful, though it does not explicitly contrast itself with the sibling trace_status tool, which could also report on running traces.

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 instruction 'Call this before anything else' is an explicit and strong usage directive. It also notes that apitrace does not require a host application, unlike GUI-backed RE servers, giving contextual guidance. However, it does not name specific alternative tools or state when not to use this tool beyond the general preflight framing.

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

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

Annotations already cover read-only, idempotent, non-destructive traits. The description adds that scanning a full large trace is slow and that `limit` caps how many calls are read (default 200k), which is useful behavioral/performance context. No contradiction with annotations.

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

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

The description is two tight sentences: the first states the core purpose and value, the second gives the key performance caveat. Every sentence adds information and there is 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?

For a tool with four parameters and zero schema descriptions, the description is not complete: it omits the meaning of `top` and `calls`, and does not explain the required `trace` format. The presence of an output schema helps for return values, but the input semantics remain underspecified.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains `limit`'s purpose and default but leaves `top`, `calls`, and `trace` undefined; only the phrase 'call range' hints at `trace`/`calls`. With one of four parameters meaningfully documented, this is partial compensation at best.

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?

Describes the output as a function-frequency profile over a call range and positions it as the fastest high-level view of a game's behavior. The verb is implicit rather than explicit ('Returns/Computes'), and it doesn't name sibling tools like get_calls or search_calls to distinguish them, but the histogram concept is specific enough to separate it from raw-call tools.

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 phrase 'fastest way to see what a game does' gives a clear context for when the histogram is appropriate (high-level overview), and the limit warning addresses performance tradeoffs. It does not explicitly state when not to use it or point to a sibling alternative for raw call data, so the guidance is implied rather than explicit.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior; the description adds useful behavioral nuance by explaining that both storage orders are attempted and that flexible separators are accepted. This tells the agent how robust the tool is without contradicting the annotations.

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

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

The description is compact and front-loaded, with the core purpose in the first sentence and supporting input-format guidance in the second. Every sentence earns its place; there is no redundant information 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?

With an output schema present, the description does not need to explain return values. It adequately covers input format, float count, and storage-order handling, which are the main invocation requirements. Minor gaps remain around the optional label parameter and explicit sibling differentiation, but overall the tool is sufficiently specified.

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 description thoroughly explains the required 'values' parameter: exactly 16 floats, whitespace/comma/newline separated, paste-friendly from raw memory or shaders. However, the optional 'label' parameter is never described, and the schema gives no description either, so its purpose remains ambiguous despite its default value.

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 a specific verb and resource: 'Decode 16 floats as a 4x4 matrix' and enumerates the decoded fields (FOV, near/far, handedness, camera position). This clearly distinguishes it from sibling tools like find_matrices or track_camera, which search or track rather than decode a raw float buffer.

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 concrete usage context: paste numbers from a memory dump, Cheat Engine watch, or shader constant, and the tool accepts multiple separator formats. It also removes a common prerequisite by noting that both row- and column-major storage orders are tried. It does not explicitly name alternatives or exclusions, but the context is clear enough.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral detail beyond that: it reads the PE import table, includes delay-loaded imports, and explicitly does not launch the executable. This effectively tells the agent what side effects will not occur and what special case is handled.

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 three focused sentences, each earning its place: the first summarizes scope, the second explains the mechanism and non-side-effect, and the third highlights a relevant edge case. It is front-loaded with the most important information and contains 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?

With a trivial one-parameter schema, strong annotations, and an output schema present, the description covers the essential behavioral context, including the static-analysis mechanism and the delay-loaded import nuance. It could mention expected input path format or prerequisites, but nothing critical is missing for an agent to use this tool correctly.

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

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

Schema coverage is 0%, so the description must compensate for the single 'game_exe' parameter. The phrase 'Inspect a game executable' identifies what the parameter refers to, but it does not specify whether the value should be a full path, filename, or how to locate it. For a one-parameter tool this is workable, but the semantics are not fully specified.

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 ('Inspect') and resource ('game executable'), and concretely names the outputs: bitness, graphics API, and trace method. It also answers the likely user question ('is this D3D8 or D3D9, and is it 32-bit'), making the tool's role unambiguous among the many tracing and replay siblings.

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 clear context for when to use this tool: when you need to inspect an executable statically 'without launching anything.' It does not explicitly name alternatives or exclusion cases, but the framing strongly implies this is the pre-trace inspection step, which is sufficient for a tool with this narrow scope.

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

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

The annotations only indicate readOnly=false, destructive=false, and idempotent=false. The description adds substantial behavioral detail beyond those annotations: sidecars are written beside source prefixes, the wrapper refuses to run if any potential sidecar exists, and --overwrite is never enabled. This is exactly the kind of safety-relevant behavior an agent needs to know.

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 every sentence earning its place. It clearly separates the primary purpose from important behavioral caveats. It is not overly verbose, though it could be slightly better structured by explicitly labeling the parameters or constraints.

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 10-parameter tool with no schema-level parameter descriptions, this description is incomplete. It gives good safety context but fails to define the required prefixes or the key output/tuning parameters. Even with an output schema present, the agent lacks enough information to confidently construct a 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?

The input schema has 10 parameters and 0% description coverage, so the description had to compensate. It only vaguely references 'source prefixes' and never explains reference_prefix, source_prefix, fuzz, alpha, output, timeout, verbose, show_all, max_bytes, or extra_args. This leaves the agent to guess the meaning of most arguments.

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 action ('Compare image sets') and a concrete deliverable ('HTML report plus new diff/thumbnail sidecars'). It is clearly differentiated from trace-oriented siblings like diff_traces and diff_state, and from dump_images, by its focus on image comparison and sidecar generation.

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 intended use case is implied clearly: comparing image sets and producing diff/thumbnail sidecars. It also gives an important precondition (refuses to run if potential sidecars exist). However, it does not explicitly state when to prefer this tool over alternatives or provide exclusions, so usage guidance remains mostly implied.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds little beyond the operation itself; it does not explain side effects, large-state capture implications, or output behavior, but it does not contradict annotations either.

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

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

The description is a single, front-loaded sentence with no filler or redundant restatement of the tool name. Every word contributes to defining the core operation.

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?

Despite an output schema, this is an 11-parameter tool with 0% schema description coverage and only a one-line description. The required parameters are inferable from names, but the many optional parameters and their behavioral effects are left entirely unexplained.

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

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

Schema description coverage is 0%, and the description only indirectly maps 'two calls' to reference_call and source_call. Eleven parameters exist, including timeout, max_bytes, keep_images, ignore_added, source_trace, api, and extra_args, none of which receive any explanatory value from the description.

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

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

The description states a specific verb ('capture and compare') and a specific resource ('complete retracer state') at two call points. This clearly distinguishes it from single-state utilities like dump_state and from trace/image diff siblings.

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 guidance on when to use diff_state versus siblings like diff_traces, diff_images, or dump_state. It does not state when this tool is preferred or what conditions make it 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?

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds useful context by identifying the underlying semantic call-stream differ, which clarifies the nature of the comparison beyond what annotations state.

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 with no filler. It front-loads the core operation and the method used, and every word contributes to understanding the tool's 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?

With 12 parameters and zero schema descriptions, the one-sentence description is not enough for correct invocation. It explains what the tool does but not how to configure optional behavior such as call ranges, suppression, or extra arguments.

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

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

Schema description coverage is 0%, so the description carries the full burden for explaining parameters. It mentions none of the 12 parameters, not even the required reference_trace and source_trace, so it adds no meaning beyond the schema field titles.

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

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

The description names a specific verb ('Compare'), a resource ('two traces'), and a specific method ('apitrace's semantic call-stream differ'). This clearly distinguishes it from sibling tools like diff_images and diff_state, which compare different artifacts.

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 role of comparing two traces is implied well enough to know when the tool is relevant, but there is no explicit guidance about when to prefer this over diff_images or diff_state, and no mention of prerequisites or exclusions.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds behavioral context by specifying that output matches `apitrace dump` exactly and explains the callset syntax, which informs how the tool processes its input beyond the annotations.

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

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

The description is compact yet informative, front-loading the primary purpose and then providing necessary syntax details. It avoids redundancy and keeps the content focused, though the syntax explanation adds length.

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-value documentation is unnecessary. The description covers the main input format and differentiation from a sibling tool, but it does not mention edge cases like error handling or the effect of `timeout`/`max_bytes`, leaving a minor gap.

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

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

The `calls` parameter is thoroughly described with syntax examples, but the other parameters (`grep`, `trace`, `timeout`, `max_bytes`) have no schema descriptions and are not explained. Since schema coverage is 0%, the description only partially compensates, leaving ambiguity for several parameters.

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 that the tool produces a human-readable call dump formatted exactly as `apitrace dump` writes it. It also specifies a use case ('eyeballing a stretch of a frame') and differentiates it from `get_calls` for numeric arguments, making the purpose unambiguous.

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 explicitly advises when to use this tool versus `get_calls` (for numeric arguments) and even documents the full callset syntax for the `calls` parameter. This gives the agent clear guidance on when to select this tool and how to format its arguments.

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 discloses the main behavior: the tool replays the trace and writes PNG files, and it can do so per frame or per call. This goes beyond the annotations, which are all false and uninformative. However, it does not mention side effects like file naming, overwrite behavior, or whether a full trace replay could be expensive or long-running, leaving gaps in the behavioral picture.

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, with the core functionality front-loaded in the first sentence and the use case in the second. It avoids redundancy and stays focused, though the second sentence is slightly casual with phrases like 'and look'.

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—five parameters, one required, full trace replay, and file output—the description is not complete enough. It omits critical input semantics such as what mrt controls, what out_prefix does, and how calls is expressed. The presence of an output schema reduces the need to describe return values, but it does not fix the missing input guidance.

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 compensate. It adds meaning for the calls parameter via 'per frame, or per specified call' and for the output format via 'PNG images', but it leaves trace, mrt, timeout, and out_prefix entirely unexplained. This is insufficient for a five-parameter tool with no schema-level 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 states a specific action and resource: 'Replay the trace and write PNG images'. It also specifies granularity ('per frame, or per specified call'), which makes the tool's purpose clear. However, it does not explicitly compare against sibling tools such as diff_images or dump_calls, so it falls short of full differentiation.

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 a practical use case: 'finding *which* draw call produces the HUD, the world, or the problem'. This implies when the tool is useful, but it does not say when to prefer it over alternatives, nor when not to use it. There are many sibling tools, and the description provides no routing 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?

The description goes well beyond the readOnly/idempotent annotations by disclosing that replay executes on the local GPU, is slow, can fail on old games, and outputs JSON. It also clarifies an upstream limitation for DirectDraw/D3D7. These are non-obvious behavioral traits that an agent needs to anticipate.

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 main action is front-loaded in the first sentence, followed by a useful analogy and then caveats. The description is a bit longer than strictly necessary, but every paragraph contributes functional information. It is well structured and readable.

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 covers output format, execution cost, failure modes, and a fallback strategy, while annotations cover safety and idempotence. Since an output schema exists, return-value details are not needed. The only meaningful gap is the semantics of the optional api and timeout parameters, which keeps it from being fully complete.

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 parameter meaning. The description implies the roles of 'call' and 'trace' via 'up to a call' and 'run the trace', but it does not explain 'api' or 'timeout'. An agent can infer the required parameters from names, but optional parameters remain undocumented.

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

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

The description states a specific action ('Replay up to a call') and a precise result ('dump the full pipeline/device state as JSON'). This clearly distinguishes dump_state from siblings like dump_images, dump_calls, and diff_state. The RenderDoc analogy reinforces intent without obscuring 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?

The description gives concrete when-not-to-use guidance: DirectDraw and D3D7 traces cannot be replayed for state inspection. It also recommends trim_trace as a fallback when replay fails. It does not explicitly compare against diff_state or other alternatives, but the context is sufficient for an agent to decide when this tool applies.

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 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.

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

The description adds rich behavioral context beyond the readOnly/idempotent annotations: shadow register file tracking, piecemeal upload resolution, register-range reporting, buffer byte offsets, transpose storage orders, and grouping by slot. There is no contradiction with annotations.

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

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

The description is thorough but well-structured: a crisp lead sentence, bulleted technical coverage, a result-reading legend, and scoping guidance. Every section adds value, and there is no filler or repetition of schema defaults.

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 complex tool with seven parameters and no schema descriptions, the description is largely complete: it explains what is detected, how results are reported, and how to interpret each kind. It falls just short only because required-parameter semantics (`trace`) and a few tuning parameters are left to inference, though the output schema covers return shape.

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 prose must carry parameter meaning. It does explain `calls`, `scan_buffers`, and the `kind` result categories, but it never names the required `trace` parameter, nor does it explain `limit`, `min_confidence`, or `scan_constants` as explicit knobs. Partial compensation, but a real gap remains.

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: 'Find and classify every 4x4 matrix the game sends to the driver.' It then enumerates exact coverage areas (fixed-function transforms, shader constants, buffer uploads) and result kinds, which also separates it clearly from sibling tools like track_camera and decode_matrix.

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 gives clear scoping advice ('Scope with calls; a single frame is usually enough and far faster') and explicitly points to track_camera as the confirmation alternative for camera candidates. It does not systematically explain when not to use this tool versus the many sibling trace-inspection tools, but the intended use case is strongly implied.

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

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

Annotations already mark it readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral constraint that the input must cover exactly one frame and that the tool decomposes that frame, but it doesn't describe output or limit behavior. With the output schema present and no contradiction, this is reasonable but not rich.

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 sentences, front-loaded with the tool's purpose and then the usage prerequisite. There is no filler and nothing that merely repeats the schema or 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?

The definition gives enough to attempt an invocation: purpose, an example callset, and how to obtain frame boundaries from trace_info/list_frames. However, trace is never described and limit's meaning/effect is left unexplained, which is a clear gap given 0% schema coverage. Because an output schema exists, not explaining the return shape is acceptable.

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 needed to carry parameter meaning. It explains the calls parameter through the '120000-125000' example and 'one frame' scope, but says nothing about trace or limit. This is only partial compensation for the missing schema 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 states a concrete analysis action ('Break a frame down') and enumerates the summary categories (draw calls, render-target switches, shader binds), so an agent can tell this is a frame-scoped analysis tool rather than a raw call retriever. It doesn't name an alternative sibling, but the frame-level framing distinguishes it from tools like dump_calls, get_calls, and search_calls.

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 explicitly instructs the caller to pass a one-frame callset, gives a concrete format example, and names trace_info(per_frame=True) and list_frames as the way to find frame boundaries. It lacks an explicit when-not-to-use statement or alternative-selection guidance, so it stops short of full 5.

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

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

Annotations already establish readOnly/idempotent/non-destructive, so the burden is on added behavioral context. The description adds that long arrays and blobs are summarized and that calls can be read from a file via '@file.txt', giving useful expectations about output fidelity.

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?

Compact and front-loaded: the purpose and summarization behavior appear before the syntax reference. The syntax list is long but necessary for callset expressions and contains no wasted words.

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?

Complex callset syntax is covered in depth and an output schema is present. But the description doesn't define `trace`, `limit`, `max_list`, or `name_filter`, and doesn't situate the tool among 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?

Provides thorough semantics for the `calls` parameter with concrete callset syntax examples. Other parameters (limit, max_list, name_filter, trace) are not explained, and schema has 0% description coverage.

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 it returns structured calls with real argument values via apitrace pickle, making the core function identifiable. It doesn't explicitly name sibling alternatives or contrast with dump_calls/search_calls, so differentiation is weaker than a top-tier description.

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 callset syntax and examples implicitly define when to use the tool: to select specific calls or ranges from a trace. However, it never states when to choose this tool over sibling tools such as dump_calls or search_calls, nor 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?

The description adds one meaningful behavioral detail beyond annotations: it preserves replay setup state, which suggests that certain GL setup calls are retained during trimming. However, it does not describe what happens to the original trace, whether output is written in place, side effects, or how it relates to readOnly/destructive hints. No contradiction with annotations.

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

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

The description is a single sentence with no filler; 'OpenGL-specific' and 'preserves replay setup state' are the two most decision-relevant facts and are front-loaded. It is concise, though the brevity contributes to the overall lack of completeness.

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 an 8-parameter tool with zero schema coverage, the description is far too thin. It gives no guidance on output behavior, parameter usage, default effects, or when to use this instead of the sibling trim_trace. The presence of an output schema and all-false annotations does not reduce the need for more operational 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?

With schema description coverage at 0% and 8 parameters, the description had a responsibility to clarify key parameters like setup_frames, output, swap_to_finish, or keep_all_states. It only vaguely references 'setup state', which maps weakly to setup_frames. The description provides almost no parameter-level meaning.

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 the tool as an OpenGL-specific frame trim, distinguishing it from the generic sibling trim_trace. It also mentions preserving replay setup state, which adds useful purpose-specific context. However, it lacks an explicit verb like 'trims' and reads more as a noun phrase than a directive.

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 phrase 'OpenGL-specific' implies this tool should be used for OpenGL traces rather than generic trace trimming, and 'preserves replay setup state' hints at a key selection criterion. But there is no explicit guidance on when to choose this over trim_trace or other alternatives, nor any exclusions or conditions.

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 mark destructiveHint, but the description adds critical context: existing DLLs from ENB/ReShade/dgVoodoo/DXVK are backed up and restored by uninstall_wrapper. It also discloses that a left-behind wrapper keeps tracing every run, making the mutation and cleanup obligations explicit.

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 paragraphs with no filler: the action, the exact use case, and the hazard/cleanup warning. Every sentence earns its place, and the key scoping condition appears near the front.

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 fully covers the manual-route rationale, the failure mode it solves, the DLL conflict behavior, and the cleanup obligation—essential safety context. It falls short only by leaving three parameters undocumented, which is a real but secondary gap given how well the workflow is explained.

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

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

Schema description coverage is 0%, and the description only indirectly maps to game_exe ('next to a game exe'). The parameters api, force, and trace_file are never explained, so an agent would still need to guess their meaning and effect.

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 action ('Drop apitrace's wrapper DLL next to a game exe') and labels it 'the manual tracing route', immediately distinguishing it from trace_launch. The resource and scope are clear, so an agent can tell what this tool is for.

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 instructs to use this when trace_launch produces nothing, with concrete scenarios such as launcher-spawned games and DRM re-launches. It also says the wrapper works even from Steam and warns to uninstall when done, giving clear when-to-use and follow-up 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 establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the context that this runs apitrace's checker, which is consistent with the annotations, but it doesn't disclose details like whether a report file is produced, how large the output can be, or any runtime implications. With the annotations carrying the burden, the description adds modest context — no more.

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

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

A single sentence with zero wasted words, front-loaded with verb and resource. It is appropriately sized for a simple tool and every word earns its place.

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

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

The output schema exists, so return values are covered structurally, and annotations cover the safety profile. The one-liner adequately captures the tool's purpose. However, with two undocumented parameters and no usage guidance, the overall package has a clear gap: an agent cannot be fully confident about what timeout and max_bytes control. For a low-complexity tool this is still adequate but not complete.

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 bears the full burden of explaining parameters. It only clarifies the required 'trace' parameter. The two integer parameters, timeout and max_bytes, receive no explanation in either the schema or the description — an agent is left guessing whether max_bytes limits the trace scanned, the report size, or something else. Given 0% schema coverage, the description insufficiently compensates.

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 ('Run'), a specific resource (apitrace's object-leak checker), and a target ('against a trace'). It clearly distinguishes itself from the sibling trace-analysis tools such as dump_calls, call_histogram, and diff_images, none of which check for object leaks. An agent can understand exactly what this tool does without opening the schema.

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 context is implied: you run this when you want a leak report from an apitrace. However, there is no explicit when-to-use guidance, no mention of prerequisites (e.g., a trace must already exist), and no discussion of when to choose this over the many sibling trace-analysis tools. The absence of an overlapping sibling lowers the cost of this gap, but the guidance is still only implied.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds useful behavioral meaning: the output values are call numbers that can be reused as scoping inputs elsewhere. It does not describe pagination, ordering, or behavior for invalid trace names, but for a simple read-only list tool this is acceptable.

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 13-word sentence with no filler, repetition, or irrelevant detail. Every word contributes meaning: it states what is returned, in what form, and why it matters.

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 list tool with a rich output schema, read-only annotations, and defaults on optional parameters, the description is nearly adequate. The missing piece is explaining how count and start affect results; otherwise an agent can invoke it with just trace and understand the output concept.

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 had to compensate by explaining parameters. It does not mention trace, count, or start at all. The agent must infer that count and start control pagination from their names and defaults alone, which is not enough given the complete lack of schema documentation.

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

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

The description clearly states that the tool returns frame boundaries in terms of call numbers and that this is intended for scoping other queries. It is a fragment rather than a full sentence with an explicit verb, but the resource and output format are unambiguous. It doesn't explicitly name siblings or contrast with frame_summary, so it misses 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?

The phrase 'so you can scope other queries to one frame' gives a clear intended use case and tells an agent why this tool exists. It does not list alternatives or say when not to use it, but the context is clear enough to guide selection among the listed 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond those annotations: sessions can persist across server runs and may still be running, a non-obvious detail that affects how an agent interprets the 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?

The description is a single, front-loaded sentence with no filler. Every word contributes: it names the resource, states the scope is all sessions, and highlights the persistence caveat.

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 parameterless, read-only listing tool with an output schema and safety annotations, the description covers everything an agent needs to understand the call's scope. The only minor gap is explicit sibling differentiation, but the context and annotations make the behavior sufficiently complete.

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

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

The tool has zero parameters, so there is no parameter burden for the description to carry. The 100% schema description coverage and empty properties object mean the description does not need to explain any inputs.

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

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

The description states the resource being listed ('All trace/replay sessions') and adds a meaningful scope detail: it includes sessions still running from a previous server run. This makes it clear it is a listing operation, but it does not explicitly differentiate itself from the sibling list_traces tool by naming the 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?

The phrase 'All ... including any still running from a previous server run' implies this is the broad, unfiltered session listing tool. However, there is no explicit guidance about when to prefer list_sessions over list_traces or other sibling tools, leaving the routing decision mostly to inference.

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

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

Annotations already establish readOnlyHint=true and idempotentHint=true, so no credit is needed for safety. The description adds useful output-behavior details ('source preview or bytecode size') but does not disclose behavior around the limit/max_shaders controls or the meaning of 'calls' versus 'trace'. This is acceptable given the annotations, but not richly transparent.

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 two sentences long, front-loads the core purpose, and uses the second sentence to point to the relevant sibling tool. 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?

Although an output schema exists and annotations cover the read-only profile, the overall definition is incomplete for a 4-parameter tool with zero schema description coverage. The required 'trace' parameter is unexplained, and the distinction between 'calls' and 'trace' plus the meaning of 'max_shaders' are absent, leaving gaps an agent must guess about.

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 compensate, but it provides no parameter-level meaning. It does not explain 'trace', 'calls', 'limit', or 'max_shaders', nor how they relate to 'source preview or bytecode size'. With four undocumented parameters, the agent is left to infer their roles from names alone.

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 ('List') and identifies a distinct resource type ('shader creation calls') with a concrete output feature ('source preview or bytecode size'). It is clear enough to distinguish from generic call-listing siblings like get_calls and search_calls, though it does not explicitly name the siblings it differs from.

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 clear context for one alternative: 'Use extract_blobs to write D3D shader bytecode out for disassembly.' This implies list_shaders is for previewing/sizing rather than extracting bytecode, providing useful routing without explicitly listing all when/when-not conditions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is consistent with them. It adds the 'trace directory' scope but does not disclose behavior such as sorting, recursion, or directory-format expectations; the output schema likely covers return shape.

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, direct sentence delivering the action and scope without filler. Every word earns its place, and the core purpose is front-loaded.

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 no-argument, read-only listing tool with safety annotations and an output schema, the description is sufficient for an agent to call it correctly. It misses explicit pointer to alternative tools, but that gap is more about usage guidance than invocation completeness.

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 no parameters, so the schema coverage is trivially 100%. The baseline of 4 applies because nothing further needs to be documented for invocation.

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 operation ('List') and resource ('trace files in the trace directory'). It is clear and distinct from siblings like list_sessions or trace_info, though it does not explicitly name 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?

The description gives no guidance on when to use this tool instead of related siblings such as list_sessions, trace_info, or trace_status. There are no conditions, exclusions, or alternative tool mentions, leaving the agent to infer selection from 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 description only states the action and compression formats, without elaborating on side effects such as file overwriting, output handling, or the meaning of the 'output' parameter. The annotations indicate non-read-only, but the description adds no further transparency.

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, clear sentence that directly conveys the tool's purpose. It is well-structured and free of unnecessary words, achieving high 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?

While the description is concise, it lacks context on how to properly invoke the tool, including parameter meanings and expected outcomes. Given the absence of parameter descriptions, the agent may struggle to use it correctly.

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

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

No parameter definitions are provided in the description; the schema lists parameters without explanations. The description mentions 'compression' but does not clarify the roles of trace, output, quality, or timeout.

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 primary function—repacking a trace with compression options—which is specific enough to distinguish from typical trace analysis tools. However, it lacks explicit mention of what 'repack' entails beyond compression, so it's slightly above average.

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 no guidance on when to use this tool over alternatives like trim_trace or sed_trace. It does not mention any conditions or comparisons, leaving the agent to infer usage from sibling names.

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 adds meaningful behavioral context beyond the annotations: the operation runs in the background, is session-based, returns a session id, and produces profiling output in the session log. It does not contradict the annotations, and it explains the asynchronous nature better than the bare hint fields.

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

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

The description is short and front-loaded, opening with the core purpose and return value. The second block about profile values is useful but formatted as a bare fragment; still, it contains no filler and earns its place.

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 covers the asynchronous session model, return value, profiling profiles, and status polling. It is incomplete, however, because it does not explain the 'trace' argument format, the meaning of 'api', 'headless', or 'extra_args', or what conditions cause the replay to finish or fail.

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 parameter meaning. It documents the 'profile' parameter with its allowed values and its effect, but says nothing about 'api', 'trace', 'headless', or 'extra_args', leaving most parameters underspecified for an agent.

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 a specific verb and resource: 'Replay a trace in the background (session-based).' It also states the return value, a session id. It does not explicitly distinguish itself from sibling tools like trace_launch or sed_trace, but the replay action is distinct enough to understand the core purpose.

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 gives implicit workflow context by saying profiling output 'lands in the session log -- poll it with trace_status,' which tells the agent how to follow up. However, it does not explain when to choose this tool over alternatives, mention any exclusions, or describe prerequisites for replaying a trace.

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

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

Annotations already declare read-only and idempotent behavior, so the bar is lower. The description adds useful context beyond annotations: it searches only function names, returns counts/call numbers rather than full dumps, and implies a lightweight operation ('cheapest way').

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 sentences deliver purpose, return shape, and a practical example with no filler. The front-loaded first sentence tells the agent exactly what the tool does, and the second sentence earns its place by showing a real regex use-case.

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 provides good high-level context and an output schema exists to document return values. However, with five parameters and zero schema-level parameter documentation, important invocation details remain underspecified, especially the role of the optional 'calls' parameter and whether matching applies to substrings or full function 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?

Schema description coverage is 0%, so the description must compensate. It does clarify that 'pattern' is a regex over function names and gives a concrete example, but it leaves 'trace', 'calls', 'timeout', and 'max_hits' unexplained; 'calls' in particular is ambiguous.

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 ('Regex search') and resource ('function names across the trace') and states the return form ('counts and call numbers'). It is clear on its own, but it does not name or contrast sibling tools like dump_calls, get_calls, or call_histogram, so differentiation is left 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 a concrete diagnostic use-case and explicitly frames this tool as the cheapest way to detect fixed-function vs. shader-constant usage, with an example pattern. It stops short of naming alternatives or saying when not to use 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?

The phrase 'into a new trace' suggests non-destructive output, but the description does not state whether the original trace is preserved, how output is determined, or what side effects occur. Annotations provide no safety profile (readOnlyHint=false, destructiveHint=false), so the description carries the full burden, and it does not satisfy 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?

The description is a single front-loaded sentence with no filler. It states the core action and output immediately. However, it omits important operational detail, so it is concise but not fully effective.

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 7 parameters, 0% schema coverage, and no annotation support, this description leaves too much to inference. It does not explain how to construct a valid call, what calls/properties/expressions mean, or how output is chosen, so an agent cannot reliably invoke this tool correctly.

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

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

Schema description coverage is 0%, and the description only loosely maps to 'trace properties' and 'enum/string symbols' without explaining which parameters (expressions, properties, calls, extra_args, timeout, output) correspond to these concepts. It adds minimal meaning beyond the raw parameter names.

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

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

The description identifies a specific action, 'stream-edit', a resource, 'trace', and the target content, 'enum/string symbols or trace properties', with a clear outcome, 'into a new trace.' This distinguishes it from trace-manipulation siblings like trim_trace or repack_trace, though it does not explicitly name 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 guidance is given about when to use sed_trace versus trim_trace, repack_trace, diff_traces, or other trace tools. The description does not state prerequisites, favorable use cases, or cases where an alternative should be chosen.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful context that the output is JSON from apitrace info and includes API/call count/frame count, but it does not clarify what the per_frame parameter changes or whether the summary can be large. No contradiction exists.

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 sentence with no filler. It front-loads the core purpose and immediately lists the included fields and output format, making it efficient for an agent to scan.

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

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

The output schema and annotations cover the return shape and safety, so the description need not repeat those. However, with 0% parameter description coverage and no usage guidance, a key input (per_frame) remains ambiguous and there is no indication when trace_info should be selected over related siblings. This leaves an agent under-equipped 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 0%, so the description must carry parameter meaning. 'Summary of a trace file' weakly maps to the trace parameter being a trace file path, but per_frame is completely unexplained. The agent cannot confidently determine what per_frame=true means, and no format/path guidance for trace is provided.

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 names the resource (trace file) and directs the agent to a summary containing API, call count, and frame count, with the output identified as JSON from apitrace info. It does not use an explicit verb like 'returns' or 'gets', but the intent is unambiguous. It does not explicitly differentiate from siblings like frame_summary or dump_calls, though the summary focus is evident.

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 trace_info versus siblings such as frame_summary, dump_calls, call_histogram, or list_frames. The description only weakly implies it is for an overall overview of a trace file but provides no exclusions, alternatives, or selection criteria.

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 discloses the key behavioral trait that this runs the game and does not block, and warns about flushing cleanly on normal quit. Since annotations only carry generic flags with no safety detail, this extra context is valuable for an agent managing 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 main action and return value are front-loaded, followed by a concise non-blocking/cleanup note and a tight parameter legend. Every sentence earns its place, with no filler or repetition.

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

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

The description covers the launch lifecycle, session id, and the two least obvious parameters, but for a 6-parameter tool with zero schema descriptions it leaves output and working_dir unexplained and does not mention prerequisites such as wrapper installation. The presence of an output schema mitigates return-value documentation, but not these call-preparation 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?

Input schema coverage is 0%, and the description compensates for api and method by enumerating valid values and default behavior. However, args, output, and working_dir are left undocumented, so the compensation is only partial despite those being non-trivial parameters.

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 action and resource: 'Launch a game under apitrace and start capturing' and mentions it returns a session id. This clearly distinguishes it from siblings like trace_stop, trace_status, and replay_trace.

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 gives an explicit workflow: launch, let the user play, then call trace_stop after normal quit for a clean flush. It also gives conditional method guidance ('Try mhook when... IAT patching misses it') and explains empty api auto-detection. It doesn't explicitly name when not to use the tool, but the operational context is strong.

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

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context beyond annotations by clarifying that the tool polls session state and reports live progress, including trace size and log tail. It does not contradict the annotations and provides reasonable transparency for a read-only polling 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?

The description is a single front-loaded sentence with a colon introducing three concise, relevant output categories. Every word earns its place, with no wasted or redundant phrasing.

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 polling tool with one parameter, an output schema, and clear read-only/idempotent annotations, the description is largely complete. It conveys the operation, the resource type, and the main status content. Missing sibling differentiation and explicit usage guidance are real gaps but are not severe enough to make the tool unusable.

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%, but the description partially compensates by explaining that 'session' refers to a trace or replay session. This adds domain meaning to the single required parameter, though it does not specify the expected ID format or how to obtain a valid session identifier.

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 the specific verb 'Poll' with a clear resource: 'a trace or replay session', and enumerates the returned status items (still running, trace size, log tail). This clearly states what the tool does, though it does not explicitly distinguish it from closely named siblings like trace_info or apitrace_status.

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 when to use the tool—whenever a trace or replay session's status is needed—but gives no explicit guidance on when to prefer it over sibling alternatives, nor any exclusions or preconditions. The usage context is inferable but not directly stated.

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

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

Annotations already signal destructive behavior, so the description adds value beyond them by explaining the specific consequence: a forced kill prevents apitrace from flushing, losing the tail of the trace. This is useful behavioral context not present in the annotations.

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

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

Two sentences with no filler. The core action is front-loaded, and the important caveat about forced kills is presented immediately after. Every sentence earns its place.

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 two-parameter stopping tool, the description is largely complete: it states what the tool does, what input matters, and a critical failure mode. The output schema covers return behavior. It does not explain how to discover session IDs, but that is inferable from sibling tools like list_sessions.

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 parameter-semantics burden. It implicitly references the force parameter through 'forced kill' and identifies 'session' as the target, but it never explicitly explains either parameter's expected format or how to obtain a valid session value.

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 begins with a specific verb and resource: 'Stop a session and report the resulting trace.' This clearly defines what the tool does and distinguishes it from sibling tools like trace_status, trace_launch, and list_sessions.

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 clear operational guidance: prefer quitting the game in-game first, and warns that a forced kill can lose the trace tail. It does not explicitly name alternative tools, but the when-to-do-it guidance is concrete and actionable.

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

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

Annotations already cover read-only/idempotent behavior; the description adds the meaningful behavioral detail that it auto-picks the most view-like matrix slot, allows `source` to override that selection, and uses eye-position movement across frames as a confirmation signal. This is useful operational context beyond the annotations.

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

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

The main purpose is front-loaded in a single concise sentence, followed by useful selection guidance and a confirmation hint. The second sentence is slightly dense, but it avoids redundancy and earns its place.

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

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

The output schema and annotations reduce the burden for return formatting and safety, and the description covers the tool's workflow well. However, given 0% schema coverage and a required `trace` parameter, the lack of guidance on what `trace` refers to and what `calls`/`limit` filter leaves an important invocation 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 0%, so the description must carry parameter meaning, but only `source` is explained (as a slot name from find_matrices). The required `trace` parameter is not described, and `calls`, `limit`, and `max_frames` receive no semantic explanation in the description either.

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 ('follow') and a precise output set: world position, forward vector, and FOV. It distinguishes itself from find_matrices by explaining that this tool selects the most view-like matrix slot automatically, rather than simply returning matrices.

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 gives clear context: use it to track the camera across frames, and if the automatic slot is not enough, pass `source` with a slot name from find_matrices. It even suggests the confirmation workflow before moving to Ghidra/ReGenny, though it does not state explicit conditions for when not to use it or how it compares with decode_matrix.

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 indicate the tool is not read-only, not idempotent, and not destructive. The description adds meaningful behavioral context: the raw slice's replayability characteristics, performance benefits, and the risk that a mid-run OpenGL slice may omit setup/resources. This goes beyond the annotations without contradicting them.

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 tightly written with no filler. The purpose is in the first sentence, followed by concise but valuable usage guidance and an explicit alternative. Every sentence earns its place.

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 strong on purpose, usage guidance, and behavioral context, and the output schema covers return values. However, with four parameters and zero schema descriptions, the lack of parameter-level detail is a real gap that makes the tool not fully self-sufficient 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 0%, so the description must explain parameters. It only implies 'calls/frames' through 'call/frame slice' and 'slice beginning at call/frame zero,' but gives no syntax, defaults, constraints, interaction between calls and frames, or meaning of the output parameter. This leaves an agent guessing on how to fill in the arguments.

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 operation ('Make a raw call/frame slice of a trace') with a clear verb and resource. It also differentiates from the sibling gltrim_trace by describing the trade-off, so an agent can tell them apart 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?

The description gives explicit usage context: slices beginning at zero are replayable and speed up downstream tools. It also directs agents to gltrim_trace for mid-run OpenGL slices when replayability matters. It does not cover all sibling alternatives like sed_trace, but the key alternative is handled.

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 destructiveHint=true, and the description aligns with that by saying 'Remove' and 'restore backups.' The description adds the useful detail that backup restoration is part of the operation, but it provides no additional behavioral context such as whether the removal is irreversible, whether the game must not be running, or what happens if no wrapper is installed. With destructive annotation present, a neutral score 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?

The description is a single sentence that leads with the primary action and efficiently adds the backup-restoration behavior. Every word contributes information, and there is no filler or repetition of the tool name. It is appropriately sized for a low-parameter 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?

The tool is simple and has an output schema, so the description doesn't need to explain return values. However, the description leaves open practical questions: what exactly should be passed as game_exe_or_dir, what conditions are required before uninstalling, and what 'restore any backups' entails in practice. It is minimally adequate but not complete.

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

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

Schema description coverage is 0%, and the description does not explain the single parameter 'game_exe_or_dir' at all. The parameter name and title provide some semantic hint, but the description adds no guidance about what values are valid, whether a file or directory is expected, or how the path is used during uninstall. The description fails to compensate for the missing schema documentation.

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

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

The description clearly states a specific action ('Remove wrapper DLLs'), names the resource ('wrapper DLLs installed by install_wrapper'), and mentions restoration of backups. It distinguishes the tool from siblings by explicitly tying it to the inverse of install_wrapper. It loses one point because it doesn't fully disambiguate what happens to game files themselves beyond removing DLLs.

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 phrase 'installed by install_wrapper' implies this tool is meant for undoing an install_wrapper operation, which gives context for when to use it. However, it does not explicitly state when not to use it, what conditions must hold before running it, or how it relates to alternatives besides install_wrapper. Usage guidance is implied rather than stated.

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