Skip to main content
Glama

AvianSuite

by com.aviansuite
OverviewDiscussionsAdmin

Correct a fact

correct_fact

Use when a recorded fact was wrong when it was recorded, such as a typo or the wrong customer, and you know the right value. Give the hash of the fact to replace and a reason. If the old value was right then and has since changed, use record_fact instead, so history shows both. The old fact stays in history, marked as superseded, so the correction can itself be undone. When the result includes a receipt link, include it when you tell a person about the change, so they can check it and undo it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYesThe corrected value. Any JSON: string, number, boolean, object or array.
reasonYesWhy the earlier fact was wrong.
evidenceNoWhere the fact came from, so a person can check it.
entity_idYesStable ID of the thing the fact is about, such as customer:42 or ticket:T-1009. Not a display name.
predicateNoPredicate of the corrected fact. Defaults to the predicate of the fact being corrected.
workspaceNoOptional. The workspace to act on, as list_workspaces names it. Leave it out to use this connection's first workspace.
supersedesYesHash of the fact being corrected, from get_entity or an earlier write.
observed_atNoWhen the corrected value was observed, RFC 3339.
operation_idYesYour ID for this one write, 8-200 characters. Reuse it when retrying the same write so it is not recorded twice. Never reuse it for a different write.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / workspace
      Added value: +{
+  "description": "Optional. The workspace to act on, as list_workspaces names it. Leave it out to use this connection's first workspace.",
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • changedInput schema / properties / value / description
      Previous value: -"The corrected value. Any JSON."New value: +"The corrected value. Any JSON: string, number, boolean, object or array."
    • addedInput schema / properties / value / type
      Added value: +[
+  "string",
+  "number",
+  "boolean",
+  "object",
+  "array"
+]
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare it is a non-read-only, non-destructive write. The description adds substantial context beyond that: the old fact is retained and marked superseded, the correction is itself reversible, and the receipt link should be surfaced to a human so they can check and undo. That is exactly the kind of undo/audit behavior annotations cannot convey.

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?

Four sentences, each carrying distinct load: trigger, inputs, the record_fact alternative, and the history/receipt behavior. The usage trigger is front-loaded and nothing is redundant.

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?

Despite 9 parameters, a nested evidence object, and no output schema, the description covers the operation's lifecycle (supersede, undo, receipt link) and its relationship to the sibling write tools. An agent has everything needed to invoke it correctly.

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 each of the 9 parameters is already documented. The description restates two of them (hash to replace, reason) and adds the intent behind the reason field, but adds no syntax, format, or default detail beyond the schema. Baseline 3 applies.

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?

States a specific verb (correct) and resource (a recorded fact), and immediately scopes it as fixing a fact that was wrong at recording time (typo, wrong customer). It explicitly contrasts with the sibling record_fact, so an agent can distinguish the two without opening schemas.

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

Usage Guidelines5/5

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

Gives an explicit when ('was wrong when it was recorded, and you know the right value') and an explicit when-not with the named alternative ('If the old value was right then and has since changed, use record_fact instead'). It also states the inputs to supply (hash and reason).

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

All AvianSuite 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