Mergify MCP server: there isn't one
A vendor that already publishes documentation for machine readers, and still exposes nothing an agent can call.
Last verified 1 September 2026 · from Mergify's documentation, its GitHub organization and the official MCP registry
This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector that lets the agent query the tool directly.
Summary
Mergify has no MCP server. Its GitHub organization carries no MCP-named repository and the official registry returns nothing.
The absence is deliberate rather than accidental. Mergify publishes an llms.txt for machine readers, and the single MCP entry in it is a blog post describing Mergify's own support triage built on other people's servers.
Mergify has thought about how machines read its documentation. It has not made its merge queue callable. An agent that wants queue state has to go through the repository host instead.
What is the Mergify MCP server, and is it usable?
Mergify automates pull request merging: merge queues, batching, and rules that decide when a change can land. That is release-stage work, and an agent that could read it would know why a change is not merging.
No server exists to ask. The search below covers the vendor's own machine-readable documentation index, its GitHub organization and the protocol's registry.
The llms.txt is what separates Mergify from vendors that never considered agents. Mergify built an internal agent on MCP servers, wrote about it, and still publishes none of its own.
Every one of the 90 vendors in this directory gets the same four checks. Mergify passes 0 of them.
| Check | Result | Evidence |
|---|---|---|
| Official | Fail | Nothing in the Mergifyio GitHub organization, and a search of it for MCP-named repositories returns zero results. |
| Maintained | Fail | There is nothing to maintain. Mergify writes for machine readers and has still published no server. |
| Distributed | Fail | No package and no entry in the official MCP registry. |
| Usable | Fail | Mergify publishes an llms.txt for machine readers. Its only MCP entry is a blog post about Mergify using other people's MCP servers for support triage, not an entry for a server of its own. |
Mergify works in CI and release, and neither its GitHub organization nor the official registry carries a server.
| Part of the work | What Mergify has here | Can an agent reach it |
|---|---|---|
| Code, tests & review | Merge rules on pull requests | No. Rules gate a merge; nothing exposes them to an agent |
| CI & release | Merge queues, batching, merge automation | No. Queue state is the product, and it is visible only through its effects on a pull request |
| Production observability | None | No telemetry product, and no server |
| Agent observability & evals | None | No traces or evaluations, and no server |
| AI cost management | None | No spend data, and no server |
Mergify keeps the answer to an unmerged pull request in its queue and rules, but publishes no tool that returns it. An agent therefore has to answer the question by reading the repository instead.
What can an AI agent do with Mergify?
Mergify leaves queue state invisible to an agent, which is the limit to keep in view.
An agent connected to your repository cannot see the queue. So it cannot say why a pull request has not merged.
Mergify holds the queue position, the batch and the rule evaluation. None of that is exposed over MCP: its GitHub organization has no MCP repository and the official registry has no entry.
A repository connector sees the pull request and its checks, which is the symptom rather than the cause.
Guard: Have the agent report what the repository shows and say explicitly that queue state was not available to it.
Do you need the MCP server at all?
No. Mergify offers documentation for agents instead. A repository connector is the practical route. GitHub's server reads pull requests, their checks and their comments, which is where Mergify's decisions surface.
For the pipeline behind those checks, CircleCI, Jenkins and Harness all publish servers that explain a failing run.
Mergify itself has a documented API, so a direct call remains available to anything that can make an HTTP request.
Read the pull request through a repository connector. Call Mergify's API directly when you need queue state.
Mergify MCP server setup
Nothing here installs a Mergify server, because there is none. This is the working route: read the pull request through the repository host, where the queue's effects are visible.
The distinction is worth stating. You can see what the queue did to a pull request; you cannot ask Mergify what its queue holds or why a rule fired.
Mergify's own API remains the route for queue state proper, and it is documented for machines even though no connector exists.
GitHub, hosted
Merge queue activity lands on the pull request: the merge commit, the status checks, the queue's own comments. GitHub's hosted server reaches all of it.
No credentials go into the command. The endpoint authorizes in the browser, so nothing long-lived is stored.
claude mcp add --transport http github \ https://api.githubcopilot.com/mcp/
GitHub, local and read-only
Where the agent should not be able to act on a pull request, the local server takes --read-only and a narrower toolset.
The personal access token is GitHub's own, and its scopes bound what the agent can reach.
claude mcp add-json "github" '{"command":"github-mcp-server",
"args":["stdio","--read-only"],
"env":{"GITHUB_PERSONAL_ACCESS_TOKEN":"<your-token>",
"GITHUB_TOOLSETS":"repos,pull_requests,actions"}}'GitLab, hosted
For GitLab-hosted projects the equivalent endpoint sits on the GitLab API.
No credentials appear in the command; authorization happens in the browser on first connection.
claude mcp add --transport http GitLab \ https://gitlab.com/api/v4/mcp
Every other client
Each block below is the configuration for one client, with the file path and the key that client expects.
Mergify already publishes for machines
Mergify ships an llms.txt for machine readers. Searching it for MCP returns one hit, a post about Mergify's own Claude-based support triage, and no entry for a Mergify server.
Checking this needs no credentials: fetch the file and search it for MCP.
curl -s https://docs.mergify.com/llms.txt | grep -i mcp
Read-only access, permissions and security
Mergify creates no credential here
Since no server exists, this page does not ask for a Mergify token.
The repository connector is the real grant
Reading pull requests through GitHub or GitLab gives an agent the whole repository surface those tokens allow, not just queue activity.
Use
--read-onlywhen merges are in scopeA merge queue exists to control what lands, and an agent with write tools on pull requests can act inside that control.
Toolsets keep the list short
repos,pull_requests,actionscovers what queue questions need and leaves the rest unregistered.Hosted routes store no token
Both hosted endpoints authorize in the browser, which keeps a long-lived credential off the machine.
Queue rules are configuration, not secrets
Mergify's rules live in the repository, so an agent reading the repo can already see the policy even without queue state.
Troubleshooting
- You cannot find a Mergify MCP server
- There is not one. The
Mergifyioorganization returns zero MCP-named repositories and the official registry returns nothing. - Mergify publishes an `llms.txt`, so a server seems likely
- That file is a documentation index written for machine readers, and its one MCP entry describes Mergify consuming other vendors' servers rather than publishing one. It shows Mergify has thought about machine access without making the merge queue callable.
- You want merge queue state inside an agent conversation
- Go through the repository host. GitHub and GitLab both publish servers that expose pull request and pipeline state, which is where the queue's effects are visible.
- You want to confirm this yourself
- Fetch Mergify's
llms.txtand search it for MCP, then search theMergifyioorganization for MCP-named repositories. On 1 September 2026 the organization was empty and the file returned one hit, a post about Mergify consuming other vendors' servers.
Mergify MCP server: Reference
| Item | Value |
|---|---|
| Server published | None |
MCP-named repositories in Mergifyio | 0 |
| Machine-readable documentation published | Yes, an llms.txt |
MCP entries in that llms.txt | One, a blog post about Mergify consuming servers |
| Packages published | None |
| Official MCP registry results | None |
| What is unreachable | Merge queue state, directly from Mergify |
| Checked | 1 September 2026 |
What engineers report
The searches are the evidence. One of them, the llms.txt, is a file most vendors do not publish at all.
| What was checked | What it shows |
|---|---|
MCP entries in Mergify's llms.txt | One, and it describes Mergify consuming other vendors' servers |
MCP-named repositories in Mergifyio | 0 |
| Official MCP registry results | None |
| Machine-readable documentation published | Yes, an llms.txt |
Mergify's llms.txt, its GitHub organization and the official MCP registry were checked on 1 September 2026. The documentation index exists and mentions no MCP server; the organization and registry return nothing.
Should you connect an agent to Mergify?
No. There is nothing to connect. Best for pairing Mergify with a repository connector, and calling its API directly for queue state.
- Strongest fit
- Teams who want merge automation and are content for it to be invisible to their agents.
- Main advantage
- Queue activity lands on the pull request, so a repository connector sees its effects without Mergify publishing anything.
- Main weakness
- Queue position and rule evaluation, the two things only Mergify knows, cannot be queried.
- Operational risk
- A repository connector with write tools can act inside the merge queue that exists to control what lands.
From Oodle
One platform for agent traces and infrastructure
Agent traces usually sit in a different product from the rest of your telemetry, so when a slow database makes an agent slow the symptom is in one tool and the cause is in another. Oodle keeps both in one query surface, from $10 per million spans.
See agent observabilityFrequently asked questions
Does Mergify have an MCP server?
No. Its llms.txt, its GitHub organization and the official MCP registry were all checked on 1 September 2026 and none carries one.
What is the llms.txt detail about?
Mergify publishes a documentation index aimed at machine readers. It shows the vendor has considered automated consumers, and its one MCP entry is about Mergify consuming servers rather than publishing one.
How can an agent see why a merge is blocked?
Only indirectly. A repository connector reads the pull request and its checks; the queue position and rule evaluation stay inside Mergify.
Is there an API?
Yes, Mergify documents one. Anything that can make an HTTP request can use it, including an agent with a fetch tool.
