MCP Integration
How Forge connects to AI assistants via the Model Context Protocol ā tools, prompts, and setup.
Forge uses the Model Context Protocol (MCP) to give AI assistants structured access to ticket data. This means Claude Code, Cursor, or Windsurf can read your tickets, check file changes, and update statuses ā all without you copying and pasting.
What is MCP?
MCP is an open protocol that lets AI assistants call external tools. Instead of the AI guessing what a ticket says, it can call get_ticket_context and get the full AEC directly.
Key properties:
- Transport: stdio (standard input/output) ā no ports, no HTTP
- Process model: The MCP server runs inside the CLI process
- Security: Uses your existing Forge credentials from
~/.forge/config.json - Scope: Project-level ā configured per repository via
.mcp.json
Setup
Automatic (Recommended)
bashforge mcp install
This detects your AI assistant and creates the appropriate configuration.
Manual Configuration
If you prefer to configure manually, add the Forge server to your .mcp.json file in the project root:
json{ "mcpServers": { "forge": { "command": "forge", "args": ["mcp", "serve"], "transport": "stdio" } } }
After adding the config, restart your AI assistant.
š Commit
.mcp.jsonto your repository so the whole team gets the same MCP tools.
Compatible AI Assistants
| Assistant | Setup Method | Status |
|---|---|---|
| Claude Code | forge mcp install (auto-detected) | Supported |
| Cursor | forge mcp install or manual .mcp.json | Supported |
| Windsurf | forge mcp install or manual .mcp.json | Supported |
MCP Tools
The Forge MCP server exposes 10 tools that AI assistants can call:
get_ticket_context
Fetch the full details of a ticket, including its AEC content.
| Parameter | Type | Required | Description |
|---|---|---|---|
ticketId | string | Yes | The ticket ID (e.g., T-001) |
Returns: Complete ticket data including title, description, status, acceptance criteria, tech spec, file changes, API contracts, scope, assumptions, and readiness score.
Use case: The AI reads this before starting a review or execution session to understand what needs to be built.
get_file_changes
Fetch the planned file changes for a ticket.
| Parameter | Type | Required | Description |
|---|---|---|---|
ticketId | string | Yes | The ticket ID |
Returns: Array of file change objects, each containing:
pathā File path relative to project rootactionācreate,modify, ordeletenotesā Description of what changes and why
Use case: The AI uses this during execution to know exactly which files to create and modify.
get_repository_context
Get information about the current Git repository.
| Parameter | Type | Required | Description |
|---|---|---|---|
path | string | No | Directory path (defaults to current working directory) |
Returns: Repository metadata including:
- Current branch name
- Git status (modified, staged, untracked files)
- File tree (directory structure)
- Remote URL
Use case: The AI uses this to understand the project structure and current state before making changes.
update_ticket_status
Transition a ticket to a new status.
| Parameter | Type | Required | Description |
|---|---|---|---|
ticketId | string | Yes | The ticket ID |
status | string | Yes | Target status (must be a valid transition) |
Returns: Updated ticket data.
Use case: The AI transitions tickets during execution ā for example, moving from Ready to Executing when starting work.
š§ Status transitions are enforced by the domain model. Invalid transitions (e.g., Define to Ready) will be rejected.
submit_review_session
Submit a set of Q&A pairs from a review session.
| Parameter | Type | Required | Description |
|---|---|---|---|
ticketId | string | Yes | The ticket ID |
qaItems | array | Yes | Array of { question: string, answer: string } objects |
Returns: Updated ticket data with the review session attached.
Use case: After the AI completes a review session (asking and answering technical questions), it submits the Q&A pairs to the API. The ticket transitions to PM Review status.
start_implementation
Record a developer's implementation branch and transition the ticket to Executing.
| Parameter | Type | Required | Description |
|---|---|---|---|
ticketId | string | Yes | The ticket ID |
branchName | string | Yes | Branch name (must start with forge/) |
qaItems | array | No | Array of { question, answer } from the implementation Q&A |
Returns: Updated ticket data with implementation session stored.
Use case: Called by the developer agent (Forgy) after branch creation to persist the branch name and Q&A answers on the ticket.
report_decision
Record a key decision made during implementation. Posts an execution event of type decision to the ticket.
| Parameter | Type | Required | Description |
|---|---|---|---|
ticketId | string | Yes | The ticket ID |
summary | string | Yes | Short description of the decision made |
rationale | string | No | Why this decision was made |
Returns: The created execution event.
Backend endpoint: POST /tickets/:id/execution-events with { "type": "decision", ... }
report_risk
Record a risk or blocker identified during implementation. Posts an execution event of type risk to the ticket.
| Parameter | Type | Required | Description |
|---|---|---|---|
ticketId | string | Yes | The ticket ID |
summary | string | Yes | Short description of the risk |
severity | string | No | Risk severity: low, medium, or high |
Returns: The created execution event.
Backend endpoint: POST /tickets/:id/execution-events with { "type": "risk", ... }
report_scope_change
Record a scope deviation from the original AEC. Posts an execution event of type scope_change to the ticket.
| Parameter | Type | Required | Description |
|---|---|---|---|
ticketId | string | Yes | The ticket ID |
summary | string | Yes | What changed from the original scope |
reason | string | No | Why the scope change was necessary |
Returns: The created execution event.
Backend endpoint: POST /tickets/:id/execution-events with { "type": "scope_change", ... }
submit_settlement
Submit the final implementation summary, create a Change Record, and transition the ticket from executing to delivered.
| Parameter | Type | Required | Description |
|---|---|---|---|
ticketId | string | Yes | The ticket ID |
summary | string | Yes | High-level summary of what was implemented |
filesChanged | array | No | List of file paths that were modified |
prUrl | string | No | URL of the pull request |
Returns: Updated ticket in delivered status with an attached Change Record.
Backend endpoint: POST /tickets/:id/settle ā creates a Change Record and transitions the ticket to delivered.
MCP Prompts
The Forge MCP server also provides 3 prompts ā pre-built personas that configure the AI for specific workflows.
forge-execute
Configures the AI as a dev-executor ā an experienced developer who implements tickets precisely according to the AEC.
What it does:
- Loads the dev-executor persona (focus on accuracy, following the spec, and clean code)
- Fetches the full ticket context via
get_ticket_context - Fetches file changes via
get_file_changes - Fetches repository context via
get_repository_context - Presents the AI with a complete implementation brief
When to use: When you want the AI to implement a Ready ticket end-to-end.
forge-review
Configures the AI as a dev-reviewer ā a thorough technical reviewer who asks clarifying questions about the implementation.
What it does:
- Loads the dev-reviewer persona (focus on asking the right questions, identifying gaps)
- Fetches the full ticket context
- Guides the AI to ask targeted questions about:
- Architectural decisions
- Existing patterns to follow
- Edge cases and error handling
- Performance and security concerns
- Collects Q&A pairs for submission
When to use: When you want the AI to help you review a ticket before execution ā especially useful for understanding complex specs.
forge-develop
Configures the AI as a dev-implementer ā Forgy in build mode, who guides the developer through implementation preparation.
What it does:
- Loads the dev-implementer persona (focus on asking implementation questions, never writing code)
- Fetches the full ticket context via
get_ticket_context - Fetches file changes via
get_file_changes - Fetches repository context via
get_repository_context - Guides the AI through a 3-phase flow: Load ā Q&A ā Branch Creation
When to use: When you want the AI to guide you through implementation prep before writing code.
Architecture
āāāāāāāāāāāāāāāāāāāāāāāā stdio āāāāāāāāāāāāāāāā
ā AI Assistant āāāāāāāāāāāāāāāāŗā Forge CLI ā
ā (Claude Code, etc.) ā ā MCP Server ā
āāāāāāāāāāāāāāāāāāāāāāāā āāāāāāāā¬āāāāāāāā
ā
ā HTTPS
ā¼
āāāāāāāāāāāāāāāā
ā Forge API ā
āāāāāāāāāāāāāāāā
- The MCP server runs as a child process of your AI assistant
- Communication is via stdin/stdout (no network ports needed)
- The server authenticates with the Forge API using your stored credentials
- All tool calls go through the same API the web app and CLI use
Troubleshooting MCP
| Problem | Solution |
|---|---|
| Tools not showing up | Run forge mcp install, then restart your AI assistant |
| "Not authenticated" errors | Run forge login first |
| Server crashes on startup | Verify Node.js 20+ with node --version |
| Tools work but return errors | Run forge doctor to check API connectivity |
.mcp.json not detected | Ensure it's in the project root (same level as .git) |