codeforge-mcp

CodeForge — an MCP (Model Context Protocol) server that exposes Senior Software Engineer / Technical Lead capabilities as individual tools. Any MCP-compatible client — Claude Desktop, Cursor, VS Code, Claude Code — can call these tools to delegate engineering tasks to a model playing a senior-engineer persona.

The server is prompt-mediated for reasoning tools: code generation, code review, RCA, etc. each return a structured prompt that locks the host LLM into the senior-engineer persona and a strict output schema. The reasoning happens in the client's LLM, so no second LLM API key is needed.

Jira tools call the Jira REST API directly.

Tools exposed

| Tool | Purpose | | --- | --- | | generate_code | Generate clean, scalable, production-ready code with tests, logging, and docs. | | scaffold_service | Scaffold a new Comviva Spring Boot microservice (pom, packaging, logging, Kafka, Consul, OpenAPI) per the standards in standards/comviva-springboot.md. | | generate_test_cases | Generate a JUnit 5 + Mockito test class for one Java class with @DisplayName on every test, @Nested groups per method, AssertJ assertions, and Comviva copyright header. For project-wide tests, the host LLM iterates over source files and calls this per class. | | review_code | Review a pull request / diff with severity-tagged findings anchored to file:line. | | analyze_bug | Root-cause a bug from symptoms, stack trace, logs, and source. | | generate_rca | Produce a publish-ready Root Cause Analysis report for an incident. | | jira_get_issue | Fetch a Jira issue. | | jira_search_issues | JQL search. | | jira_create_issue | File a new issue (bug, story, task, epic). | | jira_update_issue | Update fields on an issue. | | jira_transition_issue | Move an issue through workflow states. | | jira_add_comment | Attach investigation notes, RCA, or implementation updates. | | jira_link_issues | Link related issues (Blocks, Relates, Caused by, etc.). | | jira_add_remote_link | Attach a PR / deployment / dashboard URL to an issue. | | recommend_architecture | Propose a scalable system design for a goal. | | review_architecture | Review an API / database / microservice / pipeline / cloud infra design. | | identify_tech_debt | Inventory technical debt and produce a refactor roadmap. | | review_cicd_pipeline | Validate a CI/CD pipeline config. | | review_infra_config | Review Kubernetes / Docker / Terraform / Helm / CloudFormation. | | deployment_readiness_check | Pre-deploy go/no-go review with rollback and observability checks. | | generate_documentation | Tech design, API reference, runbook, README, or module overview. | | generate_adr | Architecture Decision Record (MADR style). | | generate_implementation_plan | Phased implementation plan with risks and definition of done. | | generate_migration_strategy | Migration strategy with stages, cutover, and rollback. |

Install & build

cd D:/eclipse-workspace/MRTM_7.12/mrtm/codeforge-mcp
npm install
npm run build

This produces dist/index.js.

Configure environment

Jira tools require credentials. Copy .env.example to .env and fill in:

JIRA_HOST=https://your-company.atlassian.net
[email protected]
JIRA_API_TOKEN=<API token from id.atlassian.com/manage-profile/security/api-tokens>
JIRA_DEFAULT_PROJECT=MRTM

.env is not loaded automatically — pass these as real environment variables when the MCP client launches the server (see the next section). Tools that don't touch Jira work without these variables.

Register with an MCP client

Claude Desktop

Edit %APPDATA%\Claude\claude_desktop_config.json (Windows) and add:

{
  "mcpServers": {
    "codeforge": {
      "command": "node",
      "args": ["D:/eclipse-workspace/MRTM_7.12/mrtm/codeforge-mcp/dist/index.js"],
      "env": {
        "JIRA_HOST": "https://your-company.atlassian.net",
        "JIRA_EMAIL": "[email protected]",
        "JIRA_API_TOKEN": "<token>",
        "JIRA_DEFAULT_PROJECT": "MRTM"
      }
    }
  }
}

Restart Claude Desktop. The tools will appear in the tool picker.

Claude Code (CLI)

claude mcp add codeforge node "D:/eclipse-workspace/MRTM_7.12/mrtm/codeforge-mcp/dist/index.js" \
  -e JIRA_HOST=https://your-company.atlassian.net \
  -e [email protected] \
  -e JIRA_API_TOKEN=... \
  -e JIRA_DEFAULT_PROJECT=MRTM

Cursor / VS Code (with MCP extension)

Add an entry in the client's MCP settings pointing to the same node dist/index.js command with the env vars above.

Company standards (used by scaffold_service)

The conventions for new microservices live in standards/comviva-springboot.md — packaging, copyright header, constructor injection, @Slf4j parameterized logging, Spring Kafka config pattern, Consul config layout, error handling, JPA, scheduling, Dockerfile. Edit that file to refine conventions; scaffold_service re-reads it on every call (no rebuild needed).

Example invocation from Claude

Scaffold a new service called rewardservice that consumes the reward.events Kafka topic, persists a RewardLedger entity to MySQL, and exposes GET /rewards/{customerId} to read balances.

