Skip to main content
Glama

worktree_uninstall

Destructive

Remove worktree-cache integration for this repo: host session hooks, post-checkout hook, policy metadata. Caches are untouched unless purge_local=true AND confirm=true (then this repo's cache namespace is quarantined, still reversible).

Instructions

Remove worktree-cache integration for this repo: host session hooks, post-checkout hook, policy metadata. Caches are untouched unless purge_local=true AND confirm=true (then this repo's cache namespace is quarantined, still reversible).

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": "worktree_uninstall"
  }
}

Input Schema

NameRequiredDescriptionDefault
jsonNoReturn JSON instead of text
confirmNotrue applies mutations; false or omitted skips cache purge
purge_localNoQuarantine this repo's cache namespace (reversible; requires confirm=true)
workspace_pathNoAbsolute thread workspace directory; must map to this project. Omit only when the server cwd is the thread workspace.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.13.0

TDQS

A3.9/5.0
Behavior4/5

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

With destructiveHint=true already set, the description adds genuinely useful context beyond the annotation: exactly which artifacts are removed, that caches survive by default, and that the purge path merely quarantines the repo's cache namespace and remains reversible. It is consistent with the destructive annotation and materially lowers the agent's risk of surprising data loss.

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 sentences, zero filler, with the default (non-destructive) behavior front-loaded and the conditional destructive branch parenthetically qualified. Every clause carries information an agent needs.

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 destructive mutation tool with no output schema, the description covers what is removed, the default safe behavior, the gating conditions, and reversibility. It stops short of stating whether hook/metadata removal is itself reversible or what state the tool expects to find, but the essentials for a correct call are present.

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

Parameters4/5

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

Schema description coverage is 100%, so the per-parameter baseline is 3. The description goes slightly beyond the individual schema blurbs by spelling out the conjunction (purge_local=true AND confirm=true) and reiterating reversibility/quarantine semantics, which clarifies how the two booleans interact rather than documenting them in isolation.

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 (Remove) plus the exact resource (worktree-cache integration) and enumerates what is removed: host session hooks, post-checkout hook, policy metadata. It is clearly distinguishable from worktree_activate/worktree_apply by its uninstall framing, though it never explicitly contrasts itself with nearby siblings like worktree_gc or worktree_audit.

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?

The description gives a precise operational condition for the destructive path (caches are only purged when purge_local=true AND confirm=true), which tells the agent when the risky branch fires. It does not, however, say when to choose this tool over alternatives such as worktree_gc, nor does it state prerequisites (e.g., integration must already be installed), leaving tool selection implied.

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