Skip to main content
Glama
Sign In
robo-cortex

robo-cortex

Official
by robotel-limited
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_affected

Reports which stored memories a git diff puts at risk by touching their anchored code files; use it before or after code changes to find memories needing review.

Instructions

Report which stored memories a git diff puts at risk because it touches a code file they are anchored to -- the proactive half of invalidation. Returns {"data": [{"id", "statement", "reason"}], "matched": N}; each reason names the offending path and diff source, e.g. path_changed:src/scanner.py@working_tree. Terminal-status memories (superseded/invalidated/abandoned/archived) are excluded -- already history. Use it when you are about to change, or have just changed, code and want to know which memories that change endangers: it is diff-driven, mapping a code delta to the memories that depend on it -- unlike retrieve_context (natural-language task -> context pack) and search_memory (keyword query). Runs the staleness refresh first, so drift already committed is flagged before the diff-scoped report.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_affected"
  }
}

Input Schema

NameRequiredDescriptionDefault
stagedNoInspect only staged changes (`git diff --cached`). Ignored if `diff_range` is set.
workingNoInspect only unstaged working-tree changes (`git diff`). Ignored if `diff_range` is set. When `diff_range`, `staged`, and `working` are all omitted, staged and unstaged changes are inspected together (`git diff HEAD`).
diff_rangeNoOptional committed range in git syntax, e.g. 'HEAD~3..HEAD'. Memories are compared against the range's end content. Takes precedence over `staged`/`working` if more than one is given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.7.0
  2. Removedv0.4.2
  3. First observedv0.4.1

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations present, the description carries the full burden and does most of it: it discloses the exact response envelope, the per-item `reason` format with a worked example, the terminal-status exclusion rule, and the non-obvious side effect that a staleness refresh runs before the report (so pre-existing drift can appear). It stops short of stating what happens outside a git repository, whether the refresh mutates stored state, or error behavior — real gaps for a tool with zero annotation coverage.

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?

Purpose is front-loaded in the first clause, followed by return shape, exclusions, usage routing, and side effects in a logical order; nearly every clause carries information. The wording is dense and semicolon-chained rather than scannable, which costs a point against the cleanest definitions.

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?

There is no output schema, and the description compensates by spelling out the return keys and the `reason` string convention, so the agent knows what to expect back. Given the tool's moderate complexity and full schema coverage, the main remaining gap is failure/edge behavior — non-git directories or how the internal refresh interacts with memory state.

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 `staged`, `working`, and `diff_range` (including precedence and the default combined `git diff HEAD` behavior) are already fully documented in the schema. The description adds only the framing 'diff-driven, mapping a code delta to the memories that depend on it', which does not extend parameter meaning beyond what the schema provides.

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 and resource ('report which stored memories a git diff puts at risk') and immediately frames the mechanism ('memories... anchored to' a code file) plus its role ('the proactive half of invalidation'). It explicitly names the two siblings it is not — retrieve_context for natural-language tasks and search_memory for keyword queries — so an agent can route correctly without opening any schema.

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 a concrete trigger ('when you are about to change, or have just changed, code and want to know which memories that change endangers') and pairs it with explicit rejections of the two nearest alternatives, including what each of those does instead. This is the when/when-not/alternatives pattern done fully.

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