Skip to main content
Glama
aflsolutions

ShadowGit MCP Server

by aflsolutions
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Query snapshot history with git

git_command
Read-onlyIdempotent

Run read-only git commands on ShadowGit history to inspect recent changes, file history, when something broke, or diffs between points in time.

Instructions

Run a read-only git command on a project's ShadowGit history: automatic snapshots taken every few minutes, kept apart from the project's own .git. Use it for what changed recently, a file's history, when something broke, or a diff between two points in time. Allowed: log, show, diff, status, blame, shortlog, rev-list, rev-parse, ls-files, ls-tree, cat-file, describe, show-branch. Commands that write, and options that read or write files outside the history (such as --output and --no-index), are refused. Output is capped at 25,000 characters; narrow it with -n, --since, --stat or a path.

Input Schema

NameRequiredDescriptionDefault
repoNoProject name or absolute path. Defaults to the current project.
commandYesA git command without the leading "git", e.g. log --since="1 hour ago" --stat

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv2.1.1
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / command / description
      Previous value: -"Git command to execute (e.g., \"log -10\", \"diff HEAD~1\", \"status\")"New value: +"A git command without the leading \"git\", e.g. log --since=\"1 hour ago\" --stat"
    • addedInput schema / properties / command / maxLength
      Added value: +1000
    • addedInput schema / properties / command / minLength
      Added value: +1
    • changedInput schema / properties / repo / description
      Previous value: -"Repository name (use list_repos to see available repositories)"New value: +"Project name or absolute path. Defaults to the current project."
    • addedInput schema / properties / repo / minLength
      Added value: +1
    • changedInput schema / required
      Previous value: -[
-  "repo",
-  "command"
-]New value: +[
+  "command"
+]
  2. Addedv1.0.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/idempotentHint annotations by enumerating the exact allowed subcommands (log, show, diff, status, blame, ...), stating that write commands and path-escaping options are refused at runtime, and disclosing a 25,000-character output cap with mitigation flags. These are behavioral constraints an agent cannot infer from the annotations or schema.

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?

Front-loads the core action, then use cases, then the allow/deny rules, then the output constraint. Every sentence is load-bearing; nothing restates the tool name or title.

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?

With only two parameters and no output schema, the description carries the remaining burden and does so: it explains ShadowGit semantics, permitted command surface, refused operations, and the output cap. An agent has everything needed to invoke this correctly on the first try.

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 coverage is 100%, so the baseline is 3, but the description adds genuinely useful semantics: which flags reduce output volume (-n, --since, --stat, a path), which maps directly onto how the command string should be formed. It does not clarify the repo default beyond what the schema already says.

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 verb (run) plus resource (read-only git command on a project's ShadowGit history) and immediately clarifies what ShadowGit is: automatic snapshots kept apart from the project's .git. Nothing else in the sibling set does anything similar, so it is trivially distinguishable from end_session, checkpoint, list_repos, etc.

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

Usage Guidelines5/5

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

Gives four concrete scenarios ('what changed recently, a file's history, when something broke, or a diff between two points in time') and an explicit negative boundary: writing commands and file-escaping options such as --output and --no-index are refused. The agent knows both when to reach for this and what will be rejected.

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