Skip to main content
Glama
openl-tablets

OpenL MCP Server

Official

Start Debug Session

openl_start_trace

Start a table debug session and run to the first stop, returning the execution stack for step-by-step inspection. Use profiling mode to obtain a compact overview of the slowest tables instead of a large trace.

Instructions

Start an interactive debug session for a table and run to the first stop. Returns the execution stack (status + frames root→current). Default stopAtEntry: true suspends at the entry of the first frame; from there use openl_step_trace / openl_resume_trace and openl_inspect_trace_frame. For test tables pass testRanges (e.g. '2'); for regular rules pass inputJson { params, runtimeContext? }; omitting both replays the previous run's remembered input. Cheapest way to understand a whole run: profiling: true with stopAtEntry: false and no breakpoints — completes in this one call and returns 'profile', a constant-size overview of the top-N slowest tables (selfMillis/totalMillis/count) plus nodeCount/distinctTables/totalMillis. For a profiling overview pass inputJson (or testRanges) together with profiling: true and stopAtEntry: false EXPLICITLY every time — do not rely on replay (omitting the input): a replay only reproduces the compact profile if the remembered run was itself a profiling run, otherwise it can return a much larger stack that overflows the response limit. Find the hot or unexpected table in profile.hotspots, then replay into it with a breakpoint to inspect live values. The executed 'tree' is omitted by default; set includeTree: true to get its ROOT node (one level — each step carries a childrenTotal count) and browse a branch level by level with openl_expand_trace_tree. One active session per user — starting a new one terminates the previous. Idle sessions are reaped after ~10 minutes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tableIdYesTable ID to debug (e.g., 'calculatePremium_1234'). Get from openl_list_tables().
inputJsonNoFor regular rules: JSON input. Use object with params (required) and runtimeContext (optional). E.g. { params: { age: 25 }, runtimeContext: { lob: 'Auto' } }. Omit BOTH inputJson and testRanges to replay the previous run's remembered input (e.g. restarting with profiling or new breakpoints).
profilingNoRetain the executed call tree — structure and timings, NO values (default false). With stopAtEntry: false and no breakpoints the run completes in this single call and returns a constant-size 'profile' overview (top-N slowest tables); the tree's root node comes with includeTree: true and is browsed level by level with openl_expand_trace_tree.
projectIdYesProject ID returned by backend. Use the exact 'projectId' value from openl_list_projects() response without modification or reformatting.
fromModuleNoModule name to trace in the context of a specific opened module. Usually omit.
profileTopNoNumber of hotspots (slowest tables) in the 'profile' overview (backend default 20).
testRangesNoFor test tables: comma-separated test-case ranges (e.g., '1-3,5'). Omit for regular rule execution.
breakpointsNoInitial breakpoint set — REPLACES the current set before starting. Key forms: '<name>' (entry of any same-named table), '<uri>' (entry of that table), '<uri>#R{r}C{c}' (spreadsheet cell), '<uri>#rule' (any decision-table rule fires), '<uri>#<ruleName>' (specific rule fires). Append '@N' to any key to break only on the table's N-th execution (0-based) — e.g. '<uri>#R48C0@3' hits the 4th run; N matches frames[].instance and a watch series' instance, so a watch outlier at instance 3 is reached with '@3'. Without '@N' a cell breakpoint hits EVERY pass.
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.
stopAtEntryNoSuspend at the entry of the first frame (default true). Set false to run straight to the first breakpoint — or, with no breakpoints, to completion.
breakOnErrorsNoSuspend on an uncaught rule error so its frame can be inspected (backend default true). Set false to let the error terminate the run.
detailedTitlesNoBuild value-rich business-view titles in the retained tree (backend default false). This can substantially increase response size.
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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed13 schema fields changedv1.2.0
    • addedInput schema / properties / breakOnErrors
      Added value: +{
      +  "description": "Suspend on an uncaught rule error so its frame can be inspected (backend default true). Set false to let the error terminate the run.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / breakpoints
      Added value: +{
      +  "description": "Initial breakpoint set — REPLACES the current set before starting. Key forms: '<name>' (entry of any same-named table), '<uri>' (entry of that table), '<uri>#R{r}C{c}' (spreadsheet cell), '<uri>#rule' (any decision-table rule fires), '<uri>#<ruleName>' (specific rule fires). Append '@N' to any key to break only on the table's N-th execution (0-based) — e.g. '<uri>#R48C0@3' hits the 4th run; N matches frames[].instance and a watch series' instance, so a watch outlier at instance 3 is reached with '@3'. Without '@N' a cell breakpoint hits EVERY pass.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / detailedTitles
      Added value: +{
      +  "description": "Build value-rich business-view titles in the retained tree (backend default false). This can substantially increase response size.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / fromModule / description
      Previous value: -"Module name for opened module execution. Usually omit."New value: +"Module name to trace in the context of a specific opened module. Usually omit."
    • addedInput schema / properties / includeTree
      Added value: +{
      +  "description": "Also 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.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / inputJson / description
      Previous value: -"For regular rules: JSON input. Use object with params (required) and runtimeContext (optional). E.g. { params: { age: 25 }, runtimeContext: { lob: 'Auto' } }."New value: +"For regular rules: JSON input. Use object with params (required) and runtimeContext (optional). E.g. { params: { age: 25 }, runtimeContext: { lob: 'Auto' } }. Omit BOTH inputJson and testRanges to replay the previous run's remembered input (e.g. restarting with profiling or new breakpoints)."
    • addedInput schema / properties / profileTop
      Added value: +{
      +  "description": "Number of hotspots (slowest tables) in the 'profile' overview (backend default 20).",
      +  "maximum": 500,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / profiling
      Added value: +{
      +  "description": "Retain the executed call tree — structure and timings, NO values (default false). With stopAtEntry: false and no breakpoints the run completes in this single call and returns a constant-size 'profile' overview (top-N slowest tables); the tree's root node comes with includeTree: true and is browsed level by level with openl_expand_trace_tree.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / response_format / default
      Previous value: -"markdown"New value: +"json"
    • changedInput schema / properties / response_format / description
      Previous value: -"Response format: 'json' for structured data, 'markdown' for human-readable (default), 'markdown_concise' for brief summary (1-2 paragraphs), 'markdown_detailed' for full details with context"New value: +"Response 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 context"
    • addedInput schema / properties / stopAtEntry
      Added value: +{
      +  "description": "Suspend at the entry of the first frame (default true). Set false to run straight to the first breakpoint — or, with no breakpoints, to completion.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / tableId / description
      Previous value: -"Table ID to trace (e.g., 'calculatePremium_1234'). Get from openl_list_tables()."New value: +"Table ID to debug (e.g., 'calculatePremium_1234'). Get from openl_list_tables()."
    • changedInput schema / properties / testRanges / description
      Previous value: -"For test tables: comma-separated ranges (e.g., '1-3,5'). Omit for regular rule/table execution."New value: +"For test tables: comma-separated test-case ranges (e.g., '1-3,5'). Omit for regular rule execution."
  2. First observedv0.0.0

TDQS

A4.8/5.0
Behavior5/5

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

With only openWorldHint in annotations, the description carries the full behavioral burden and does so thoroughly. It discloses session lifecycle ('One active session per user — starting a new one terminates the previous'), idle reaping, replay hazards and response-limit overflow, output shape for profiling, lazy tree behavior, and the meaning of profiling vs stack modes. No contradiction with annotations.

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?

The description is long, but it is dense and organized: core behavior, input-mode selection, profiling workflow, tree browsing, and session lifecycle. The front-loaded first sentence gives immediate orientation. A small amount of redundancy with the already-detailed schema descriptions prevents a perfect score.

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?

For a 13-parameter, no-output-schema tool, the description is unusually complete. It explains what the response contains in each mode (stack frames, constant-size profile overview, lazy tree root), how to navigate the session using sibling tools, how to handle replay, and what side effects to expect. Nothing critical for selecting or invoking the tool is missing.

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%, so the baseline is 3, and the description adds meaningful cross-parameter guidance beyond the schema: combining inputJson/testRanges with profiling: true and stopAtEntry: false, the explicit warning against relying on replay, and the workflow of finding a hot table and replaying into it with a breakpoint. It does not rename or redefine individual parameters, so it stops short of a 5.

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 description opens with a precise verb-and-resource statement: 'Start an interactive debug session for a table and run to the first stop.' It also names the related trace tools it coordinates with, so an agent can clearly distinguish this entry point from openl_step_trace, openl_resume_trace, openl_inspect_trace_frame, and openl_expand_trace_tree.

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: test tables vs regular rules, replay behavior when both inputs are omitted, when to set profiling: true, and why profiling should be requested explicitly rather than via replay. It also routes the agent from this call to follow-up tools like openl_step_trace, openl_resume_trace, openl_inspect_trace_frame, and openl_expand_trace_tree.

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