devops-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_REPOS | Yes | Comma-separated list of `owner/repo` pairs the server watches and exposes via the `devops://watchlist` resource (e.g. "owner/repo,owner/other"). | |
| GITHUB_TOKEN | Yes | A GitHub personal access token used to call the GitHub REST API. Classic tokens need `repo` for private repositories. Fine-grained tokens need read access to metadata, pull requests, issues, and commit statuses; check-run details also need permission to read checks. | |
| MCP_HTTP_PORT | No | Port for the optional local Streamable HTTP server. Only used when the server is started with `--http`; the default port is 3333. | 3333 |
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": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_open_pull_requestsA | List open pull requests for one repository and roll up CI. Failure wins over pending, which wins over success. An empty check set is "unknown", not passing. Returns the first page only. |
| summarize_pull_requestA | Fetch one pull request and return a bounded digest of its metadata, description, and diff. Patches are truncated. This tool does not call a language model; the host writes the prose from the digest. |
| list_issuesA | List issues for one repository. Pull requests are omitted because GitHub returns them from the issues API. Returns the first page only, so a page that is mostly pull requests can yield fewer issues than the limit. |
| create_issueA | Open a GitHub issue in one repository. This writes to GitHub. Call it only when the user has explicitly asked to create an issue. Creating the same issue twice creates two issues. |
| get_repo_activityA | Recent commits, updated issues, and updated pull requests since a timestamp. Defaults to the last 24 hours. Returns the first page of each list only. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| morning_standup | Ask the model to summarize watched repositories: recent activity, pull requests waiting on review, and CI failures. |
| pr_review_brief | Ask the model to brief a reviewer on one pull request using summarize_pull_request. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| watchlist | Repositories from the GITHUB_REPOS environment variable. Hosts that do not attach resources automatically can still read this URI. |
| octocat/Hello-World | Description, default branch, and open issue count for one repository. |
| octocat/Spoon-Knife | Description, default branch, and open issue count for one repository. |
TDQS
Scored across 5 tools
Each tool maps to a distinct resource+action: listing open PRs with CI rollup, digesting one PR, listing issues, creating an issue, and a cross-resource activity feed. The only mild overlap is between list_open_pull_requests and get_repo_activity (which also surfaces updated PRs), but the descriptions make the boundary clear (CI-focused open list vs. time-windowed feed).
All five names follow a strict snake_case verb_noun pattern: list_open_pull_requests, summarize_pull_request, list_issues, create_issue, get_repo_activity. Verbs (list/summarize/create/get) are used consistently with their implied semantics.
Five focused tools sit comfortably in the reasonable range and each earns its place around the PR/issue workflow. It is slightly lean for a server branded "devops," which implies CI/CD and deployment operations beyond pull requests and issues.
Read paths are solid (PR list+digest, issue list, activity feed) but the write surface is a single create_issue. There is no create/merge/comment on pull requests and no update/close/comment on issues, so common follow-up actions become dead ends for an agent.