MCP server that turns ChatGPT Web into a real coding agent on your own repositories: read, search, edit, build, test, git, pull requests. OAuth 2.1. No OpenAI API key.
repo-bridge demonstrates solid tool design with 23 well-named, verb-first tools (run_command, read_file, git_commit, etc.). All tools have descriptions (avg ~150 chars, within baseline 194). Input schemas are present and typed for all tools. However, output schemas are entirely undocumented, no tool specifies what fields it returns, forcing LLMs to infer structure. Error handling is present but generic; most tools lack recovery guidance. Parameter descriptions are adequate but inconsistent in detail. Security is strong (no secrets in params, destructive command gating), but composition could be tighter, some tools like run_command overlap with run_build/run_tests.
What this bridge is allowed to do: permission level, which capabilities are enabled, which executables may run, timeouts and output limits, protected branches, and whether GitHub/GitLab tokens are configured. Check this when a tool is refused, or before planning work that needs to push.
Push the current branch (unless already pushed) and open a pull request on GitHub or a merge request on GitLab. Write a title in the repository's convention and a body that states what changed, why, and what verification was run. If an open request already exists for this branch, its URL is returned instead of creating a duplicate.
Make targeted edits to an existing file by replacing exact text. Each edit's old_string must appear exactly once (include surrounding lines to disambiguate) unless replace_all is set. All edits are applied atomically: if any fails, none are applied.
Find files by name or glob pattern (e.g. "**/*Service.java", "**/test_*.py"). Use when you know roughly what a file is called but not where it lives.
List branches, or create / switch to one. Creating a feature branch is the normal first step before making changes, since commits to protected branches are refused.
Output schemas completely undocumented. No tool specifies return type, field names, or structure. LLMs cannot plan downstream calls or extract data reliably.
Error handling lacks recovery guidance. Tools throw BridgeError but do not tell LLM what to do next (retry, ask user, call alternative tool). Generic error messages waste agent reasoning cycles.
Parameter descriptions inconsistent in detail. Some params (e.g. 'timeout_seconds') lack range/unit info; others (e.g. 'pattern' in search_code) are well-documented. Standardize to 50-100 char descriptions with constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Stage and commit changes. By default every modified and untracked file is staged; pass `paths` to commit a subset. Refuses to commit on a protected branch — create a feature branch first. Write the message in the style of the repository's recent commits (check git_log).
Show changes as a unified diff. against="worktree" (default, unstaged changes), "staged", "head" (staged + unstaged), or a branch/commit name to compare the current branch against it (uses the merge base). Use stat_only=true first on a large change to see which files moved before pulling in the full diff.
Recent commits, newest first. Useful for matching the project's commit-message conventions before committing.
Current branch, upstream tracking, ahead/behind counts, and every staged / unstaged / untracked file. Check this before committing, and to notice user changes you did not make.
List files and directories. Use for orientation in an unfamiliar area of the repo. Build outputs, node_modules and .git are skipped automatically. Prefer search_code when you are looking for something specific.
Read a file as text. Returns exact file content (no line numbers by default) so it can be copied verbatim into edit_file anchors. For large files pass start_line/end_line, or use search_code first to find the region worth reading. Credential files (.env, keys, cloud config) are never returned.
Clone (or refresh) a remote Git repository into an isolated managed workspace and check out a branch. Use for work on a repository that is not already on this machine. Returns the same project brief as workspace_open. Each task gets its own workspace so parallel tasks cannot interfere.
Summarise everything done in this workspace: files changed (with per-file line counts from git), commands run and whether they passed, git operations, current branch and commit state. Use this to write an accurate final report instead of relying on memory — and to see what is still uncommitted.
Build the project using the build command detected from the repository (Maven, Gradle, npm/pnpm/yarn script, cargo, go, dotnet, make…). Returns exit code and output with error lines preserved even when the log is long.
Run a development command in the workspace (build tools, package managers, test runners, git, language toolchains). Commands run WITHOUT a shell: pipes, redirects, && and ; are rejected — issue separate calls instead. Only allowlisted executables are permitted; destructive commands require confirm=true. Prefer run_build / run_tests / run_lint, which pick the right command for this project automatically.
Run the project linter / static checks using the command detected from the repository (eslint, ruff, clippy, go vet, spotless…).
Run the project test suite using the command detected from the repository. Failing output is summarised with the failure lines pulled out, so you can go straight from "tests failed" to the responsible code. This is the tool to use in an implement → test → fix loop.
Search file contents across the repository and return matching lines with file:line locations. This is the primary way to find code — far cheaper than reading files. Supports literal or regex patterns, glob filters, and surrounding context lines. Respects .gitignore.
Stop tracking a workspace. For managed (cloned) workspaces you can also delete the directory to reclaim disk. Never deletes a local workspace's files.
Current state of a workspace without re-reading the repository: branch, working-tree changes, recent commits, detected commands, and everything this bridge session has already changed. Use this to resume work ("continue on quantix").
List repositories the bridge can open and which one is currently active. Call this first when you do not know what is available.
Open a local repository and return a full project brief: languages, build system, detected build/test/lint commands, module layout, git state, and the repo's AGENTS.md / CLAUDE.md instructions. Accepts an alias from workspace_list or an absolute path inside a configured root. Makes the workspace active for subsequent tool calls.
Create a new file, or replace / append to an existing one. Use this for NEW files. To change part of an existing file use edit_file instead — it is safer and much cheaper than resending the whole file.
Tool overlap: run_command, run_build, run_tests, run_lint all execute commands. Composition could be tighter, consider whether run_command is necessary if run_build/run_tests/run_lint cover the common cases.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Clients cannot infer safety properties without reading descriptions. Add annotations to guide agent planning.