Loading ToolBench

Reading the current corpus…

gitbridge-mcp MCP server · F · ToolBench

← Browse

gitbridge-mcp

github.com/ioTus/gitbridge-mcp

MCP bridge server connecting AI chat clients to GitHub repositories via the Model Context Protocol

<=2025-11-25STDIO22 tools

45/100

Definition Quality46

Protocol Readiness47

Supportability43

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging, Dynamic Client Registration

Deprecated protocol patterns detected

Summary

GitBridge has 22 tools with consistent naming (verb_noun pattern) and basic parameter descriptions. However, critical gaps undermine quality: (1) Tool descriptions are generic and lack WHEN/WHY guidance, e.g., 'Read file contents from a repository' does not explain when to use read_files vs session_bootstrap. (2) Output schemas are completely undocumented, no tool shows what fields are returned, forcing LLMs to guess. (3) Parameter descriptions are minimal (avg ~30 chars) and lack constraints, ranges, or format guidance. (4) No error handling guidance, tools do not explain recovery paths. (5) Destructive tools (delete_file, patch_multiple_files) lack confirmation or dry-run patterns. (6) No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Naming is solid (read_files, create_branch, delete_file), but descriptions and schemas fall well short of production baseline (94% of A+ tools have full docstrings; 100% have documented return types).

Tools (22)

add_issue_commentwriteauth47/100

Add a comment to an issue

create_branchwriteauthsource verified48/100

Create a new branch in a repository

create_issuewriteauthsource verified50/100

Create a new issue in a repository

create_repowriteauthsource verified48/100

Create a new repository

delete_filedestructiveauthsource verified42/100

Delete a file from a repository

flush_queuewriteauthsource verified42/100

Flush queued write operations with a commit message

get_file_diffread onlyauthsource verified43/100

Get the diff for a file at a specific commit

get_project_board

Issues (5)

CRITICALtool ↗

Output schemas completely undocumented. No tool shows what fields are returned, their types, or structure. LLMs cannot plan downstream calls or extract required data.

read_fileslist_filessearch_filesget_recent_commitsget_file_difflist_brancheslist_issuesread_issueget_project_board

CRITICALconfirmation-request ↗

Destructive tools (delete_file, patch_multiple_files, move_file) lack confirmation, dry-run, or undo patterns. Agents can irreversibly delete or modify code without safeguards.

delete_filepatch_multiple_filesmove_file

HIGHtool-description ↗

Tool descriptions are generic and lack WHEN/WHY guidance. E.g., 'Read file contents from a repository' does not explain when to use read_files vs session_bootstrap, or what metadata_only mode does. Descriptions average ~30 chars; baseline is 194 chars.

read_filessession_bootstrappatch_multiple_files

Recommendations

Document output schemas for all tools. For each tool, specify returned fields, types, and structure. E.g., read_files should return [{path, content, encoding, size_bytes}]. This enables LLMs to chain tools and extract required data.
Expand tool descriptions to 100 - 200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and any prerequisites. E.g., 'Read file contents from a repository. Use this for single/multiple files; use session_bootstrap to load entire repo context. Supports partial reads via offset_bytes/max_bytes.'
Add parameter constraints: enums for content_encoding and state fields; min/max for numeric params (offset_bytes, max_bytes, limit); regex patterns for branch/file names. Include format guidance in descriptions: 'Branch name (alphanumeric, hyphens, underscores; max 255 chars)'.
Implement confirmation/dry-run for destructive tools. Add a 'dry_run' boolean param to delete_file, patch_multiple_files, move_file. Return what would be deleted/modified without executing. Require explicit confirmation for actual execution.
Add tool annotations: mark read-only tools with readOnlyHint=true; mark destructive tools (delete_file, patch_multiple_files) with destructiveHint=true; mark idempotent tools (create_branch if branch exists) with idempotentHint=true. This guides agent planning.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

45/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	45	<=2025-11-25	v2