debug_step_overStep over the current statement and return the updated pause snapshot, allowing you to continue debugging without entering function details.
Step over the current statement and return the new pause snapshot. Lines are 1-based.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | No | Session id from debug_launch/debug_attach. Required when more than one session is live. | |
| timeoutMs | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds a useful detail by stating the result is a 'new pause snapshot' and that lines are 1-based, but it does not disclose timeout behavior, effects on breakpoints, or what happens if the target exits.
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 delivers the core behavior and return value, with the line-numbering note added as a compact clarification. 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 state-changing debugger control with two optional parameters and no output schema, the description covers the operation and return snapshot adequately. It could be more complete about what the snapshot contains and timeout/session behavior, but those are partially covered by the schema.
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 only 50%: sessionId is documented in the schema but timeoutMs is not, and the description contributes no parameter semantics. It does not compensate for the missing timeoutMs explanation.
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 operation ('Step over the current statement') and what it returns ('the new pause snapshot'). It does not explicitly differentiate from the sibling debug_step_into/debug_step_out tools, so it misses the top criterion for a 5.
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 behavior of stepping over a statement is implied, but there is no explicit guidance on when to prefer this over debug_step_into or debug_step_out, and no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.