Skip to main content
Glama
Sign In
robo-cortex

robo-cortex

Official
by robotel-limited
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

change_status

Moves a stored memory to a final state (superseded, invalidated, abandoned, archived) or back to active, re-verifying linked code paths against HEAD so it isn't immediately flagged stale.

Instructions

Move a memory to a deliberate, final state (superseded, invalidated, abandoned, archived) or manually back to active. new_status='active' re-verifies: every linked path's blob hash is recaptured against current HEAD and last_verified_at is set to now, so the next retrieve_context/search_memory call doesn't immediately re-flag needs_review. scope disambiguates a memory_id that collides between the repo and global stores.

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": {
      "memory_id": "<memory_id>",
      "new_status": "<new_status>",
      "reason": "<reason>"
    },
    "name": "change_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
scopeNo
reasonYes
memory_idYes
new_statusYes
supersedes_link_toNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.7.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does disclose meaningful side effects: recapturing every linked path's blob hash against current HEAD, stamping last_verified_at, and the downstream effect on future needs_review flags. It does not state whether status changes are reversible, what permissions are required, or what happens to evidence links on invalidation, so it is not complete.

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 main action and the valid status vocabulary are front-loaded, and the re-verification explanation earns its length because it is non-obvious behavior. The closing sentence on scope is slightly tacked-on but still necessary.

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?

For a five-parameter mutation tool with no annotations and no output schema, the description should explain the reason/supersedes_link_to parameters and the expected result of the call. It covers the core state machine and the re-verification side effect well, but leaves an agent guessing about two parameters and the return value.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it only covers two of five parameters: the allowed values for new_status and the store-disambiguation role of scope. The required `reason` parameter and `supersedes_link_to` are never explained, and `memory_id` is only mentioned in the context of collisions.

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 ('move a memory to...') plus the resource and enumerates the four final states (superseded, invalidated, abandoned, archived) as well as the reverse transition to active. This is clearly distinguishable from read-oriented siblings like retrieve_context, get_memory, and search_memory.

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?

Explains when the active transition should be used and why (it re-verifies so the next retrieve_context/search_memory call doesn't immediately re-flag needs_review), which is real decision context. It does not say when to prefer record_memory over superseding, or describe failure/guard conditions, so it stops short of explicit when-not guidance.

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