Skip to main content
Glama
aflsolutions

ShadowGit MCP Server

by aflsolutions
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Start a ShadowGit session

start_session
Idempotent

Pause automatic snapshots for a project so a set of related edits is saved as one checkpoint instead of partial snapshots. Use checkpoint and end_session to save and resume.

Instructions

Pause ShadowGit's automatic snapshots for a project while you make a set of related edits, so they can be saved as one checkpoint instead of several partial snapshots. Returns the existing session if one is already active. Needs the ShadowGit app running. To save the edits and resume snapshots, use checkpoint and end_session.

Input Schema

NameRequiredDescriptionDefault
repoNoProject name or absolute path. Defaults to the current project.
descriptionYesWhat you are about to change, e.g. "Fix login redirect"

Output Schema

NameRequiredDescriptionDefault
repoYes
session_idYes
already_activeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv2.1.1
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / description / description
      Previous value: -"What you plan to do in this session"New value: +"What you are about to change, e.g. \"Fix login redirect\""
    • addedInput schema / properties / description / maxLength
      Added value: +200
    • addedInput schema / properties / description / minLength
      Added value: +1
    • changedInput schema / properties / repo / description
      Previous value: -"Repository name"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",
-  "description"
-]New value: +[
+  "description"
+]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "already_active": {
+      "type": "boolean"
+    },
+    "repo": {
+      "type": "string"
+    },
+    "session_id": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "session_id",
+    "repo",
+    "already_active"
+  ],
+  "type": "object"
+}
  2. Addedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), but the description adds real context beyond them: it pauses automatic snapshots, returns an existing session if one is already active, and requires the ShadowGit app to be running. That prerequisite and the nature of the state change are exactly what annotations cannot convey.

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?

Three tight sentences, front-loaded with the effect, then the idempotency behavior, then the prerequisite and next steps. No filler.

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?

With an output schema present, the description need not describe return values, and it covers purpose, prerequisite, and follow-up tools. Minor gaps only, such as not stating whether the pause applies repo-wide or session-scoped beyond what the schema implies.

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%, including the repo default and a description example, so the schema carries the parameter burden. The description only alludes to 'a project' without adding format or constraint detail beyond the schema.

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 and effect: pausing ShadowGit's automatic snapshots for a project so related edits collapse into one checkpoint. This is clearly distinguishable from sibling tools like checkpoint and end_session, which the description itself names.

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?

Gives a clear trigger condition (while making a set of related edits) and routes the agent to checkpoint and end_session for saving and resuming. It stops short of an explicit when-not rule, e.g. whether to skip this for trivial single edits.

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