Skip to main content
Glama
modelcontextprotocol

git MCP server

Official

git_diff_staged

Read-onlyIdempotent

Display staged file diffs to review changes before committing, with adjustable context lines for better readability.

Instructions

Shows changes that are staged for commit

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
repo_pathYes
context_linesNo

Implementation Reference

  • The core handler function that executes git_diff_staged logic. It calls `repo.git.diff('--unified=<context_lines>', '--cached')` to show staged changes.
    def git_diff_staged(repo: git.Repo, context_lines: int = DEFAULT_CONTEXT_LINES) -> str:
        return repo.git.diff(f"--unified={context_lines}", "--cached")
  • Pydantic model defining the input schema for git_diff_staged: repo_path (str) and optional context_lines (int with default 3).
    class GitDiffStaged(BaseModel):
        repo_path: str
        context_lines: int = DEFAULT_CONTEXT_LINES
  • Enum entry mapping the tool name 'git_diff_staged' to the GitTools enum.
    DIFF_STAGED = "git_diff_staged"
  • Tool registration where GitDiffStaged is added to the list of tools with its schema and annotations.
    Tool(
        name=GitTools.DIFF_STAGED,
        description="Shows changes that are staged for commit",
        inputSchema=GitDiffStaged.model_json_schema(),
        annotations=ToolAnnotations(
            readOnlyHint=True,
            destructiveHint=False,
            idempotentHint=True,
            openWorldHint=False,
        ),
  • The dispatch/call-site in the handler loop that invokes git_diff_staged when the tool name matches DIFF_STAGED.
    case GitTools.DIFF_STAGED:
        diff = git_diff_staged(repo, arguments.get("context_lines", DEFAULT_CONTEXT_LINES))
        return [TextContent(
            type="text",
            text=f"Staged changes:\n{diff}"
        )]
Behavior2/5

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

Annotations provide readOnlyHint: true and destructiveHint: false, so the safety profile is clear. The description adds no behavioral context beyond 'shows changes', omitting details like requirement of repo_path or default context_lines behavior. With annotations covering safety, the bar is lower, but the description still fails to add useful behavioral context.

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?

The description is a single concise sentence with no unnecessary wording. However, it could include additional relevant details (e.g., parameter explanations) without becoming overly verbose, so it is appropriately sized but not optimally informative.

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 tool with no output schema and 0% schema description coverage, the description is incomplete. It does not specify that the output is a diff format, nor does it explain the context_lines parameter's effect. While the tool is simple, the lack of completeness could lead to agent confusion without additional context.

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%, yet the description does not explain any parameter meaning. The parameter names (repo_path, context_lines) are somewhat self-explanatory, but the description adds no additional semantics, such as the purpose of context_lines or how repo_path is used. The description should compensate for the schema coverage gap but fails.

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?

Description clearly states 'Shows changes that are staged for commit', using specific verb 'Shows' and resource 'changes that are staged'. This effectively distinguishes it from siblings like 'git_diff_unstaged' (for unstaged changes) and 'git_diff' (likely for all changes).

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?

No explicit when-to-use or when-not-to-use guidance is provided. However, the tool name and description imply it is for reviewing staged changes before commit, and the sibling tool names suggest alternatives. Usage context is implied but not elaborated.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/modelcontextprotocol/git'

If you have feedback or need assistance with the MCP directory API, please join our Discord server