The Five MCP Prompts in code-review-graph: Review, Architecture, Debug, Onboard, and Pre-Merge

The code-review-graph repository provides five specialized MCP prompt templates—Review Changes, Architecture Map, Debug Issue, Onboard Developer, and Pre-Merge Check—that encode complete, token-efficient workflows for AI-powered code analysis and developer automation.

The tirth8205/code-review-graph project implements a Model Context Protocol (MCP) server that transforms codebases into queryable knowledge graphs. At its core are five reusable MCP prompts defined in code_review_graph/prompts.py, each engineered to minimize LLM token consumption while maximizing insight through a disciplined "minimal first" strategy. These prompts orchestrate sequences of graph-analysis tools to handle everything from pre-commit reviews to new developer onboarding.

What Are MCP Prompts?

MCP prompts are Python functions that return a list of fastmcp.prompts.Message objects defining a structured conversation flow between an AI client (such as Claude or CodeBuddy) and the code-review-graph server. Unlike simple chat instructions, these templates enforce specific tool-calling sequences, parameter constraints, and output formats that leverage the underlying code graph.

According to the source code in code_review_graph/prompts.py, all five prompts share a common _TOKEN_EFFICIENCY_PREAMBLE that mandates:

• Call get_minimal_context first to obtain a concise risk overview
• Keep detail_level="minimal" unless deeper inspection is required
• Limit the number of tool calls per turn to reduce token waste

The Five Built-in MCP Prompt Templates

Each prompt corresponds to a distinct developer workflow as documented in the repository's README (line 315) and implemented between lines 45–159 of code_review_graph/prompts.py.

1. Review Changes Prompt (review)

Function: review_changes_prompt (lines 45–71)

Purpose: Pre-commit review of a single commit or diff.

Typical tool sequence:

1. get_minimal_context – Obtain a concise risk overview
2. detect_changes with detail_level="minimal" – Identify modified files
3. Conditional: query_graph and get_affected_flows for high-risk items only

This prompt enables developers to catch architectural regressions before they reach the repository by analyzing local changes against the codebase graph.

2. Architecture Map Prompt (architecture)

Function: architecture_map_prompt (lines 74–90)

Purpose: Generate a concise architecture diagram or system overview.

Typical tool sequence:

1. get_minimal_context
2. get_architecture_overview
3. list_flows
4. Optional: get_community for selected communities

Use this when documenting system boundaries or onboarding senior developers who need to understand module dependencies without tracing import chains manually.

3. Debug Issue Prompt (debug)

Function: debug_issue_prompt (lines 92–115)

Purpose: Guided debugging of a reported problem.

Typical tool sequence:

1. get_minimal_context
2. semantic_search_nodes – Locate relevant code entities
3. query_graph (callers) – Trace execution paths
4. Optional: get_flow for detailed flow analysis

This workflow leverages semantic search across the knowledge graph to identify potentially buggy functions and their caller chains, reducing time spent grepping through logs.

4. Onboard Developer Prompt (onboard)

Function: onboard_developer_prompt (lines 117–133)

Purpose: New-developer orientation and codebase familiarization.

Typical tool sequence:

1. get_minimal_context
2. list_graph_stats – Repository metadata
3. get_architecture_overview
4. list_communities – Module clusters
5. list_flows – Key execution flows

Instead of reading thousands of lines of documentation, new developers receive a curated, risk-scored tour of the repository structure highlighting critical paths and community boundaries.

5. Pre-Merge Check Prompt (pre-merge)

Function: pre_merge_check_prompt (lines 135–159)

Purpose: PR readiness validation and risk scoring.

Typical tool sequence:

1. get_minimal_context
2. detect_changes
3. Conditional branching: get_affected_flows, query_graph (tests), refactor (dead code detection)
4. Final structured output: GO/NO-GO recommendation

This prompt acts as an automated gatekeeper, calculating risk scores and identifying missing test coverage or dead code before allowing a merge to proceed.

Token-Efficiency and Risk-Scored Workflows

