Skip to main content
Glama
kmandana
by kmandana

get_commit_context

Retrieves staged git changes and runs secret scanning to provide context for generating commit messages. Must be called before writing any commit.

Instructions

REQUIRED FIRST STEP: Get git diff and file changes to analyze before writing a commit message.

IMPORTANT: You MUST call this tool FIRST before generating any commit message. Never write a commit message without first seeing the actual git diff from this tool.

This tool ONLY shows STAGED changes. We intentionally do not support unstaged changes to ensure users have explicit control over what gets committed and prevent accidental commits.

CRITICAL: If the diff is empty and there are no files:

  1. STOP immediately - do NOT proceed with generating a commit message

  2. Tell the user: "No staged changes found. Please stage the files you want to commit first using: git add "

  3. DO NOT attempt to stage files automatically

  4. Wait for the user to stage their changes

Returns file changes and diff output with TOKEN-BASED pagination (MCP limit: 25k tokens). Large diffs are automatically paginated to stay under the token limit.

ANALYZING THE RESPONSE - follow these steps in order:

  1. SECRET SCAN (automated): Check secret_scan.status FIRST.

    • If "warnings_found": STOP and warn the user about each finding. Show the file, line number, type, and redacted preview for each finding. Recommend removing the secret before committing. Do NOT proceed to generate a commit message until the user acknowledges or explicitly chooses to proceed despite the warnings.

    • If "clean": proceed to step 2.

  2. SECRET SCAN (your review): Even if the automated scan is clean, briefly review the diff yourself for anything the regex-based scanner might miss:

    • Hardcoded credentials or secrets in unusual formats

    • Internal URLs, IP addresses, or hostnames that shouldn't be committed

    • Sensitive configuration values (database hosts, internal endpoints)

    • Comments containing passwords or access instructions If you spot anything suspicious, warn the user before proceeding.

  3. COMMIT MESSAGE: After confirming no secrets (or user acknowledgment), generate a commit message following:

    • 50/72 rule: 50 char subject line, 72 char body lines

    • Conventional commits format: type(scope): description

    • DO NOT include AI signatures, attribution, or "Generated with" footers

Args: cursor: Pagination cursor for large diffs (optional, returned as next_cursor) max_diff_tokens: Maximum tokens per response (default: 20000, safe under 25k limit) repo_path: Path to git repository (optional, defaults to Claude's working directory)

Returns: JSON string with: - has_changes: boolean - True if there are any staged changes to commit - files: list of changed files with status - secret_scan: results of secret detection on added lines - diff: the diff chunk (paginated) - next_cursor: pagination cursor for next chunk (if any) - pagination_info: token counts and chunk info - commit_format_guide: formatting rules for commit messages

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cursorNo
repo_pathNo
max_diff_tokensNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations provided, the description fully bears the burden of behavioral disclosure. It reveals that only staged changes are shown, explains pagination (token-based, 25k limit), details the return structure (has_changes, files, secret_scan, diff, etc.), provides a step-by-step analysis guide including secret scanning, and clarifies behavior for edge cases (empty diff).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is quite long and includes extensive step-by-step instructions that could be better placed elsewhere. While it front-loads the critical 'REQUIRED FIRST STEP' message, it could be more concise by separating behavior from workflow instructions.

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?

Given no annotations and a return structure described in the text, the description is complete: it covers all parameters, return fields, pagination, error handling (empty diff), security scanning, and even formatting rules for commit messages. No gaps remain for effective usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description's 'Args' section explains each parameter: cursor for pagination, max_diff_tokens for token limit, repo_path defaults to working directory. This adds meaningful context absent from 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?

The description clearly states 'Get git diff and file changes to analyze before writing a commit message,' specifying the verb (get), resource (git diff and file changes), and purpose (analyze before commit). It distinguishes itself from sibling tools like 'commit_changes' by positioning itself as the required first step.

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?

Explicitly states 'REQUIRED FIRST STEP' and instructs the agent to never write a commit message without first seeing the diff. It also describes when to stop (empty diff) and what to tell the user. While it doesn't directly compare to alternatives, the strong directive provides clear usage context.

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/kmandana/DevNarrate'

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