Soul

Overview Schema Source Related Servers Discussions Admin

n2_kv_gc

Delete old KV-cache snapshots for a project to reclaim storage and reduce clutter. Set an age limit in days, or use the configured defaults.

Instructions

Remove old KV-Cache snapshots. Uses config defaults if no args.

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": {
      "project": "<project>"
    },
    "name": "n2_kv_gc"
  }
}

Input Schema

Name	Required	Description	Default
`project`	Yes	Project name
`maxAgeDays`	No	Delete older than N days

Schema Changelog

Changes observed during successful MCP inspections.

First observedv9.2.0Nov 4, 2026

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are supplied, so the description carries the full burden for a destructive operation. It never says deletions are irreversible, which snapshots actually get matched (per project? all?), or what happens when nothing is older than the threshold; 'old' is the only behavioral detail given.

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?

Two short sentences with the action front-loaded and no filler. Nothing is redundant or buried.

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

Completeness2/5

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

For a deletion tool with zero annotation coverage and no output schema, the description is too thin: it omits irreversibility, deletion scope, and the effect of the required project parameter. An agent has no basis for judging risk before invoking it.

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 coverage is 100%, so both parameters are already documented. The description adds one piece of meaning beyond the schema: that omitted arguments fall back to configuration defaults, which the schema does not state. It does not clarify whether maxAgeDays overrides or supplements the config value, nor what 'project' scopes.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Remove old KV-Cache snapshots'), which is enough to tell it apart from n2_kv_save/load/search and from n2_kv_restore in the sibling list. It stops short of explicitly naming the neighboring backup/restore tools it complements.

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

Usage Guidelines3/5

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

'Uses config defaults if no args' implies you may call it with only a project or none of the optional tuning, which is useful calling guidance. There is no statement of when cleanup is appropriate versus restoring or backing up, and no exclusions or prerequisites.

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