LexQ
LexQ is a Decision Operations Platform for engineering teams.
Community: Submitted by a user or imported; check the owner before granting accessOnlineNo sign-inGlobalFreeRead-only
What it can do
- Lexq Whoami: Show current authentication info (tenant ID, user ID, role).
- Lexq Groups List: List all policy groups (tenant-wide, priority ASC).
- Lexq Groups Get: Get a single policy group by ID.
What data it sees
Do you need an account
No: the server works without sign-in
LexQ is a Decision Operations Platform for engineering teams. Define, test, and deploy business rules without touching application code — with built-in Impact Simulation and full audit trails.
How to connect
How to connect LexQ to Claude
The server address to paste into Claude settings:
https://lexq--lexq-io.run.tools
- Open Claude (claude.ai or the desktop app).
- Go to Settings → Connectors.
- Click Add custom connector.
- Paste the server address copied below into Remote MCP server URL and click Add.
- In a chat, click + → Connectors and switch the new connector on.
Custom connectors are available on Free, Pro, Max, Team and Enterprise plans (Free is limited to one). On Team and Enterprise an organization Owner adds the connector first under Organization settings → Connectors.
Authorization
After you click Add, a sign-in window for the service opens. Sign in with your own account and approve access. Claude never sees your password.
How to connect LexQ to ChatGPT
The server address to paste into ChatGPT settings:
https://lexq--lexq-io.run.tools
- Open ChatGPT in a browser (chatgpt.com). A Plus, Pro, Business, Enterprise or Edu plan is required.
- Turn on developer mode once: Settings → Apps → Advanced settings → Developer mode.
- Open Settings → Connectors and click Create.
- Fill in the form: Name (anything), Description (one line about what the service does), MCP server URL (copy it below).
- Under Authentication choose OAuth if the service requires sign-in, otherwise None. Click Create.
- In a new chat open + → Apps/Connectors and enable the connector.
OpenAI has renamed this section before (Connectors → Apps/Plugins). If the label differs, search settings for "developer mode". On Business/Enterprise workspaces an admin must allow custom connectors first.
Authorization
On first use ChatGPT opens the service's sign-in window. Sign in and approve access.
How to connect LexQ to Cursor
The server address to paste into Cursor settings:
https://lexq--lexq-io.run.tools
Fastest: click Open in Cursor below and confirm the prompt.
Manually:
- In Cursor open Settings → Cursor Settings → MCP and click Add new global MCP server.
- Paste the JSON copied below into
~/.cursor/mcp.json(per project:.cursor/mcp.jsonin the repo root). - Save the file. The server appears in the MCP list; authorize it there if asked.
Authorization
If the service needs sign-in, an authorize button appears next to the server in the MCP list.
Server tool list (60)
Raw names from tools/list. Only developers need these.
| lexq_whoami | Show current authentication info (tenant ID, user ID, role). |
| lexq_groups_list | List all policy groups (tenant-wide, priority ASC). |
| lexq_groups_get | Get a single policy group by ID. |
| lexq_groups_create | Create a new policy group. Requires name. Priority is auto-assigned (appended last, tenant-wide); use lexq_groups_reorder to change order. Optionally set conflict resolution, activation group, and description. Policy groups that share an activationGroup form a cluster and must share the same activationMode / activationStrategy / executionLimit; executionLimit is how many of those groups run, not how many rules. |
| lexq_groups_update | Update a policy group. Only provided fields are updated; omitted fields remain unchanged. |
| lexq_groups_delete | Archive a policy group. Only non-live groups can be deleted. This is irreversible. |
| lexq_groups_reorder | Reorder policy groups by priority. Priority is tenant-wide and flat (1...N continuous); array index 0 = priority 1 (highest precedence). activationGroup is not affected — this only changes priority. |
| lexq_ab_test_start | Start an A/B test on a policy group. Requires a challenger version ID and traffic rate. The split is computed from context.trafficKey on each execution request; requests that omit it never reach the challenger and the test stays at 0%. |
| lexq_ab_test_stop | Stop a running A/B test. All traffic is restored to the control (current) version. |
| lexq_ab_test_adjust | Adjust traffic rate of a running A/B test. |
| lexq_versions_list | List all versions of a policy group. |
| lexq_versions_get | Get a single version by ID, including its rules and fact requirements. |
| lexq_versions_create | Create a new DRAFT version in a policy group. Optionally provide a commit message and effective date range. |
| lexq_versions_update | Update a DRAFT version. Only DRAFT versions can be modified. Only provided fields are changed. |
| lexq_versions_delete | Delete a DRAFT version. Only DRAFT versions can be deleted. |
| lexq_versions_clone | Clone an existing version to create a new DRAFT. Useful when the source version is already published. |
| lexq_rules_list | List all rules in a version (priority ASC). Returns summary with conditionSummary and actionSummary. |
| lexq_rules_get | Get full rule detail including condition tree and action definitions. |
| lexq_rules_create | Create a rule in a DRAFT version. Requires name, condition tree, and actions array. priority is auto-assigned (appended last); use lexq_rules_reorder to change order. Before creating rules with new fact keys, call lexq_facts_list to check existing facts. If a required key is missing, ask the user to confirm the type, isRequired, and description before calling lexq_facts_create — registering facts enables type validation, Console UI autocomplete, and the dry-run requirements analyzer. After saving, lexq_facts_unregistered lists any keys this version references but has not defined (non-blocking, version-wide) — use it to decide what to register. Condition: { type: "SINGLE", field, operator, value, valueType } or { type: "GROUP", operator: "AND"|"OR", children: [...] } Value types: STRING, NUMBER, BOOLEAN, LIST_STRING, LIST_NUMBER Operators are constrained by the LEFT fact's type (from lexq_facts_list). Using one outside its type is rejected by the server — check the fact type before choosing an operator. - STRING fact: EQUALS, NOT_EQUALS, CONTAINS, IN, NOT_IN - NUMBER fact: EQUALS, NOT_EQUALS, GREATER_THAN, GREATER_THAN_OR_EQUAL, LESS_THAN, LESS_THAN_OR_EQUAL, IN, NOT_IN - BOOLEAN fact: EQUALS, NOT_EQUALS - LIST_* fact: HAS_ANY, HAS_ALL, HAS_NONE (only these) HAS_* query list-typed facts. Value is always an array whose element type matches the fact: - HAS_ANY: fact has at least one of the given values - HAS_ALL: fact has all of the given values - HAS_NONE: fact has none of the given values Example: { "type": "SINGLE", "field": "userTags", "operator": "HAS_ANY", "value": ["VIP","GOLD"], "valueType": "LIST_STRING" } Do NOT use CONTAINS on a list fact — CONTAINS is substring match on STRING facts only. IN is the mirror of HAS_*: IN takes a scalar fact with a list value; HAS_* takes lists on both sides. Actions: [{ type, parameters }] Action parameter schemas: - MUTATE_FACT: { targetVar: string, operator: "ASSIGN"|"ADD"|"SUB"|"MUL"|"DIV", me |
| lexq_rules_update | Update an existing rule in a DRAFT version. Only provided fields are changed. |
| lexq_rules_delete | Delete a rule from a DRAFT version. |
| lexq_rules_reorder | Reorder rules by specifying rule IDs in desired order. Priorities are assigned 1...N (1-based, continuous); array index 0 = priority 1 (highest precedence). |
| lexq_rules_toggle | Enable or disable a rule without deleting it. |
| lexq_facts_list | List all fact definitions (input variable schema). Shows key, type, required, and PII status. Always check this before creating rules. |
| lexq_facts_create | Register a new input variable. Key starts with a letter, then letters, numbers, and underscores (e.g. paymentAmount). Casing is not enforced. Types: STRING, NUMBER, BOOLEAN, LIST_STRING, LIST_NUMBER. |
| lexq_facts_update | Update a fact definition. The key is immutable. The type can change only while no rule references the fact; if any does, the call fails with FD-007 and reports the count. Only the fields you send are changed. System facts accept name, description, and PII only. |
| lexq_facts_delete | Delete a fact definition. System facts cannot be deleted. Neither can a fact that any rule references: that call fails with FD-006 and reports the count. Remove the references first. |
| lexq_facts_action_metadata | Retrieve runtime fact requirements per Action type. For each Action, shows which input facts must be present in the execution payload — e.g. MUTATE_FACT always requires its targetVar fact, plus refVar when one is specified. The factRequired flag describes the FACT, not the parameter: refVar is an optional parameter, but if you specify it the named fact must exist. A required fact absent at runtime throws — the engine never defaults to 0. Facts are supplied as input or written by a prior action in the same rule; only SET_FACT creates a fact from nothing. Static data, safe to cache in-session. |
| lexq_facts_unregistered | List facts referenced by a version's rules but not yet defined (read-only — does not block publish/deploy, INV-4). Version-wide: covers every rule in the version. Each entry carries the inferred type, suggested name, and where it is referenced (condition/action). Register them with lexq_facts_create to enable type validation and the dry-run requirements analyzer. |
| lexq_facts_export | Export the fact catalog. The two formats carry different things: CSV is the catalog as it stands, system facts included, for reading in a spreadsheet; JSON matches the shape that batch create accepts, so it can be fed straight back in, which is why it leaves out the fields that endpoint does not take. Returns the file contents as text. |
| lexq_deploy_publish | Publish a DRAFT version (DRAFT → ACTIVE). Locks the version from further edits. Must have at least one rule. Undefined facts referenced by rules do not block publishing (INV-4); call lexq_facts_unregistered first to review them. |
| lexq_deploy_live | Deploy an ACTIVE (published) version to live traffic. Takes effect immediately. Versions whose effective start date has not arrived are rejected (P-037) — use lexq_deploy_schedule for those. Undefined facts do not block deployment (INV-4); use lexq_facts_unregistered to review what the version references but has not defined. |
| lexq_deploy_rollback | Rollback to the previous deployed version. Only available if there is a previous version. |
| lexq_deploy_undeploy | Remove the live version from traffic. The version stays ACTIVE but no longer serves requests. |
| lexq_deploy_schedule | Schedule an ACTIVE version with a future effective start date to auto-deploy at that time (Scheduled Deployment). One pending schedule per group; manual deploy/rollback/undeploy, starting an A/B test, or archiving the group cancels it. The snapshot hash is sealed at scheduling and re-verified at execution (fail-closed). |
| lexq_deploy_unschedule | Cancel the pending scheduled deployment for a group. The version itself is not affected. Fails with P-039 if no pending schedule exists. |
| lexq_deploy_schedules | List scheduled deployments across all groups (all statuses: PENDING, EXECUTED, CANCELED, FAILED), newest first. |
| lexq_deploy_history | List deployment history across all groups. |
| lexq_deploy_detail | Get detailed info about a specific deployment including snapshot hash and integrity check. |
| lexq_deploy_overview | Show current deployment status of all groups — which version is live, last deployment type, and deployer. |
| lexq_deploy_deployable | List ACTIVE (published) versions that can be deployed for a group. Use this to find which versions are available before calling deploy live. |
| lexq_deploy_diff | Compare rule snapshots between two versions. Shows added, removed, and modified rules. Useful for reviewing changes before deploying a new version. |
| lexq_dry_run | Execute a single dry run against a version. Tests how rules evaluate given input facts without side effects. Returns: inputFacts — normalized input facts mutatedFacts — input facts changed by rule actions (e.g. MUTATE_FACT mutates paymentAmount) generatedVariables — system-generated values; every fact in mutatedFacts gets a paired {factName}__delta key (signed difference) executionTraces — per-rule match status decisionTraces — per-rule decision (SELECTED / NO_MATCH / BLOCKED / etc.) Example input: { "facts": { "paymentAmount": 100000, "customerTier": "VIP" } } Always dry-run before publishing to validate rule behavior. |
| lexq_dry_run_compare | Compare dry run results between two versions using the same input facts. Useful for validating changes. Returns: resultA / resultB — full DryRunResponse for each version diff.mutatedDiff — changes in mutatedFacts between A and B (key → {before, after}) diff.generatedDiff — changes in generatedVariables between A and B |
| lexq_requirements | Analyze which input facts a version requires. Returns required keys, types, and an example request body. |
| lexq_simulation_start | Start an Impact Simulation against historical, uploaded, or inline data. dataset.type and dataset.source are BOTH required, and must be paired: HISTORICAL → source EXECUTION_LOGS, with dataset.from / dataset.to (yyyy-MM-dd) UPLOADED → source S3_BUCKET, 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, default 10000) options.baselinePolicyVersionId: uuid (optional, for baseline comparison) options.includeRuleStats: boolean options.metricConfig: optional — omit for plain execution count. To aggregate a fact, pass { "targetVariable": "<fact>", "aggregationType": "COUNT" | "SUM" | "AVG" } Example (uploaded dataset): { "policyVersionId": "<uuid>", "dataset": { "type": "UPLOADED", "source": "S3_BUCKET", "path": "<path from lexq_dataset_upload>" }, "options": { "baselinePolicyVersionId": "<uuid>", "includeRuleStats": true, "maxRecords": 10000 } } Example (historical): { "policyVersionId": "<uuid>", "dataset": { "type": "HISTORICAL", "source": "EXECUTION_LOGS", "from": "2026-01-01", "to": "2026-01-31" }, "options": { "baselinePolicyVersionId": "<uuid>", "includeRuleStats": true } } |
| lexq_simulation_status | Get simulation status and results. Poll until status is COMPLETED or FAILED. |
| lexq_simulation_list | List simulation history with optional filters. |
| lexq_simulation_cancel | Cancel a running or pending simulation. |
| lexq_simulation_export | Export simulation results as JSON or CSV. Returns the raw data. |
| lexq_dataset_upload | Upload inline CSV or JSON content as a simulation dataset. The content is uploaded to S3 and a path is returned in the "path" field. To use the returned path in lexq_simulation_start, set: dataset: { "type": "UPLOADED", "source": "S3_BUCKET", "path": "<returned path>" } CSV example: userId,paymentAmount user_001,150000 user_002,50000 JSON example: [{"userId":"user_001","paymentAmount":150000}, {"userId":"user_002","paymentAmount":50000}] |
| lexq_dataset_template | Generate a sample CSV or JSON template based on the required facts of a version. Use this to understand the expected data format before uploading a dataset. |
| lexq_profile_overview | Per-rule latency profile of a policy group over a time window: group TOTAL distribution split by cache state (HIT = compiled ruleset cache hit, MISS = deep-load + compile), a per-rule CONDITION/ACTION percentile table, and slow-rule flags. flagged = p50 ≥ 10× median of per-rule p50s within the group; absolute thresholds are intentionally not supported. Every percentile is accompanied by its sample count n; a percentile is withheld (null) unless n×(1−q) ≥ 3 (p50 needs n ≥ 6, p95 n ≥ 60, p99 n ≥ 300 — display gate, separate from the n ≥ 100 judgment gate). Baselines report INSUFFICIENT_COHORT when fewer than 3 rules qualify. Rule detail comes from a deterministic 1% sample of calls; TOTAL is recorded for every call. Defaults: last 24h, live version, cacheState HIT. |
| lexq_profile_rule | Single-rule latency detail: merged phase × cacheState distributions plus a per-window time series (60s windows). Missing windows are genuine gaps — never interpolated. Series points carry each window's own values; percentiles in merged distributions are withheld (null) unless n×(1−q) ≥ 3 (p50 n ≥ 6, p95 n ≥ 60, p99 n ≥ 300). flagged = p50 ≥ 10× median of per-rule p50s within the group; absolute thresholds are intentionally not supported. |
| lexq_replay_decision | Re-evaluate a past execution (traceId) against a candidate version and return the decision diff (decisionChanged, effect changes, fired rules) plus a determinism verdict. Synchronous and free of charge (TPS throttle only). A replay sends no webhook, notification, or event: rule actions produce no outward effects. |
| lexq_replay_start | Submit an async job that replays a date window of past executions against a candidate version and measures the blast radius (how many decisions change). Billed per replayed record (REPLAY metric); VIEWER role cannot submit. Poll with lexq_replay_status. |
| lexq_replay_status | Poll a window replay job. RUNNING shows progress 0–100; COMPLETED fills summary and changedSamples; FAILED carries errorMessage. capped=true means the window exceeded the sample cap and only part was replayed. |
| lexq_replay_list | List window replay job history (reverse-chronological). Lightweight items — use lexq_replay_status for summary and changed samples. |
| lexq_replay_cancel | Cooperatively cancel a PENDING or RUNNING window replay job. Other states are rejected. VIEWER role cannot cancel. |
| lexq_replay_export | Export a COMPLETED window replay job. A running job is rejected — a partial result reads as the whole thing on the receiving end. The two formats carry different things: CSV holds the effect blast radius, whose columns are fixed; JSON holds the changed samples and action parameters, which nest and whose keys differ per tenant. JSON is not a superset of CSV. Returns the file contents as text. |