Skip to main content
Glama

neurover_cleanup_approve

Destructive

Records duplicate-cleanup decisions for a job by group—keep one copy or delete all—without deleting files.

Instructions

Очистка дублей, шаг 4: зафиксировать выбор пользователя по группам (оставить одну копию / удалить все). Ничего не удаляет.

Input Schema

NameRequiredDescriptionDefault
modeYes
jobIdYes
confirmYes
groupIdsNo
retentionNo
groupRetentionNo
allowUsedOnCanvasNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.13

TDQS

C2.9/5.0
Behavior2/5

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

The description's key behavioral claim, 'Ничего не удаляет' (deletes nothing), directly contradicts the supplied destructiveHint=true annotation, leaving the agent unsure whether approving is itself destructive or merely authorizes deletion downstream. The step framing and per-group choice semantics are genuinely useful context beyond the annotations, which is why this is not a 1, but the safety-relevant conflict is significant given there is no output schema to clarify the effect.

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?

Two short clauses, front-loaded with the step number and the action, with no filler or redundancy. It is efficiently structured, though the final reassurance clause is the one that introduces ambiguity rather than clarity.

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 7-parameter, nested-object approval step inside a destructive cleanup workflow with no output schema and no helpful annotations, this is thin. It omits what 'mode' changes, what happens after approval (does a later step delete?), and whether groupRetention overrides retention, all of which an agent needs to call it correctly.

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 carry the parameter burden, and it does not. It hints at per-group selection ('по группам', keep_one/delete_all), but those values are already visible in the enums, while the critical 'mode' distinction (metadata vs hash), jobId, the required confirm flag, and allowUsedOnCanvas are entirely unexplained.

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?

The description names the operation precisely: step 4 of duplicate cleanup, which records the user's per-group choice (keep one copy / delete all). That is a specific verb plus resource and it positions the tool in a multi-step pipeline, which separates it from siblings like cleanup_scan or cleanup_start. It stops short of explicitly contrasting with the closely named neurover_cleanup_approve_files, so it is not a 5.

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?

Sequencing is only implied by the phrase 'шаг 4' (step 4), which suggests it follows scan/report and precedes apply/verify, but no explicit when-to-use or when-not-to-use rule is given. Nothing says how this differs from neurover_cleanup_approve_files or neurover_cleanup_step, and there is no mention of prerequisites such as an existing jobId or a completed scan. Usage is inferable but not stated.

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