Skip to main content
Glama

Update Fact Definition

lexq_facts_update
Destructive

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. Rules in deleted groups do not count. Only the fields you send are changed. System facts (isBlocked, blockReason) accept changes to name, description, PII, and the value domain; isRequired is ignored, and their type cannot change (FD-003).

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": {
      "factId": "<factId>"
    },
    "name": "lexq_facts_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoDisplay name
typeNoValue type. Omit to leave it unchanged. Changing it fails with FD-007 while any rule outside a deleted group references the fact.
isPiiNoPII flag — enables/disables masking (changeable even on system facts)
factIdYesFact definition ID
isRequiredNoisRequired is stored on the definition only; the engine does not read it.
descriptionNoDescription. Send "" to remove it.
valueDomainNoWhich values this fact accepts. Three states: omit the field to leave the value domain alone, send {} to remove it, or send a populated object to replace it. Narrowing it never blocks the update and does not rewrite rules. When rules compare this fact with a value the new value domain excludes, the result ends with a warning that lists them by version: drafts and the versions currently deployed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / isRequired / description
      Previous value: -"Required flag"New value: +"isRequired is stored on the definition only; the engine does not read it."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the mutation-oriented annotations, it discloses patch semantics, key immutability, the reference-dependent FD-007 failure and reported count, the deleted-group exception, and system-fact FD-003 behavior. These details materially affect whether and how a call succeeds.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Six compact sentences move from the core operation to general update semantics and then special cases. The text is dense but contains no filler, and the most important constraints are front-loaded.

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?

Together with the fully documented schema, the definition covers partial updates, nested value-domain behavior, reference constraints, error codes, and system-fact exceptions. Despite the absence of an output schema, no significant ambiguity remains about how to invoke the tool correctly.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is 100%, the description adds general send-only-fields patch behavior and a consolidated account of which system-fact fields are mutable, ignored, or type-restricted. Some of the type-change guidance repeats the schema, so the added value is strong but not entirely novel.

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 opening “Update a fact definition” supplies a specific verb and resource, clearly distinguishing the operation from sibling fact creation, deletion, and listing tools. The remaining sentences stay focused on the behavior of modifying an existing definition.

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 gives clear situational guidance for partial updates, type changes, and system facts, including when calls fail or fields are ignored. It does not explicitly route agents to an alternative such as lexq_facts_create when a new definition is needed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.