resume

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states side effects ('advances code execution until next breakpoint or completion'), prerequisites, and the return confirmation. It does not mention whether the operation is reversible or if it alters breakpoints, but the core behavioral impact (execution resumes) is clearly disclosed. This is more than adequate for the tool's purpose.

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 concise and well-structured. Each sentence delivers distinct value: the action, side effects, prerequisites, return, usage guidance, and alternatives are all clearly separated. It front-loads the core function and keeps the description to four sentences without 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?

For a tool that simply resumes a debugger, the description covers all essential aspects: what it does, conditions for use, what to expect as a result, and alternatives. There is no output schema, but the description's return statement ('confirmation of resume command') suffices. An agent has everything needed to call 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?

The input schema provides 100% coverage for both parameters (tab_id and instance_id) with clear descriptions. The tool description does not add new parameter semantics, but none are needed since the schema already explains them. Baseline of 3 is appropriate here.

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 function: 'Continues full execution of the debugger from current breakpoint.' It uses a specific verb ('continues') and resource ('full execution of the debugger'), and explicitly distinguishes itself from single-step alternatives, making it easy for an agent to differentiate from siblings like step_over.

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 says when to use it ('Use this to continue program flow after inspection') and names alternatives ('step_over' or 'step_out' for single-step execution). It also states the prerequisite: 'requires an active, paused debugger session.' This leaves no ambiguity about when to select this tool over others.

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