mergesafe-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | No | Optional. Defaults to `gh auth token`. Used to read MergeSafe's comments and to post your replies | |
| MERGESAFE_API_KEY | Yes | An organization API key from the MergeSafe app (ms_live_…) | |
| MERGESAFE_API_URL | No | Optional. Defaults to https://app.mergesafe.ai | https://app.mergesafe.ai |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_findingsA | List MergeSafe's findings on the latest review of a pull request. repo is "owner/name". Each finding has severity (P0 most severe .. P3), title, problem, file, line, status, blocking, comment_id, comment_url, agent_prompt (a self-contained instruction for fixing it, read from the inline comment on GitHub) and comment_status: ok; no_comment (the finding has no inline comment); no_github_token (set GITHUB_TOKEN or run gh auth login, then call again); unavailable (the comment could not be read: open comment_url or the PR on GitHub). Intended loop: for each finding with blocking=true, check the claim against the file as it stands now; if it holds, apply the fix the agent_prompt describes and add a regression test; run the tests; commit and push; then call reply with "Fixed in " (or why it is not a real problem) on its comment_id. |
| request_reviewA | Ask MergeSafe to review the current head of a pull request. repo is "owner/name" (or the bare name in the key's own organization). tier and addons are optional; leave them out to use the repository's own settings. Returns MergeSafe's answer unchanged. Call it after pushing fixes; a head that was already reviewed is refused, not charged twice. |
| replyA | Reply on one MergeSafe inline comment thread, as you (with your own GitHub token, not MergeSafe's). repo is "owner/name"; comment_id is the finding's comment_id from get_findings. Use it to say "Fixed in " after pushing a fix, or to explain why a finding is not a real problem. |
| report_reproductionA | Report the result of reproducing one MergeSafe finding, as a reply on its thread (with your own GitHub token). repo is "owner/name"; comment_id is the finding's comment_id from get_findings. Pass the exact command you ran, its exit code (non-zero when the defect showed) and the tail of its output; the output is shortened to its last lines; a command over 500 characters is refused rather than shortened. Run it against the code as it stands, before fixing, and report what happened rather than what you expected: the reply records it on the thread as evidence for whoever judges the finding. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
get_findings and request_review are clearly distinct (read vs. trigger a review), but report_reproduction and reply both post a reply on a MergeSafe inline comment thread, differing only in payload and intent. The descriptions do explain when to use each, so an agent can pick correctly, but the overlap is real.
Three tools follow a verb_noun pattern (get_findings, request_review, report_reproduction) and one is a bare verb (reply). Mostly consistent with a single minor deviation that is still readable.
Four tools is a tight, well-scoped surface for a review-feedback loop (fetch findings, request review, respond, report reproduction). It is on the lean side but each tool earns its place.
The intended loop of fetch findings, fix, push, reply, and re-request review is fully covered. Minor gaps exist — no tool to resolve/dismiss a thread or inspect the PR diff/files — but agents can work around these via GitHub directly.