git-remote-mcp

git_stash

Manage Git stashes in local repositories: list, push, pop, apply, drop, show, or clear saved changes to switch context without committing work.

Instructions

Manage git stashes.

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

Input Schema

Name	Required	Description	Default
`cwd`	No	Optional local working directory or repository path.
`ref`	No	Optional stash ref.
`action`	No	Stash action.	list
`message`	No	Message for stash push.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 11, 2026

TDQS

C2.3/5.0

Behavior1/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says only 'Manage git stashes' and does not mention that actions such as drop, clear, or pop mutate state, that push creates a stash, or any side effects, permissions, or reversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is concise and front-loaded but too sparse for a tool with seven enumerated actions and optional parameters. It reads as under-specification rather than efficient brevity.

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 multi-action stash tool with no annotations and no output schema, the description should explain action semantics and at least note the default 'list' behavior. Instead it leaves the agent to discover all behavior from the schema enum alone.

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 the schema itself documents cwd, ref, action, and message. The description adds no parameter meaning beyond the schema, making the baseline of 3 appropriate.

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

Purpose3/5

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

The description names the resource (git stashes) and a generic verb (manage), but it does not state the specific operations (list, push, pop, apply, drop, show, clear) or distinguish this tool from siblings like git or git_status. It is marginally more than a restatement of the tool name, so it lands at the vague-purpose level.

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

Usage Guidelines2/5

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

There is no guidance about when to use stashes versus commits or branches, nor when to choose this tool over siblings. The description offers only an implied domain, with no conditions, exclusions, or alternatives.

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