Skip to main content
Glama
Sign In

LexQ

by io.lexq
OverviewDiscussionsAdmin

Create Rule

lexq_rules_create

Create a rule in a DRAFT version. It goes last in priority order; lexq_rules_reorder changes the order.

An action's targetVar must be a registered fact (ACT-032 otherwise). Keys a rule only reads (condition fields, refVar) may stay unregistered. Actions must use facts in the data types they are registered with. MUTATE_FACT's targetVar must be a NUMBER fact, and so must its refVar if that key is registered (ACT-035 otherwise). SET_FACT's value must match the data type of its targetVar (ACT-036 otherwise). For example, "10" does not match a NUMBER fact. A null value matches any data type.

Condition: { type: "SINGLE", field, operator, value, valueType } or { type: "GROUP", operator: "AND"|"OR", children: [...] } Value types: STRING, NUMBER, BOOLEAN, LIST_STRING, LIST_NUMBER Limits: 25 SINGLE conditions per rule (GROUP nodes do not count), 10 levels of nesting below the root, 100 rules per version. Value limits: every value in a condition or an action has the same limits as a value in an execution call. A list holds up to 1000 items, text up to 4096 characters, and a number up to 34 digits before and 34 after the decimal point. Saving or publishing a rule with a value over a limit fails with P-064, and the message gives the value's path.

Operators that work on each fact type:

  • STRING: EQUALS, NOT_EQUALS, CONTAINS (substring), IN, NOT_IN

  • NUMBER: EQUALS, NOT_EQUALS, GREATER_THAN, GREATER_THAN_OR_EQUAL, LESS_THAN, LESS_THAN_OR_EQUAL, IN, NOT_IN

  • BOOLEAN: EQUALS, NOT_EQUALS

  • LIST_STRING, LIST_NUMBER: HAS_ANY, HAS_ALL, HAS_NONE IN and NOT_IN test whether the fact's value is in the array. HAS_ANY, HAS_ALL and HAS_NONE match when the fact's list holds at least one, all, or none of the array's values. The array holds values of the fact's type, or for a list fact, of its element type. Example: { "type": "SINGLE", "field": "userTags", "operator": "HAS_ANY", "value": ["VIP","GOLD"], "valueType": "LIST_STRING" }

Actions: [{ type, parameters }]

  • MUTATE_FACT: { targetVar, operator: "ASSIGN"|"ADD"|"SUB"|"MUL"|"DIV", method: "PERCENTAGE"|"AMOUNT", operand: number, refVar?, rounding? } Reads and writes targetVar. The request must send it (P-015 otherwise), and it must hold a number when the action runs. operand may be negative, and a percent may be over 100. AMOUNT PERCENTAGE (base = refVar, or targetVar when omitted) ASSIGN targetVar = operand targetVar = base × operand/100 ADD targetVar += operand targetVar += base × operand/100 SUB targetVar -= operand targetVar -= base × operand/100 MUL targetVar *= operand targetVar *= (operand/100 + 1) DIV targetVar /= operand invalid refVar is allowed only with PERCENTAGE and ASSIGN, ADD or SUB. DIV with AMOUNT needs a nonzero operand. rounding: { scale: integer (0..34), mode?: "UP"|"DOWN"|"CEILING"|"FLOOR"|"HALF_UP"|"HALF_DOWN"|"HALF_EVEN" }. mode defaults to HALF_UP. Without rounding, the result keeps at most 34 significant digits and at most 34 digits after the decimal point, rounded half-even. At execution, a result or {targetVar}__delta with more than 34 digits before the decimal point fails the call with ACT-034. Send smaller values or change the calculation. See https://docs.lexq.io/guides/policy-rules#mutate_fact-%E2%80%94-with-rounding for organizations that use Fail-open.

  • SET_FACT: { targetVar, value }, where value matches the data type of targetVar. The request does not have to send targetVar.

  • BLOCK: { reason? } sets isBlocked to true and blockReason to the reason, or "Policy Violation" without one. It does not stop later actions or rules; the caller enforces the block. Only BLOCK writes these two keys: a SET_FACT or MUTATE_FACT targeting either is rejected (ACT-033).

Every condition is checked against the input facts before any action runs, so a condition never sees a value an action writes in the same request. The winning rules' actions then run in priority order, each on the values the actions before it left.

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": {
      "groupId": "<groupId>",
      "versionId": "<versionId>",
      "rule": "<rule>"
    },
    "name": "lexq_rules_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
ruleYesJSON string of CreateRuleRequest: { name, condition, actions, mutexGroup?, mutexMode?, mutexStrategy?, mutexLimit?, isEnabled? }
groupIdYesPolicy group ID
versionIdYesVersion ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare a non-destructive, non-open-world write, and the description adds substantial behavioral detail beyond that: validation error codes (ACT-032, ACT-035, ACT-036, ACT-033, P-064, ACT-034), per-version rule caps, and the execution semantics that conditions are evaluated before any action runs and that actions apply sequentially in priority order. It stops short of stating what the call returns or any auth/rate-limit behavior, keeping it below the top mark.

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?

It is long, but the length is justified by the embedded rule DSL, and it is front-loaded with the core action and ordering caveat. It is organized into labeled sections (condition grammar, limits, operators, the MUTATE_FACT table, SET_FACT, BLOCK), though a few passages, such as the external docs URL and the cross-reference to execution-call value limits, cost more words than they return.

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?

With no output schema, the description carries the burden of describing the response, and it never says what a successful create returns (for example, the new rule ID). For a mutation tool with a nested DSL payload, the validation and execution semantics are otherwise thorough, but that missing return-value statement leaves a real gap.

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

Parameters3/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 does expand the opaque `rule` JSON string into a detailed condition/action grammar. However, several documented optional fields (mutexGroup, mutexMode, mutexStrategy, mutexLimit, isEnabled) are never explained, and the limits section defers to 'the same limits as a value in an execution call,' requiring knowledge from another tool.

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 gives a specific verb, resource, and constraint: create a rule in a DRAFT version. It immediately states the resulting placement ('goes last in priority order') and names the sibling, lexq_rules_reorder, that changes that placement, letting an agent distinguish it from ordering and update siblings without opening a schema.

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?

It clearly sets the context of use (draft version only) and explicitly routes ordering to lexq_rules_reorder. It does not explicitly contrast create against lexq_rules_update or explain when a rule should be created in a non-draft context, so guidance is strong but not fully exhaustive.

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