Skip to main content
Glama
Sign In
Crabrix

Crabrix

by sergii-ziborov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Plan file operations

crabrix_plan_changes
Read-onlyIdempotent

Preview up to 32 file operations against the current project without making changes, returning affected files, the resulting project, revision, and plan hash to validate before applying.

Instructions

Format 2 rooms only. Check up to 32 file operations against the current project without changing anything: create, copy, write, move, moveFolder, delete (the text stays in recovery), deleteFolder, restore, purge (clears a recovery row), setEntry, setEdition, setName. Name a file by its id from status or snapshot, or by its shown path. Returns what would change, the project afterwards, the revision it read and a planHash. Apply the same operations with crabrix_apply_operations. Moving a Rust file does not rewrite mod, #[path] or include_str! references.

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": {
      "operations": "<operations>"
    },
    "name": "crabrix_plan_changes"
  }
}

Input Schema

NameRequiredDescriptionDefault
operationsYes

Output Schema

NameRequiredDescriptionDefault
formatYes
planHashYes
revisionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A4.4/5.0
Behavior4/5

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

The annotations already declare readOnly/idempotent/non-destructive, yet the description adds real behavioral context: nothing is mutated, delete keeps text in recovery, purge clears a recovery row, and the response carries what would change, the resulting project, the revision read, and a planHash. It also discloses a concrete limitation (moving a Rust file does not rewrite mod, #[path] or include_str! references). Remaining gap: it does not say whether planHash or the revision must be supplied to apply, or what happens when a plan conflicts.

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?

Front-loaded with the core promise (check, don't mutate), then the kind list, then the sibling routing, then caveats — a sensible order with almost no filler. The opening 'Format 2 rooms only.' is unexplained noise that costs the reader a beat, and the maxItems 32 is restated from the schema.

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 12-variant polymorphic operation tool, the description covers what is checked, how files are addressed, what comes back, and the apply counterpart; the output schema handles return-shape detail. What is missing is the failure/conflict story and the contract between the plan (planHash/revision) and the subsequent apply call, which an agent driving a multi-step workflow would need.

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

Parameters5/5

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

Schema description coverage is 0%, so the description has to carry the load, and it does: all 12 operation kinds are named, and semantics that the schema's const values cannot express are spelled out (delete retains text in recovery, purge clears a recovery row, folder variants use from/to). It also explains that a file can be referenced by a 22-char id from status/snapshot or by its shown path, which is exactly the ambiguity in the nested oneOf.

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 action (check/plan file operations against the current project) and its defining property ('without changing anything'), then enumerates the 12 supported operation kinds. An agent can immediately tell this apart from crabrix_apply_operations, which actually performs the work.

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?

Explicitly positions itself as the dry-run step and routes to crabrix_apply_operations for execution ('Apply the same operations with crabrix_apply_operations'), which is a genuine when/when-not pair. The gap is that the sibling crabrix_apply_changes is never mentioned, leaving the agent to guess how it differs from apply_operations.

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