Skip to main content
Glama
openl-tablets

OpenL MCP Server

Official

Step (Into / Over / Out)

openl_step_trace

Step a suspended debug session once and return the new stack. Use 'out' to run the current frame to its exit, making its result inspectable; combine with breakpoints to find which table returned what.

Instructions

Step the suspended debug session once and return the new stack. For declarative rules (decision tables, spreadsheets, rating) the main move is type: 'out' — run the current frame to its own exit so its result is inspectable — combined with breakpoints; 'into'/'over' are advanced (imperative TBasic/loops). A step that finishes a frame first suspends at that frame's exit — the frame is still on the stack with completed: true and its result readable via openl_inspect_trace_frame (or pass withValues: true to bundle those variables into this response); the next step continues in the caller. An exception suspends at the throwing frame before it propagates. The stack is returned compact — steps only for the active frame; use openl_inspect_trace_frame for another frame's detail. Valid only while suspended. (openl_resume_trace differs: it runs to the next breakpoint or completion, not just to this frame's exit.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYes'out' (main tool for declarative rules — decision tables, spreadsheets, rating): run the current frame to its own exit so its result is inspectable, then continue in the caller. 'into' / 'over' are ADVANCED (imperative TBasic / loops): 'into' enters the next call or sub-step; 'over' advances to the next sub-step of the current frame (nested calls run through). For 'which table returned what', prefer 'out' plus breakpoints over stepping through expressions.
projectIdYesProject ID returned by backend. Use the exact 'projectId' value from openl_list_projects() response without modification or reformatting.
profileTopNoNumber of hotspots (slowest tables) in the 'profile' overview (backend default 20).
withValuesNoAfter the step, also return the active frame's variables (the same content as openl_inspect_trace_frame on the top frame) as 'variables' — saves the usual step→inspect round-trip when you step 'out' to read a frame's result. Default false.
includeTreeNoAlso return the executed call tree's ROOT node ('tree'), not just the bounded 'profile' overview (default false). Against a current OpenL Studio the tree is lazy — one level deep: the root's steps each carry a 'childrenTotal' count instead of nested children, so a large run is no longer returned whole. Drill into a branch with openl_expand_trace_tree; to find the hot table use 'profile' and replay into it with a breakpoint.
response_formatNoResponse format: 'json' for structured, round-trippable data (default), 'markdown' for human-readable output, 'markdown_concise' for a brief summary (1-2 paragraphs), or 'markdown_detailed' for full details with contextjson
Behavior5/5

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

The description discloses several non-obvious behaviors not present in the annotations: finishing a frame suspends at that frame's exit with completed: true, the next step continues in the caller, exceptions suspend at the throwing frame, and the returned stack is compact with only the active frame's steps. This substantially exceeds what annotations alone provide.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: core action, mode selection, frame-exit behavior, exception behavior, response shape, validity condition, and sibling differentiation. It is front-loaded with the essential operation before diving into nuances.

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

Completeness5/5

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

Even without an output schema, the description explains what the response contains (the new stack, optional variables, optional tree root), how the compact stack is scoped, when variables can be bundled, and how to get details for other frames. This is complete for a tool with significant debug-session complexity.

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

Parameters4/5

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

Schema coverage is 100% and parameter descriptions are already thorough, so the baseline is 3. The description adds extra strategic meaning beyond the schema, especially around the 'type' parameter ('out' plus breakpoints for declarative rules, into/over advanced) and the value of 'withValues' for avoiding a separate inspect round-trip.

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?

The first sentence names a specific verb and resource: 'Step the suspended debug session once and return the new stack.' It clearly differentiates this stepping behavior from related trace operations and the description goes on to contrast with openl_resume_trace and openl_inspect_trace_frame.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: it is 'Valid only while suspended,' recommends 'out' as the main move for declarative rules, marks 'into'/'over' as advanced for imperative code, and names alternatives such as openl_resume_trace and openl_inspect_trace_frame with the conditions that select them.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/openl-tablets/openl-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server