Skip to main content
Glama
openl-tablets

OpenL MCP Server

Official

Watch Cells Across a Run

openl_watch_trace_cells

Watch scalar cell values across every execution of a table to spot outliers, then jump to the exact pass with a breakpoint and inspect the frame.

Instructions

Answer 'show me this factor across all coverages/iterations' in one call, without dumping frames. Watch SCALAR cells (a single number/string factor, e.g. '$VehiclePriceFactor') — NOT a cell whose value is a big aggregate object (a whole spreadsheet result like '$RateCardPremium'), which makes every captured point huge and can overflow the response; drill into an aggregate with a breakpoint + openl_inspect_trace_frame instead. Runs the table to completion and returns a WatchView: one 'series' per cell with a 'points' array holding the cell's value at each execution of its table (each point carries instance/label/ref/path; value is serialized like any traced value and may come lazy — expand a large one with openl_get_trace_value using its parameterId). Read the series, spot the outlier (e.g. 83.372 among 1.0s), then jump straight to that pass: set a breakpoint '<point.ref>@<point.instance>' (the '@N' suffix targets the N-th execution — same 0-based numbering as the series' 'instance') and replay + openl_inspect_trace_frame to see why. Value JSON Schemas are omitted by default (withSchema: true restores them). Captures cells inside lazy result branches too (nested SpreadsheetResult[]) — the run materializes the whole result. The server caps points per series for a cell deep in a combinatorial branch (benefit × gender × age-band …); each series reports 'total' (the full execution count) and WatchView.truncated flags that some late executions were dropped — inspect a specific one with a '@N' breakpoint. Pass testRanges for a test table or inputJson for a regular rule (omit both to replay the remembered input). This starts a fresh session (terminates any previous one) and clears breakpoints so the run reaches completion.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cellsYesCell names to watch, e.g. ['$VehiclePriceFactor']. The value of each named cell is captured at EVERY execution of its table across the whole run — one series per cell.
tableIdYesTable ID to run (e.g., 'calculatePremium_1234'). Get from openl_list_tables().
inputJsonNoFor regular rules: JSON input { params, runtimeContext? }. Omit BOTH inputJson and testRanges to replay the previous run's remembered input.
projectIdYesProject ID returned by backend. Use the exact 'projectId' value from openl_list_projects() response without modification or reformatting.
fromModuleNoModule name to run in the context of a specific opened module. Usually omit.
testRangesNoFor test tables: comma-separated test-case ranges (e.g., '1-3,5').
withSchemaNoInclude each watched value's JSON Schema (default false — the schema is large and rarely needed; a value that came lazy still carries its parameterId for openl_get_trace_value).
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?

Annotations only provide openWorldHint, so the description carries the full behavioral burden — and it delivers. It discloses side effects (starts a fresh session, terminates previous ones, clears breakpoints), server-side truncation with 'total' and 'truncated' flags, lazy value serialization, and the exact WatchView response shape. It even warns about oversized aggregate values overflowing the response.

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 long, but every sentence earns its place for a tool with 8 parameters and no output schema. It is front-loaded with the core purpose, then moves through exclusions, workflow, edge cases, and parameter selection in a logical sequence. The density is justified by the tool's complexity.

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?

Despite having no output schema, the description fully explains the WatchView result: one series per cell, points arrays with instance/label/ref/path, 'total', and truncation flags. It also covers nested lazy branches, overflow risks, breakpoint workflow, and input selection. An agent has everything needed to call and interpret this tool correctly.

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

Parameters5/5

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

Schema coverage is 100%, but the description still adds meaningful semantics beyond the schema: inputJson/testRanges interplay and the 'replay the remembered input' behavior, withSchema's impact on large schemas, and the '@N' 0-based instance numbering tied to series entries. This extra context helps an agent choose and combine parameters correctly.

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 clear mission: answer 'show me this factor across all coverages/iterations' in one call without dumping frames. It names the exact resource (SCALAR cells like '$VehiclePriceFactor') and explicitly contrasts this with aggregate-object cells, making the tool's scope unambiguous. It also differentiates from sibling tools like openl_inspect_trace_frame and openl_get_trace_value.

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: watch scalar cells, not aggregate objects, and drill into aggregates with a breakpoint plus openl_inspect_trace_frame instead. It also explains when to use testRanges vs inputJson vs omitting both, and how to use a '<ref>@N' breakpoint for specific passes. This is modelable decision logic, not just a vague hint.

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