Skip to main content
Glama
Sign In
GitFerry

GitFerry

by mayank1307
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Apply a local GitFerry bundle

apply_bundle
Destructive

Validate and apply a local GitFerry bundle to replay commits and restore staged, unstaged, and untracked files; use dryRun to preview changes before modifying a repository.

Instructions

Validate and apply a trusted local .gitferry bundle: replay commits, restore staged/unstaged changes, and write untracked or snapshot files. Modifies the target unless dryRun=true. Preview first and review conflicts afterward. force bypasses repository, dirty-tree, and overwrite guards.

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": {
      "cwd": "<cwd>",
      "bundlePath": "<bundlePath>"
    },
    "name": "apply_bundle"
  }
}

Input Schema

NameRequiredDescriptionDefault
cwdYesAbsolute path to the target git repository
forceNoOverride repo-fingerprint, dirty-tree, and file-overwrite guards (default false)
dryRunNoValidate and report the plan without changing anything (default false)
bundlePathYesAbsolute path to the .gitferry bundle file
includeUntrackedNoWrite untracked files from the bundle (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.2

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already mark the operation as destructive and non-idempotent; the description adds that it modifies the target unless dryRun=true, that force bypasses repository, dirty-tree, and overwrite guards, and that conflicts should be reviewed afterward. This goes beyond the annotation flags by disclosing mutation scope and safety bypasses.

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?

Four short sentences are front-loaded with purpose and mutation behavior, followed by workflow and force semantics. Every sentence adds actionable information with no filler.

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

Completeness5/5

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

For a destructive apply tool whose annotations declare safety traits and whose five parameters are fully documented in the schema, the description supplies the missing operational context: dry-run preview, conflict review, and force guard bypass. An agent has enough information to call it correctly.

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 coverage is 100%, and every parameter is documented in the input schema, so the schema already carries parameter meaning. The description reinforces dryRun and force semantics but does not add format or semantic details beyond the schema, making the baseline 3 appropriate.

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?

The description gives a precise verb ('Validate and apply') and resource ('.gitferry bundle'), then enumerates what applying entails—replaying commits, restoring staged/unstaged changes, and writing untracked or snapshot files. That is detailed enough to distinguish it from pack_changes and inspect_bundle even though it does not name the siblings.

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?

It provides clear workflow guidance—'Preview first and review conflicts afterward'—and explains that dryRun prevents modification while force bypasses guards. It does not explicitly contrast this tool with inspect_bundle or pack_changes, so alternative-selection guidance is implied rather than 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