The MCP client picks scaffold_service, fills in the args, and the host LLM produces the full project — pom.xml, RewardserviceApplication.java, config/KafkaConfig.java, service/RewardEventConsumer.java, dao/RewardLedgerRepository.java, model/RewardLedger.java, controller/RewardController.java, application.yml, bootstrap.yml, consul-prop.yml, logback-spring.xml, Dockerfile, and tests — all carrying the Comviva copyright header and following every rule in the standards file.

How the prompt-only tools work

When you call review_code, the server doesn't itself invoke an LLM. It returns a single text block containing:

1. A senior-engineer persona prelude (role, tone, standards).
2. The supplied inputs (the diff, PR title, etc.) embedded in a task description.
3. A strict output contract — the exact sections, severity scale, table columns, and rules the LLM must follow.

The host LLM (Claude Desktop, Cursor, etc.) then executes that prompt as its next reasoning step. Because the contract is strict and the persona is consistent across tools, you get reproducible, high-quality output without standing up a second LLM endpoint.

If you later want the server to call an LLM itself (e.g. for batch jobs without a host UI), wire an Anthropic client into each tool's handler and post the existing prompt body to it. The current architecture is designed to make that swap trivial.

Adding a new tool

1. Create src/tools/yourTool.ts exporting a ToolDefinition:

   import { z } from "zod";
   import { withPersona } from "../prompts/persona.js";
   import type { ToolDefinition } from "./types.js";
   
   const Schema = z.object({ /* inputs */ });
   
   export const yourTool: ToolDefinition = {
     name: "your_tool",
     description: "What it does, in one sentence.",
     inputSchema: Schema,
     handler: async (raw) => {
       const input = Schema.parse(raw);
       return { content: [{ type: "text", text: withPersona("...prompt body...") }] };
     },
   };

2. Register it in src/tools/index.ts under the right capability group.

3. npm run build. The client picks up the new tool on next restart.

Sharing with the team

Two distribution paths — start with A, promote to B once the standards stabilise.

A. Git clone

Maintainer (one-time): push this folder to GitHub.

Each teammate (one-time):

git clone https://github.com/ThakurAnketPratapSingh/codeforge-mcp.git
cd codeforge-mcp
setup.bat      # Windows
./setup.sh     # macOS / Linux / Git Bash

setup.bat / setup.sh installs deps, builds, and runs claude mcp add codeforge ... automatically. Teammates add their own Jira creds afterwards (re-register with -e JIRA_* flags — see the setup script output).

Getting updates:

git pull && setup.bat

Standards live in standards/comviva-springboot.md, versioned with the repo, so git pull is how new conventions reach every teammate.

B. Public npm (npmjs.com)

The package is published to the public npm registry as @anketpsingh/codeforge-mcp. Anyone with Node.js installed can grab it — no token needed.

⚠️ Public publication means standards/comviva-springboot.md is searchable on npmjs.com. Make sure that's intended.

Maintainer — one-time setup:

1. Create a free account at https://www.npmjs.com/signup
2. Enable 2FA on the account (npm requires it for publishing).
3. Authenticate on this machine:

   npm login

   Enter username, password, email, and the OTP from your authenticator.

Maintainer — each release:

npm run release:patch   # 0.1.0 → 0.1.1, builds, publishes
npm run release:minor   # 0.1.0 → 0.2.0
npm run release:major   # 0.1.0 → 1.0.0

prepublishOnly rebuilds from clean automatically. Only dist/, standards/, README.md, and .env.example ship.

Each teammate — one-time:

npm install -g @anketpsingh/codeforge-mcp
claude mcp add codeforge codeforge-mcp

No .npmrc or token required — it's public.

Getting updates:

npm install -g @anketpsingh/codeforge-mcp@latest

Per-user secrets (both paths)

Jira credentials are per-user. Each teammate adds their own via claude mcp add ... -e JIRA_EMAIL=... -e JIRA_API_TOKEN=... after the base install. Shared values (JIRA_HOST, JIRA_DEFAULT_PROJECT) go in the README so everyone copies them verbatim.

Evolving the standards

standards/comviva-springboot.md is the single source of truth. To change a convention:

1. Edit the file
2. Path A: commit, push, teammates git pull && setup.bat
3. Path B: bump version, npm run release:minor, teammates npm install -g @anketpsingh/codeforge-mcp@latest

Standards changes are visible in git log standards/ — useful when investigating "why does the generator do X now".

Project layout

codeforge-mcp/
├── src/
│   ├── index.ts              # stdio entry point
│   ├── server.ts             # MCP server wiring
│   ├── prompts/persona.ts    # shared senior-engineer persona
│   ├── jira/client.ts        # Jira REST client (Cloud v3 / ADF)
│   └── tools/
│       ├── types.ts          # ToolDefinition shape, error helper
│       ├── index.ts          # tool registry
│       ├── codeGeneration.ts
│       ├── codeReview.ts
│       ├── bugAnalysis.ts
│       ├── rca.ts
│       ├── jira.ts
│       ├── architecture.ts
│       ├── devops.ts
│       └── documentation.ts
├── package.json
├── tsconfig.json
└── .env.example