Skip to main content
Glama
Sign In

LexQ

by io.lexq
OverviewDiscussionsAdmin

Start Simulation

lexq_simulation_start
Destructive

Start an Impact Simulation against historical, uploaded, or inline data.

Every record a simulation processes counts toward the plan's simulation usage, including records processed before a cancel. When the plan's limit is reached, a new simulation cannot start.

dataset.type and dataset.source are BOTH required, and must be paired: HISTORICAL → source EXECUTION_LOGS, with dataset.from / dataset.to (yyyy-MM-dd, whole days in the organization time zone, both inclusive) UPLOADED → source UPLOADED_FILE, with dataset.path (the path returned by lexq_dataset_upload) MANUAL → source REQUEST_BODY, with dataset.manualData (array of fact records)

options.maxRecords: number (max 100000). When omitted, HISTORICAL and UPLOADED run at most 1000 records and MANUAL runs every record sent. options.baselinePolicyVersionId: uuid (optional, for baseline comparison) options.includeRuleStats: boolean options.metricConfig: optional — omit for plain execution count. To aggregate a fact, pass { "targetVariable": "", "aggregationType": "COUNT" | "SUM" | "AVG" }

Example (uploaded dataset): { "policyVersionId": "", "dataset": { "type": "UPLOADED", "source": "UPLOADED_FILE", "path": "" }, "options": { "baselinePolicyVersionId": "", "includeRuleStats": true, "maxRecords": 10000 } }

Example (historical): { "policyVersionId": "", "dataset": { "type": "HISTORICAL", "source": "EXECUTION_LOGS", "from": "2026-01-01", "to": "2026-01-31" }, "options": { "baselinePolicyVersionId": "", "includeRuleStats": true } }

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "body": "<body>"
    },
    "name": "lexq_simulation_start"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYesJSON string of SimulationRequest

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, but the description adds genuinely non-derivable behavior: every processed record is billed to the plan's simulation usage even if the run is cancelled, and new simulations are blocked once the limit is hit. That is real cost/quota disclosure beyond the annotations, though it omits whether the call is asynchronous or what it returns.

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-loaded with the one-line purpose, then a tight constraint block, an options list, and two field-accurate examples. It is long but nearly every line carries a rule not available elsewhere; the only slack is minor repetition between the pairing table and the examples.

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

Completeness3/5

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

Inputs are documented exhaustively, which is the hard part for a single opaque body parameter. However, with no output schema, the description should say what a successful start yields (job/simulation id) and that progress must be tracked via lexq_simulation_status; that lifecycle information is absent, leaving an agent unsure what to do after the call.

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?

The schema exposes only an opaque 'body' JSON string, so the description carries the entire request contract: the required type/source pairing table, date format and inclusivity rules, path provenance, manualData shape, maxRecords cap and per-type defaults, and the metricConfig aggregation enum. Without this text the tool would be effectively uncallable.

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

Purpose4/5

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

States a specific verb+resource ('Start an Impact Simulation') and scopes it to historical, uploaded, or inline data, which is much more informative than the title alone. It does not explicitly differentiate against the nearest siblings (lexq_dry_run, lexq_replay_start, lexq_simulation_status), so an agent must infer the boundary from the dataset-type rules rather than from a named alternative.

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

Usage Guidelines4/5

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

Gives clear preconditions: UPLOADED requires a path produced by lexq_dataset_upload, HISTORICAL requires from/to date bounds, and the plan quota must not be exhausted. It never states when to prefer lexq_dry_run or lexq_replay_start instead, and never mentions polling with lexq_simulation_status, so the when-not guidance is missing.

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

All LexQ toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources