Skip to main content
Glama
Sign In

LexQ

by io.lexq.mcp
OverviewDiscussionsAdmin
This connector has been deprecated

This listing duplicates LexQ (io.lexq/lexq), which follows the official MCP Registry entry. Use that listing instead.

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

NameRequiredDescriptionDefault
keyYesVariable key. Any casing; must start with a letter.
nameYesDisplay name
typeYesValue type
isPiiNoMark as PII — masked on every read surface, revealable only in the console (audited)
isRequiredNoWhether this fact is required for rule evaluation
descriptionNoDescription
valueDomainNoWhich values this fact accepts. Omit for no value domain. 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.

  1. Changed2 schema fields changed
    • changedInput schema / properties / valueDomain / description
      Previous value: -"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."New value: +"Which values this fact accepts. Omit for no value domain. 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."
    • changedInput schema / properties / valueDomain / properties / allowedValues / description
      Previous value: -"Accepted values. For list types the constraint applies to each element, not to the list as a whole."New value: +"Accepted values. For list types the value domain applies to each element, not to the list as a whole."
  2. Changed1 schema field changed
    • 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"
+}
  3. Changed4 schema fields changed
    • 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_]*$"
  4. Changed1 schema field changed
    • 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"
+}
  5. First observed

TDQS

B3.2/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is known. The description adds nothing beyond that: it doesn't say what happens on a duplicate key, whether registration is versioned/idempotent, or what a successful call returns. For a creation tool this is a notable gap.

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 that front-load the action and then the key format. Every sentence is short, though the key-pattern and type enumeration duplicate the schema rather than earning their space.

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?

Given 7 parameters with nested objects but full 100% schema coverage, and no output schema expected to be explained, the description is adequate: it covers the primary identifier format and the type vocabulary. Richer options (isPii, valueDomain) are fully handled by the schema.

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 all 7 parameters, including isPii, isRequired, and valueDomain. The description's key-pattern and type-list sentences merely restate schema content (pattern regex, enum values) rather than adding new meaning, so baseline 3 is appropriate.

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 follows with concrete constraints. It's unambiguous against lexq_facts_update/delete/list by virtue of the creation framing, though it never explicitly names siblings to distinguish itself.

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 mention of the adjacent lexq_facts_update (for editing an existing fact) or lexq_facts_list. The format rules given are input-shape hints, not usage guidance.

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
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources