Trace Runtime Value Writes

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

The description discloses substantial behavioral detail beyond the annotations: it installs one temporary breakpoint/watchpoint at a time, resumes to the next confirmed writer, captures bounded evidence, removes only its own watch, and repeats. It also reveals a key limitation: the tool stops on unrelated debugger events rather than continuing through them. The destructiveHint and openWorldHint annotations are consistent with this live-target mutating behavior.

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

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

The description is dense but efficient, front-loading the core purpose, then usage context, then operational behavior, then exclusions. Every sentence earns its place, and no content is repeated from 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?

Given the tool's complexity, the description covers the essential operational model, safety preconditions, limitations, and unsupported uses. An output schema exists, so the description does not need to explain return values. The combination of schema, annotations, and description gives an agent enough context to decide when and how to invoke the 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 100%, and each parameter already has a meaningful description, including defaults, bounds, and semantics such as aggregation deadline and per-stop timeout. The tool description reinforces general concepts like 'bounded' and 'writer stops' but does not add significant parameter-level meaning beyond what the schema already provides.

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

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

The description opens with a specific verb and resource: 'Build a bounded temporal write timeline for one debugger-visible variable or expression.' This directly states what the tool does and differentiates it from broader debugging or dump-analysis tools by focusing on a single variable/expression and a timeline of writes.

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 when-to-use guidance: after differential or crash evidence identifies a suspicious value and live-target resume is safe. It also gives clear when-not-to-use conditions: crash dumps, unsafe-to-resume targets, and as root-cause proof. However, it does not name alternative sibling tools to use in those excluded cases, so it falls one step short of the strongest guidance.

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