LexQ

Create Fact Definition

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.

Input Schema

TableJSON Schema

Name	Required	Description
`key`	Yes	Variable key. Any casing; must start with a letter.
`name`	Yes	Display name
`type`	Yes	Value type
`isPii`	No	Mark as PII — masked on every read surface, revealable only in the console (audited)
`isRequired`	No	Whether this fact is required for rule evaluation
`description`	No	Description
`valueDomain`	No	Which values this fact accepts. Omit for no constraint. STRING and LIST_STRING take allowedValues only; NUMBER and LIST_NUMBER take all three; BOOLEAN takes none. Declaring it lets the rule editor offer a dropdown and rejects a rule literal that could never match.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 14, 2026

addedInput schema / properties / valueDomain

Added value: +{
+  "description": "Which values this fact accepts. Omit for no constraint. STRING and LIST_STRING take allowedValues only; NUMBER and LIST_NUMBER take all three; BOOLEAN takes none. Declaring it lets the rule editor offer a dropdown and rejects a rule literal that could never match.",
+  "properties": {
+    "allowedValues": {
+      "description": "Accepted values. For list types the constraint applies to each element, not to the list as a whole.",
+      "items": {
+        "type": [
+          "string",
+          "number"
+        ]
+      },
+      "type": "array"
+    },
+    "max": {
+      "description": "Upper bound, inclusive. Numeric types only.",
+      "type": "number"
+    },
+    "min": {
+      "description": "Lower bound, inclusive. Numeric types only.",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

Changed4 schema fields changedSep 10, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / key / description

Previous value: -"Variable key (snake_case)"New value: +"Variable key. Any casing; must start with a letter."

changedInput schema / properties / key / pattern

Previous value: -"^[a-z][a-z0-9_]*$"New value: +"^[a-zA-Z][a-zA-Z0-9_]*$"

Changed1 schema field changedJul 8, 2026

addedInput schema / properties / isPii

Added value: +{
+  "default": false,
+  "description": "Mark as PII — masked on every read surface, revealable only in the console (audited)",
+  "type": "boolean"
+}

First observedApr 2, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation-safe profile is covered. The description adds the key validation rule and that casing is not enforced, which is useful, but omits behavior on duplicate keys, error modes, and any auth/permission requirements.

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?

Three tight sentences, front-loaded with the core action. Some content (key pattern, type list) duplicates the schema, but nothing is wasted and the size matches the tool.

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?

A 7-parameter tool with a nested valueDomain object and no output schema; the schema carries full field detail, so the description needn't explain returns. It is adequate but silent on PII/required semantics and duplicate-key behavior that a caller creating a fact would care about.

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 description coverage is 100%, so the schema already documents key, name, type, isPii, isRequired, description, and the nested valueDomain. The description largely repeats the key pattern and type enum, adding only 'casing is not enforced' as marginal value. Baseline 3 is correct.

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 and resource ('Register a new input variable'), and the word 'new' separates it from lexq_facts_update/delete/list. It does not explicitly name a sibling alternative, but the create semantics are unambiguous.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no contrast with lexq_facts_update or lexq_facts_list. The agent must infer that this is the creation path and when a fact should be registered at all.

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

All LexQ tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?