Skip to main content
Glama
Sign In
Connapse

Connapse

by Destrayon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

memory_correct

Replace an outdated or incorrect fact while preserving its history. Record whether the world changed or the old value was wrong, updating dates and sources without losing prior versions.

Instructions

Replace a fact and keep the old one in history. kind="changed": the world changed, so the old fact ends on validFrom and the new value starts there (validFrom required). kind="wrong": the old fact was never right, so it is marked superseded and the new value takes its dates; a date you pass replaces the old one, except one where another version of the fact starts or ends. Subject and attribute default to the old fact's. A fact with versions you cannot see (another user's private ones) cannot be corrected; remember a new fact instead.

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>",
      "value": "<value>"
    },
    "name": "memory_correct"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNo"changed" (default) or "wrong"
valueYesThe new value
factIdYesID of the fact to replace (from memory_recall)
reasonNoWhy it changed, e.g. the ticket
sourcesNoSources for the new value: document IDs, or "node:<id>"
subjectNoNew subject, if it changed
validToNoDate the new value stopped being true, if it has
attributeNoNew attribute, if it changed
validFromNoDate the new value took effect (required for changed)
containerIdNoOptional and not needed: the fact is found by its id in every space you can see, and the correction stays where the fact is

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the single destructiveHint=false annotation, the description discloses history retention, the differing temporal semantics of the two correction modes, the validFrom requirement for 'changed,' and the restriction on correcting facts with invisible private versions. That is substantive behavioral context.

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?

The description is dense and front-loaded, and every sentence contributes useful semantic or eligibility information. It could be slightly easier to scan if the two kind behaviors were visually separated, but there is no wasted filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex mutation with 10 parameters and no output schema, the description covers the crucial correction semantics, date behavior, defaults, and eligibility restriction. It does not describe what the tool returns, but the main behavioral gaps that would cause misuse are addressed.

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?

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining how kind affects dates, that validFrom is required for 'changed,' that subject and attribute default to the old fact's values, and that a supplied date replaces the old one except around other versions.

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 description states a specific verb and resource: 'Replace a fact and keep the old one in history.' It clearly distinguishes itself from ordinary remembering by noting that invisible versions cannot be corrected and that the fallback is to 'remember a new fact instead.'

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?

It gives explicit when-to-use rules for the two modes: kind='changed' means the world changed, while kind='wrong' means the old fact was never right. It also names the alternative when correction is impossible: 'remember a new fact instead.'

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

Deploy Server

Other Tools