Git Polite

by uneco

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct, non-overlapping purpose: list_changes shows numbered unstaged changes, apply_changes stages selected lines, diff provides full file diffs, auto_commit guides commit organization, and unstack restructures commit history. The descriptions clearly differentiate their roles, with no ambiguity about when to use each tool.
Naming Consistency4/5
Four tools follow a consistent verb_noun pattern (list_changes, apply_changes, auto_commit, unstack), but 'diff' deviates as a single noun without a verb. While this minor inconsistency is noticeable, the naming remains readable and intuitive for the domain.
Tool Count5/5
With 5 tools, this server is well-scoped for its purpose of advanced git operations like partial staging and commit management. Each tool earns its place by addressing specific workflows, such as selective staging, full diff viewing, commit organization, and history restructuring, without being overly sparse or bloated.
Completeness4/5
The tool set covers core workflows for selective staging, diff viewing, commit organization, and branch restructuring, with no obvious dead ends. A minor gap exists in lacking a tool for direct commit creation or push operations, but agents can work around this using auto_commit guidance or external commands.
Average 4.7/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it specifies that output is never truncated (a key trait not covered by readOnlyHint or openWorldHint), mentions suitability for large files, and implies performance considerations. No contradiction with annotations exists.
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?
The description is well-structured and front-loaded, with a clear purpose statement followed by usage guidelines and parameter details. Every sentence adds value, and there's no redundant information, making it efficient and easy to parse.
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 the tool's moderate complexity, rich annotations, and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage, behavioral traits, and parameter semantics adequately without needing to explain outputs.
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?
With 0% schema description coverage, the description compensates by explaining 'path' as 'File path to view diff for' and 'unified' as 'Context lines around changes', adding meaning beyond the bare schema. However, it doesn't detail default values or constraints beyond what's implied.
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 the tool's purpose with specific verbs ('view complete diff') and resource ('single file'), explicitly distinguishing it from sibling 'list_changes' by emphasizing no truncation. It directly answers what the tool does in the first sentence.
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?
The description provides explicit guidance on when to use this tool vs. alternatives, listing three specific use cases (e.g., 'View the complete diff of a large file') and naming 'list_changes' as an alternative that truncates output. It clearly defines the context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by stating 'updates the git index directly' and 'reports remaining unstaged changes'. It adds valuable context about iterative staging and handling of untracked files, though it doesn't detail rate limits or auth needs beyond annotations.
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?
The description is front-loaded with the core purpose, followed by usage guidelines, examples, and behavioral details in a logical flow. Every sentence adds value, such as clarifying capabilities with untracked files and providing format examples, with no wasted text.
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 the tool's complexity (destructive operation with partial staging), the description is complete: it explains the purpose, usage, parameters, and behavior, and with an output schema present, it doesn't need to detail return values, covering all necessary context for effective use.
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?
With 0% schema description coverage, the description compensates by explaining both parameters: 'path' as 'File path to apply changes to' and 'numbers' with detailed format examples (e.g., '0001,0002,0005', '0001-0010'), adding meaning beyond the basic schema types.
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 the specific action ('Stage selected lines to git index for partial commits') and resource ('git index'), distinguishing it from siblings like 'auto_commit' and 'unstack' by emphasizing selective staging for partial commits, unlike full-file operations.
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?
It explicitly states when to use this tool ('After using list_changes to view numbered changes') and provides alternatives ('alternative to `git add -p`'), with clear differentiation from siblings by noting it can stage parts of untracked files, unlike typical 'git add'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, indicating a safe, exploratory operation. The description adds valuable behavioral context beyond annotations: it explains the tool uses 'progressive disclosure' to avoid token limits, shows recent commits and file statistics, and provides step-by-step instructions. However, it doesn't mention rate limits, authentication needs, or potential side effects, keeping it from a perfect score.
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?
The description is well-structured and concise. It starts with a clear purpose statement, then lists key features in bullet points, provides usage guidance, and ends with return information. Every sentence adds value without repetition, and it's front-loaded with the most important information.
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 the tool's complexity (guided session for organizing commits), the description is complete. It explains the purpose, workflow, when to use it, alternatives, and behavioral traits. With annotations covering safety and an output schema declared, the description doesn't need to detail return values or permissions, making it fully adequate for the agent's needs.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's behavior and output. A baseline of 4 is applied for zero parameters, as the description compensates by explaining what the tool does without redundant parameter info.
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 the tool's purpose: 'Start a guided session to organize and commit all unstaged changes with appropriate granularity.' It specifies the verb ('organize and commit'), resource ('unstaged changes'), and scope ('with appropriate granularity'). It distinguishes from siblings by focusing on guided organization rather than direct diff viewing (list_changes, diff) or other operations (apply_changes, unstack).
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?
The description explicitly states when to use this tool: 'Use this when you have multiple logical changes mixed together and want to organize them into separate, well-structured commits.' It also provides alternatives: 'Use list_changes or diff tools to view detailed changes for specific files.' This gives clear context for when to choose this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, but the description adds valuable behavioral context beyond this. It explains key features like including untracked files, numbering changed lines, pagination support, and auto-truncation of large diffs. It details how to handle truncated files and clarifies that this tool's output format is required for selective staging with `apply_changes`. No contradiction with annotations exists.
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?
The description is well-structured and front-loaded with the core purpose. Each section (Key features, Handling truncated files, Use cases, Args, Returns) earns its place by providing essential information without redundancy. The text is dense with actionable guidance while remaining focused on helping the agent use the tool correctly.
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 the tool's complexity (pagination, truncation, line numbering) and the presence of annotations and output schema, the description is complete. It covers purpose, usage guidelines, behavioral details, parameter semantics, and integration with sibling tools. The output schema handles return format documentation, so the description appropriately focuses on operational context.
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?
With 0% schema description coverage, the description compensates well by explaining all 5 parameters in the Args section. It provides meaning for each parameter: 'paths' filters files, 'page_token' is for pagination, 'page_size_files' is a safety limit, 'page_size_bytes' is the primary limit, and 'unified' controls context lines. Default values are noted, adding clarity beyond the bare 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 the tool's purpose: 'View unstaged git changes with line-level selection numbers for partial staging.' It specifies the verb ('view'), resource ('unstaged git changes'), and key functionality ('line-level selection numbers'). It explicitly distinguishes from sibling `git diff` by noting inclusion of untracked files and line numbering for staging.
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?
The description provides explicit guidance on when to use this tool: 'PREFER THIS OVER `git diff` when you need to selectively stage changes.' It also specifies when to use alternatives: use `diff` tool for truncated files, and notes that `git diff` output lacks line numbers. It lists specific use cases and mentions the next step: 'After viewing changes, use apply_changes with the line numbers.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations. While annotations indicate destructive and non-read-only operations, the description details that it 'creates branches from origin/main', 'cherry-picks commits in order', warns about 'existing branches with the same name will cause an error', clarifies 'the current branch is not changed', and explains it 'uses low-level git commands to avoid changing working directory'. This provides crucial operational insights.
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?
Well-structured and appropriately sized. It front-loads the core purpose, provides usage guidelines with an example, details parameters, return format, and important notes. Every sentence adds value without redundancy, efficiently covering complex functionality in a clear hierarchy.
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 the tool's complexity (destructive operation with nested parameters) and 0% schema coverage, the description is exceptionally complete. It explains purpose, usage, parameters, return values (though output schema exists, it clarifies format), and behavioral notes. With annotations covering safety aspects, the description adds all necessary operational context for effective use.
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?
With 0% schema description coverage, the description fully compensates by explaining both parameters. It details that 'branches' is a dictionary mapping names to commit lists with examples of commit references (SHA, branch names, symbolic refs) and ordering. It explains 'parent' as the base commit with default 'origin/main' and that all branches start from it. This adds essential meaning beyond the bare 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 the tool's purpose with specific verbs ('unstack', 'transforms', 'creates') and resources ('linear commits', 'parallel branches', 'separate PRs'). It distinguishes from siblings by focusing on restructuring commit history rather than applying changes, auto-committing, diffing, or listing changes.
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?
Explicitly states when to use: 'Use this when you've made multiple changes in sequence but want to create separate PRs for different logical changes.' It also provides a concrete example scenario and distinguishes from alternatives by explaining the transformation from linear to parallel branches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-git-polite MCP server](https://glama.ai/mcp/servers/uneco/mcp-git-polite/badges/card.svg)](https://glama.ai/mcp/servers/uneco/mcp-git-polite)

Score Badge

Copy to your README.md:

[![mcp-git-polite MCP server](https://glama.ai/mcp/servers/uneco/mcp-git-polite/badges/score.svg)](https://glama.ai/mcp/servers/uneco/mcp-git-polite)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/uneco/mcp-git-polite'

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