debugger_variables

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description contributes only the word 'page', hinting at pagination, and says nothing about what happens on a stale generation, whether children are lazily fetched, or any failure mode. It stays consistent with annotations but adds little beyond 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?

A single front-loaded sentence with no filler — good density. The terseness borders on under-specification rather than verbosity, which is the opposite problem, but as writing it is tight and unambiguous.

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?

An output schema exists, so return values need not be described. However, this is a stateful debugger read requiring a generation-bound opaque reference, and the description omits how to obtain that reference, that it expires on resume, and what the pagination semantics are. For a 4-parameter tool with zero schema coverage, that leaves too much unknown.

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 burden. It gestures at two of four parameters implicitly ('page', and the locals/arguments/children target), but never explains timeout, session_id, or the page count/start defaults, nor the opaque VariablesRef shape. The nested definitions carry some meaning, but the description does not compensate for the top-level gap.

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

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

States a specific verb and resource: 'Read a page of locals, arguments, or object children.' An agent can tell this retrieves variable values from a suspended debug session. It offers no differentiation from the sibling debugger_scopes, which is the tool that supplies the reference this one consumes.

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 when-to-use guidance at all. It never says the `reference` must come from debugger_scopes or debugger_get, nor does it warn that the container expires on resume — a critical selector detail for a debugger tool. The agent must infer the whole call sequence from sibling names and the schema.

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