This server supports local Git development workflows with the following tools:
health_check: Confirm the server is running and reachable.
open_review: Launch an external diff visualizer to compare changes between two Git refs in a given repository. The server blocks until the user accepts or rejects the changes, returning "accepted" or "rejected".
repo_path (required): Absolute path to the Git repository.
base_ref (optional, defaults to main) and head_ref (optional, defaults to HEAD): The refs to compare.
Provides tools for reviewing pull requests by launching a diff visualizer against a git repository and returning the review decision (accepted/rejected).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PR Viewer MCP Server Review the diff between main and feature/add-greet in the current repo."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for local development workflows. Tools for branching and diff review, designed to be called by AI coding assistants.
uv sync --group devRelated MCP server: GitHub Code Reviewer
Tool | Description |
| Confirms the server is reachable. |
| Checks the working tree is clean, then creates a new branch. |
| Launches a diff visualizer and blocks until the user accepts or rejects. |
open_branchParameter | Default | Description |
| — | Absolute path to a git repo. |
| — | Name for the new branch. |
|
| Ref to branch from. |
Returns "Created branch '<name>' from <base_ref>" on success, or an error
string describing why it failed (dirty tree, branch already exists, bad ref).
open_reviewParameter | Default | Description |
| — | Absolute path to a git repo. |
|
| The base git ref (e.g. |
|
| The head ref to diff against base (branch name, commit SHA, etc.). |
Blocks until the user finishes reviewing. Returns "accepted" or "rejected".
Create a shell script that receives the repo context via env vars, launches the visualizer, captures the user's decision, and signals the result back to the server via the provided IPC path:
#!/usr/bin/env bash
# Env vars provided by the server:
# REPO_PATH – absolute path to the git repo
# BASE_REF – base ref (e.g. main)
# HEAD_REF – head ref (e.g. feature/add-greet)
# RESULT_PATH – IPC path the script writes "accepted" or "rejected" to
# launch your visualizer, capture the decision, then signal the result:
echo "accepted" > "$RESULT_PATH"The default visualizer (scripts/launch-octorus.sh) opens octorus in a new
terminal window and prompts accept/reject after the user quits.
Add to ~/.claude/mcp.json (global) or .mcp.json at a project root:
{
"mcpServers": {
"devflow": {
"command": "uv",
"args": ["run", "--directory", "/path/to/pr-viewer", "devflow-mcp"]
}
}
}opencode mcp add pr-viewerFollow the prompts: choose stdio, set command to uv, args to
run --directory /path/to/pr-viewer devflow-mcp. This writes to
~/.config/opencode/opencode.jsonc.
codex mcp add pr-viewer -- uv run --directory /path/to/pr-viewer devflow-mcpThis writes to ~/.codex/config.toml.
Create a branch called feature/add-login in /path/to/repo from main.Open a review of feature/add-greet in /path/to/repo against main.
If it's accepted, merge it with `gh pr merge --merge`.
If it's rejected, post a comment explaining what needs to change../scripts/setup-toy-repo.shCreates ./toy-repo/ with a main branch and a feature/add-greet branch.
To remove it when done:
./scripts/teardown-toy-repo.shuv run mcp dev src/devflow_mcp/server.pyOpen the inspector URL printed in the terminal (default: http://localhost:5173).
In the MCP inspector, select open_branch and fill in:
{
"repo_path": "<absolute-path-to-project>/toy-repo",
"branch_name": "test-branch"
}Select open_review and fill in:
{
"repo_path": "<absolute-path-to-project>/toy-repo",
"base_ref": "main",
"head_ref": "feature/add-greet"
}The tool blocks — the inspector shows a spinner until the review is complete. A terminal window opens automatically; answer the accept/reject prompt when you quit octorus.
import asyncio
from mcp.client.stdio import stdio_client, StdioServerParameters
from mcp.client.session import ClientSession
async def main() -> None:
server = StdioServerParameters(
command="uv",
args=["run", "--directory", "/path/to/pr-viewer", "devflow-mcp"],
)
async with stdio_client(server) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
await session.call_tool("open_branch", {
"repo_path": "/path/to/repo",
"branch_name": "feature/my-feature",
})
result = await session.call_tool("open_review", {
"repo_path": "/path/to/repo",
"base_ref": "main",
"head_ref": "feature/my-feature",
})
print(result.content[0].text) # "accepted" or "rejected"
asyncio.run(main())uv run pytestConfirm the PR Viewer MCP server is running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the purpose and does not disclose behavioral traits like read-only nature, side effects, or any constraints beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check with no parameters and an existing output schema, the description sufficiently conveys the tool's role. It does not need to explain return values because the output schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. With no parameters, the baseline is 4, and the description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool confirms the server is running. Verb 'confirm' and resource 'PR Viewer MCP server' are specific, and the tool is distinct from sibling 'open_review'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking server health but does not explicitly state when to use vs alternatives or provide exclusions. Context suggests it's a prerequisite, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open the diff visualizer for the given repo and refs.
Blocks until the user accepts or rejects the diff in the visualizer. Returns "accepted" or "rejected".
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | ||
| base_ref | No | main | |
| head_ref | No | HEAD |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately notes that the tool blocks until user action and returns 'accepted' or 'rejected', which are critical behavioral traits. However, it does not mention potential side effects or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the main action, and contains no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's straightforward nature, the description covers key aspects: what the tool does, that it blocks, and what it returns. It could mention that it requires user interaction and potential timeouts, but is generally complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for parameters, and the tool description adds no meaning beyond the parameter names. The description must compensate for the low schema coverage but fails to do so, leaving parameter semantics entirely to inference from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a diff visualizer for a given repo and refs, using specific verbs and resources. It distinguishes from the sibling 'health_check' tool, which has a different purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it blocks until user acceptance/rejection, but lacks explicit guidance on when to use this tool versus alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0health_checkopen_reviewThe two tools have completely distinct purposes: one checks server health, the other initiates a review workflow. There is no overlap or ambiguity.
Both names use snake_case, but 'health_check' is a noun phrase while 'open_review' is a verb phrase, creating a minor inconsistency in grammatical pattern.
Only two tools for a 'PR Viewer' server is very thin. The scope appears limited, and typical MCP servers offer more operations for meaningful interaction.
The server lacks essential tools for a PR viewer, such as listing PRs, viewing details, or commenting. Only a health check and a single review tool are provided, leaving major gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live PR/MR code reviews via review_url_code. OAuth or portal Bearer auth.
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
Git-native policy layer for AI agents: check_action verdicts against rules approved via PR.
Versioned artifact review for people and AI agents, with contextual comments and human control.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/darenkeck-dev/devflow-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
