Skip to main content
Glama

step_out

Exit the current function during debugging. Waits briefly for the program to stop, returning success with pending state if the remainder takes longer than 5 seconds.

Instructions

Step out of the current function. Waits briefly for the program to stop; if the step is still executing after ~5s (e.g. the rest of the function is long-running), returns success with state "running" and pending:true — the session becomes "paused" when the step completes

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sessionIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does well: it discloses the ~5s wait, the timeout outcome (success with state 'running' and pending:true), and the eventual transition of the session to 'paused'. It omits error cases and whether a specific session state is required beforehand, but the async/timeout behavior is genuinely valuable information not available elsewhere.

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

Conciseness4/5

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

Front-loads the action ('Step out of the current function') before the timing behavior, and every clause earns its place. The second sentence is dense but conveys distinct, decision-relevant facts about the wait and return states.

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

Completeness4/5

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

With no annotations and no output schema, the description supplies the return-state and timing behavior an agent needs to interpret results. What is missing is the precondition (session must be stopped/paused) and any failure modes, but for a one-parameter step action it is nearly complete.

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

Parameters3/5

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

Schema description coverage is 0% and the single required sessionId parameter is never mentioned in the description. The parameter name is largely self-evident in this debugging-session toolset, so the gap is minor, but the description contributes no parameter semantics beyond the obvious.

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

Purpose5/5

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

States a specific verb and resource: 'Step out of the current function' with precise step-debugging semantics. An agent can distinguish it from step_over, step_into, and continue_execution purely from the description without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the step-debugging vocabulary and the returned state semantics, but the description never states the prerequisite (e.g. a paused/stopped session) or when to prefer step_out over step_over/step_into/continue_execution. No explicit when/when-not guidance is offered.

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