All five MCP prompts implement a minimal-first architecture that dramatically reduces LLM costs. By mandating an initial call to get_minimal_context, the prompts obtain a risk score early in the conversation. Low-risk changes trigger shorter tool sequences, while only high-risk items invoke expensive deep-analysis tools like get_affected_flows or refactor.

This selective, high-value tool usage ensures that routine reviews consume minimal tokens, while complex architectural changes receive the full analytical depth of the code graph.

How to Invoke the MCP Prompts

The following example demonstrates how to load and execute each prompt via the FastMCP client. This assumes an active MCP server started with code-review-graph serve.

from fastmcp import FastMCP
from code_review_graph.prompts import (
    review_changes_prompt,
    architecture_map_prompt,
    debug_issue_prompt,
    onboard_developer_prompt,
    pre_merge_check_prompt,
)

# Initialize the MCP client (stdio transport)

mcp = FastMCP("code-review-graph")

# 1. Review Changes (pre-commit)

response = mcp.run_prompt(review_changes_prompt(base="HEAD~1"))
print("Review Summary:", response)

# 2. Architecture Mapping

response = mcp.run_prompt(architecture_map_prompt())
print("Architecture Diagram:", response)

# 3. Debug Issue (provide a description)

response = mcp.run_prompt(debug_issue_prompt(description="Segfault when loading config"))
print("Debug Steps:", response)

# 4. Onboard Developer

response = mcp.run_prompt(onboard_developer_prompt())
print("Onboarding Overview:", response)

# 5. Pre-Merge Check (run on a PR branch)

response = mcp.run_prompt(pre_merge_check_prompt(base="origin/main"))
print("Pre-merge recommendation:", response)

Implementation details:

• FastMCP.run_prompt sends the list of Message objects to the MCP server
• The server executes the embedded workflow (e.g., calling detect_changes, query_graph, etc.)
• Each prompt returns a concise textual response suitable for CI/CD integration or IDE display

Summary

• code_review_graph/prompts.py houses five production-ready MCP prompt templates: review_changes_prompt, architecture_map_prompt, debug_issue_prompt, onboard_developer_prompt, and pre_merge_check_prompt.
• Each prompt enforces a token-efficient workflow starting with get_minimal_context and conditionally invoking deeper analysis tools only for high-risk items.
• The prompts cover the complete development lifecycle: review (pre-commit), architecture (documentation), debug (troubleshooting), onboard (new developers), and pre-merge (PR gates).
• All prompts return structured, actionable outputs (such as GO/NO-GO recommendations) that integrate easily with automated build pipelines.

Frequently Asked Questions

What distinguishes the Review Changes prompt from the Pre-Merge Check prompt?

The Review Changes prompt (review_changes_prompt) focuses on local, pre-commit diffs, typically comparing HEAD~1 against working directory changes. The Pre-Merge Check prompt (pre_merge_check_prompt) executes a broader risk assessment against a target branch (like origin/main), includes dead-code detection via the refactor tool, and produces a formal GO/NO-GO verdict suitable for CI gates.

How does the _TOKEN_EFFICIENCY_PREAMBLE reduce API costs?

The preamble forces the LLM to call get_minimal_context first, which returns a risk score and concise metadata. If the risk is low, the workflow skips expensive tools like get_affected_flows or deep query_graph traversals. This "minimal first" pattern ensures that simple changes trigger at most 2–3 tool calls rather than the 6–8 calls typical of deep analysis.

Can I customize the tool sequences in these MCP prompts?

Yes. While the default implementations in code_review_graph/prompts.py provide recommended sequences, you can import the prompt functions, modify the returned Message list, or wrap them to inject additional steps. The MCP server architecture treats these prompts as composable templates rather than fixed black boxes.

Where are the underlying MCP tools implemented?

The tools referenced in the prompts—such as detect_changes, query_graph, semantic_search_nodes, and get_architecture_overview—are implemented in the code_review_graph/mcp_tools/ directory. The FastMCP server (code_review_graph/fastmcp_server.py) registers these tools and exposes them to the prompt workflows defined in prompts.py.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}