git-readonly-mcp

by kazuki0529

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct read-only Git operation, with no overlapping purposes. Tools like git_list_repositories, git_list_remotes, and git_list_remote_refs are clearly separated by scope. The descriptions make it easy for an agent to select the correct tool.
Naming Consistency5/5
All tools follow a consistent 'git_' prefix and use a verb_noun pattern (e.g., list_repos, show_commit, compare_refs). Even single-word names like status and log align with Git's own conventions, maintaining predictability.
Tool Count5/5
15 tools is well within the ideal range and each tool earns its place for a read-only Git interface. The count is not excessive, and there are no redundant or filler tools.
Completeness5/5
The tool set covers the full spectrum of read-only Git operations: repository status, history, diffs, blame, grep, refs, tree browsing, and file reading. No significant gaps are apparent for the stated read-only purpose.
Average 3.4/5 across 15 of 15 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 11, 2026
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the word 'bounded', which hints at pagination/limits, but this adds little beyond what the schema already exposes via limit and offset parameters.
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 one short sentence with no unnecessary words, making it easy to parse. However, for a tool with 14 parameters, it is arguably too terse, but conciseness rewards brevity, so it earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (14) and complexity, the description is completely inadequate. It provides no context on output structure, usage scenarios, or how to combine parameters, relying entirely on annotations and schema—which are themselves underspecified—to guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (2 of 14 parameters have descriptions). The description does not explain any parameter semantics, leaving 12 parameters undocumented and the agent without guidance on how to effectively use filters, revision, author, or path arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads commit history with a specific verb and resource. However, it does not differentiate from sibling tools like git_show_commit or git_diff, which also operate on commit history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as git_show_commit or git_diff. It does not mention filtering options, prerequisites, or exclusions like 'use git_show_commit for a single commit'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no behavioral context beyond the basic operation, such as the meaning of the ranges or the nature of the output. It does not contradict annotations, but fails to add value beyond them.
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 of four words, with no waste. It front-loads the verb and resource. However, it is so terse that it omits useful context, preventing a perfect score.
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?
Despite having annotations and an output schema, the description fails to explain the parameter semantics or disambiguate from sibling tools. For a 5-parameter required tool with low schema coverage, the description is inadequate for an AI to invoke it correctly with confidence.
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 coverage is only 20% (only repositoryId has a description). The description does not explain oldBase, oldHead, newBase, or newHead, nor their relationship as commit ranges. The parameter names are self-explanatory to Git users, but the description does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses verb 'Compare' and resource 'commit ranges', clearly stating the operation. It is distinct from siblings like git_compare_refs (which compares refs) and git_diff (single commits), though it doesn't explicitly call out the distinction. Lacks detail on what output is produced, so not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as git_compare_refs or git_diff. No scenarios, exclusions, or alternative suggestions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, but the description says 'Register' which implies a write operation to create a registry entry. This is a direct contradiction. The description adds no meaningful behavioral context beyond the conflicting annotation.
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 sentence with no redundant words. While it is minimal, it is appropriately sized for the tool's apparent simplicity, though it could benefit from a bit more detail.
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?
The tool has annotations and an output schema, but the description does not explain the registration semantics, what happens if the path is invalid, or why readOnlyHint is present. This inconsistency and missing context make the description incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'path' with no description, and schema description coverage is 0%. The description does not explain what 'path' should be (e.g., absolute/relative, worktree directory). The agent has no semantic guidance for this parameter.
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 action ('Register'), the resource ('Git worktree'), and the output ('return its repositoryId'). This distinguishes it from sibling tools, which are all read/list/compare operations.
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?
The description implies usage for registering a worktree but does not explicitly say when to use this tool versus alternatives. There is no mention of alternative tools or exclusions, leaving the usage context vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only nature is covered. The description adds limited behavioral context by listing comparison targets, but it doesn't disclose any additional traits like output format defaults or merge-base behavior. Since there is no contradiction, a neutral score is appropriate.
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 a single, well-structured sentence that immediately conveys the core function. It is front-loaded with the verb and resource, contains no filler, and every word contributes meaning. This is exemplary conciseness.
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?
Given the tool has 9 parameters, enums, and a sibling list of 14 git tools, this one-line description is inadequate. It does not clarify the meaning of modes, when to use this versus comparable siblings, or how the output schema might vary by format. Annotations and output schema help, but the description leaves too many gaps for an agent to confidently select and invoke it correctly.
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 only 33% (3 of 9 parameters have descriptions), so the description must compensate for the missing parameter semantics. However, it does not elaborate on the meaning of 'base', 'head', 'mode', 'path', 'format', etc. The only hint is that 'working tree, index, HEAD, or two revisions' maps roughly to the 'mode' parameter, which is insufficient for a tool with this many parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Compare') and resource scope ('working tree, index, HEAD, or two revisions'). It is not tautological and gives a good sense of what the tool does, though it doesn't explicitly distinguish from siblings like git_range_diff or git_compare_refs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as git_compare_refs or git_range_diff. The description mentions the objects that can be compared but does not offer context on selection criteria, prerequisites, or exclusions. This leaves the agent without clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful context by noting it searches 'tracked content' (excluding untracked files) and does not invoke a shell, but it does not describe output format or pagination behavior. This is adequate but not rich behavioral disclosure.
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 a single, front-loaded sentence with no wasted words. 'Search tracked content' states the core action, and 'without invoking a shell' adds a meaningful nuance. It is concise and well-structured, though it could be expanded without losing conciseness.
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?
Given the tool's complexity (7 parameters, 2 enums) and sparse schema descriptions, the description is too thin. It doesn't clarify what 'tracked content' encompasses (e.g., working tree, index, or revisions), how patterns are matched, or how output is structured. Annotations and an output schema exist, but the description leaves significant gaps for an agent to infer correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is very low (only repositoryId has a description in the schema, about 14%). The tool description does not explain any parameters such as pattern, target, context, or patternType. Since the burden falls on the description to compensate for low schema coverage, and it fails to do so, the agent gets little assistance in constructing valid invocations.
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 identifies the tool's function: 'Search tracked content' uses a specific verb and resource. It distinguishes from siblings like git_read_file (reads a single file) and git_log (lists commits) by focusing on content search. The phrase 'without invoking a shell' adds a distinctive implementation detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. There are no prerequisites, exclusions, or references to sibling tools. The only context is the implied purpose, which is not sufficient for an agent to decide between this and other search or read operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds that it 'resolves' refs and reports specific outputs, but it does not disclose potential error cases or details like whether refs must be fully qualified. Given the strong annotations, the description provides sufficient but not exceptional transparency.
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 a single sentence that front-loads the core action ('Resolve two refs') and the output ('report merge base and ahead/behind counts'). There is no redundant or filler text, so it earns high marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the output schema likely defines return values, reducing the need for detailed return descriptions. However, the lack of directionality, ref format guidance, and usage context makes it incomplete for an agent deciding when to invoke this tool over siblings. It is adequate but not comprehensive.
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 coverage is only 33% (only repositoryId has a description). The description identifies left and right as 'two refs', which adds some meaning, but it does not specify acceptable ref formats (e.g., branch names, SHAs) or the directionality of ahead/behind counts (which ref is the base). This is a significant gap given the low schema coverage.
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 specifies the tool's function: it resolves two refs and reports merge base and ahead/behind counts. This distinct purpose sets it apart from siblings like git_diff (content differences) or git_log (commit history), making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description only states what it does, not the conditions under which it should be chosen, nor any exclusions or prerequisites (e.g., refs must exist in the repository).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that it lists three types of refs, but does not disclose behavior about the limit or filtering semantics. No contradiction exists, and the extra context is modest.
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 a single sentence with no redundant words. It is front-loaded and effectively communicates the core purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description provides a minimal viable explanation. However, it omits mention of the filtering capability via 'kind' and the default behavior of listing all refs. Since an output schema exists and parameters are defined in the schema, the description is adequate but not complete for nuanced usage.
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 only 33% (only repositoryId has a description). The description does not explain the 'kind' enum or 'limit' parameter, and it fails to compensate for the low coverage. The agent would need to infer parameter meanings solely from the schema, which is insufficient for the enum.
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 uses a specific verb ('List') and resource ('local branches, tags, and remote-tracking refs'), clearly distinguishing this tool from siblings like git_list_remotes (remote configurations) and git_list_remote_refs (remote refs). The word 'local' adds scoping that differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, lacks exclusions, and does not mention any prerequisites or context. It is implied that one would use it to list local refs, but no explicit direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the contextual detail 'at a revision' but does not disclose defaults (like HEAD) or the fact that recursion is off by default, which are behavior-relevant nuances.
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?
One sentence, no filler, purpose front-loaded. It earns its place without extra words, making it appropriately concise for a tool with simple core behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core operation is clear and output schema exists, but the description omits optional parameters and does not explain how path/recursive affect the result. With moderate complexity and sparse param coverage, the description leaves gaps that an agent would need to infer.
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 only 25% (just repositoryId). The description hints at the revision parameter but gives no explanation of 'path' or 'recursive'. Since the schema leaves these undocumented, the description should have elaborated but does not.
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 uses specific verb+resource ('List files and directories') and clarifies scope ('at a revision'). This clearly distinguishes it from sibling tools like git_list_repositories and git_read_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, and there are no preconditions or exclusions mentioned. The description states only what it does, not why an agent would choose it over other list-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds a small behavioral detail ('line-level') but does not disclose nuances like whether line numbers are inclusive, how revision affects the output, or if any file-state prerequisites exist. Still, it does not contradict annotations and adds a bit of context beyond the raw facts.
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?
One sentence, front-loaded with the action, and zero wasted words. It is appropriately sized for a tool that performs a single, well-known operation. The structure is ideal for quick scanning by an agent.
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?
While an output schema exists (so return values need not be explained), the description lacks enough context for correct invocation given the low schema description coverage. It omits any information about line range semantics, revision behavior, or how the tool behaves across different repository states. An agent may not know that start/end are optional, or what revision defaults to, without deeper inference.
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 coverage is only 20% (only repositoryId has a description), and the tool description does not compensate. It mentions 'a file' (implying path) and 'line-level' (implying start/end), but does not explain the semantics of start, end, or revision (beyond the default of HEAD). The description leaves most parameters under-documented, forcing the agent to rely on schema types and defaults.
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 uses a specific verb ('Show') and clearly identifies the resource ('line-level commit attribution for a file'). It distinctly separates this from sibling tools like git_log (which shows commit history) or git_diff (which shows changes between revisions), so an agent can unambiguously select git_blame for line-attribution needs.
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?
The description implies a use case (inspecting line-level history of a file) but does not explicitly state when to use it instead of alternatives or any preconditions. It lacks guidance on when not to use it (e.g., when needing only commit-level history). This is typical of a minimal but non-misleading description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context that the patch is optional and that changed files are shown, which is useful behavioral nuance beyond the 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 a single, front-loaded sentence with no filler. Every word adds value: 'Show commit metadata, changed files, and optionally its patch' efficiently conveys the tool's purpose without redundancy.
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?
With 6 parameters and an output schema, the description is too sparse. It does not mention that 'path' restricts the output to a specific file, nor how 'revision' selects the commit (defaulting to HEAD). These are critical usage details that are absent, making the tool under-specified for an agent to invoke correctly.
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 50% (3 of 6 params have descriptions). The description only hints at includePatch via 'optionally its patch' but adds no meaning for path, revision, or includePatch beyond the schema. It fails to compensate for the undocumented parameters, especially path and revision which are central to git_show.
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 uses a specific verb ('Show') and resource ('commit'), and clearly lists the output components: metadata, changed files, and optional patch. This distinguishes it from siblings like git_log (list commits) and git_diff (show differences) by indicating a single-commit focus.
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?
The description implies usage for inspecting a single commit, but provides no explicit guidance on when to use this tool over alternatives (e.g., git_log for history, git_diff for comparing branches). No exclusions or alternative tool mentions are given, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds 'bounded' which hints at the maxBytes limit but does not elaborate on truncation or error behavior. No contradiction with 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 a single, front-loaded sentence with no redundancy or irrelevant details. Every word adds meaning, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered. However, the description does not clarify the meaning of 'bounded' or how the target/revision parameters interact, and schema descriptions are sparse. It is adequate for a simple read tool but leaves room for more explanatory detail.
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 coverage is only 20% (only repositoryId has a description). The description does not explain path, target, maxBytes, or revision. Parameter names are somewhat self-explanatory, but the description fails to compensate for the sparse schema, leaving ambiguity about defaults and constraints.
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 uses a specific verb ('Read') and clearly identifies the resource ('a bounded file') and scope ('from a revision, the index, or the working tree'). This distinguishes it from sibling tools like git_list_tree (directory listing) or git_show_commit (commit details).
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?
The description implies when to use the tool (to read file content from various Git sources) but does not explicitly mention alternatives or exclusions. Sibling tools are not referenced, so the agent must infer differentiation from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description doesn't need to repeat that. It adds context about the scope (branch and working tree) but doesn't disclose additional behavioral details like exit codes or untracked file handling.
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 a single, concise sentence that directly states the tool's purpose. No unnecessary words; it is perfectly front-loaded and easy to parse.
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?
For a simple tool with one required parameter, an existing output schema, and clear safety annotations, the description is nearly complete. It lacks only a hint about when to use it in a workflow, such as checking for uncommitted changes before a merge.
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?
The single parameter repositoryId is fully described in the schema, including where to obtain it. The description adds no further parameter info, so it relies on the schema, which is acceptable given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: showing branch and working tree status. This is specific and distinct from sibling tools like git_log or git_diff, though it doesn't explicitly name alternatives.
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?
Usage is implied by the name and description—it is obvious when to call git_status. However, there is no explicit guidance on when to prefer it over alternatives or any exclusions, so it lacks explicit direction.
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 already declare the operation as read-only, idempotent, and non-destructive. The description adds the meaningful behavioral guarantee that URLs are not exposed, which is a privacy-relevant detail beyond the annotations. This adds useful context for an agent.
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 a single, tightly crafted sentence. It front-loads the action and resource while adding an important constraint without any wasted words.
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?
For a simple read-only list tool with one thoroughly documented parameter and an output schema, the description covers the essentials. It could be more explicit about usage versus sibling tools, but that gap is minor given the overall simplicity and annotations.
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?
The input schema fully documents repositoryId as 'ID returned by git_list_repositories', giving 100% coverage. The description does not mention parameters, so it adds no extra value beyond the schema. Baseline 3 is appropriate.
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 lists configured remote names and explicitly excludes URLs, distinguishing it from siblings like git_list_remote_refs (which lists refs) and git_list_repositories (which lists repositories). The verb 'list' and resource 'remote names' are specific and unambiguous.
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?
The description implies usage for retrieving remote names but does not explicitly compare with alternatives or provide when/when-not criteria. The tool's name and description make the use case fairly obvious, yet no alternatives or exclusions are mentioned.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the behavioral constraint of operating only on anonymous public HTTPS remotes, which is useful beyond the annotations. No contradiction found.
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 a single sentence with no redundancy. It is front-loaded with the action ('List') and resource, making it immediately scannable.
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?
For a simple list tool with rich annotations and an output schema, the description covers the essential purpose and constraint. It does not detail limit behavior or the distinction from git_list_refs, but those are not critical given the schema and sibling context. Overall, sufficient for effective selection.
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 low (33%) with only repositoryId described. The description provides no additional parameter semantics, so it fails to compensate for the gaps in the schema. Parameter names (remote, limit) are partially self-explanatory, but not fully.
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 uses a specific verb ('List') and resource ('refs from a configured anonymous public HTTPS remote'), clearly distinguishing it from sibling tools like git_list_refs (likely local refs) and git_list_remotes (which lists remotes themselves).
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?
The description provides clear context by specifying that this operates on a 'configured anonymous public HTTPS remote', which implies a prerequisite and excludes other remote types. However, it does not explicitly name alternatives or state when not to use it, so slightly below a 5.
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 already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds useful behavioral context beyond that: it specifies what is listed (configured workspace folders) and the exact condition checked (whether each is an available Git repository root). This helps the agent understand the tool's scope and output semantics.
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 a single, clear sentence that front-loads the verb and resource, with no filler or redundancy. Every word contributes to understanding the tool's purpose.
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?
For a zero-parameter read-only tool with strong annotations and an output schema present, the description is complete. It communicates what is returned (workspace folders and repo-root status) without needing to detail the output format, which is covered by the output schema.
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 zero parameters, the description correctly avoids parameter details. The schema coverage is 100% (fully described by the empty schema), so the baseline of 4 applies. No additional parameter clarification is needed.
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 uses a specific verb ('List') and resource ('configured workspace folders') and states the output criterion ('whether each is an available Git repository root'). This clearly distinguishes it from sibling tools like git_list_refs or git_list_remotes, which list refs/remotes rather than workspace folders.
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?
The description implies usage: it is for inspecting workspace folders to see which are repo roots. However, it provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The context is clear but not explicit.
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:

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

Score Badge

Copy to your README.md:

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

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/kazuki0529/git-readonly-mcp'

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