ForgeMCP

by hardened-steel

Overview Schema Source Related Servers Discussions Admin

Python

Local

git_stash

Destructive

List, save, apply, pop, or drop Git stashes without automatically hiding other edits.

Instructions

List, save, apply, pop, or drop stashes without automatically hiding other edits.

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": {
      "action": "<action>"
    },
    "name": "git_stash"
  }
}

Input Schema

Name	Required	Default
`action`	Yes
`message`	No
`reference`	No	stash@{0}
`include_untracked`	No

Output Schema

Name	Required	Description	Default
`error`	No
`changes`	Yes
`stashes`	No
`updates`	No
`conflicts`	Yes
`operation`	Yes
`head_after`	Yes
`head_before`	Yes
`process_ids`	Yes
`synchronization_error`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.1Nov 5, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the clause 'without automatically hiding other edits' adds a genuine behavioral detail about scope of effect. However, for a multi-action tool the description never distinguishes risk per action: 'list' is a pure read while 'drop' is irreversible, and that distinction matters far more than the annotations' single global destructive flag.

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?

A single front-loaded sentence with the resource named first and the action list immediately after; nothing is padded or redundant beyond the necessary enumeration. It is efficient, though it spends its limited words on the enum that the schema already documents.

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

Completeness3/5

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

An output schema exists, so return values need not be explained, but the action-dependent semantics remain missing: that 'message' applies only to save and 'reference' only to apply/pop/drop is nowhere stated. For a four-parameter, five-action tool with zero schema descriptions, the definition is too thin to carry the call 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 compensate, and it does not: 'message', 'reference' (defaulting to stash@{0}), and 'include_untracked' are never mentioned. Restating the action values merely duplicates the enum, leaving three parameters with no semantic guidance anywhere in the definition.

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 a specific resource (stashes) and enumerates the concrete operations (list, save, apply, pop, drop), so an agent immediately knows what capability this covers. It doesn't differentiate from siblings like git_restore or git_switch, but the stash-specific scope makes overlap unlikely, so 4 rather than 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?

The action list implies which operation to pick, and the trailing clause hints at a safety-relevant behavior, but there is no explicit when-to-use guidance such as 'use save before switching branches' or when to prefer git_stash over git_restore. It's implied usage only, with no exclusions or prerequisites stated.

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

Deploy Server