codeforge-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JIRA_HOST | No | Your Jira host URL, e.g., https://your-company.atlassian.net | |
| JIRA_EMAIL | No | Your Jira email address | |
| JIRA_API_TOKEN | No | Your Jira API token | |
| JIRA_DEFAULT_PROJECT | No | Default Jira project key, e.g., MRTM |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_codeB | Generate clean, scalable, production-ready code for a feature. Returns a structured prompt the host LLM executes to produce code, tests, logging, error handling, and docs following industry best practices. |
| scaffold_serviceB | Scaffold a new Comviva Spring Boot microservice following company standards (packaging, logging, Kafka, Consul config, error handling, OpenAPI). Returns a structured prompt that yields a complete file tree with full source for pom.xml, the application class, config beans, controllers, producers/consumers, entities, application.yml/bootstrap.yml, logback-spring.xml, Dockerfile, and tests. |
| generate_test_casesA | Generate a complete JUnit 5 + Mockito test class for one Java class, with @DisplayName annotations on every test class, nested group, and test method for readable test reports. Follows Comviva standards (copyright header, package layout). Call once per class; for 'tests for all classes in the project', the host LLM should glob the sources and invoke this tool per file. |
| review_codeA | Review a pull request or diff. Returns a structured prompt that yields severity-tagged, file:line-anchored findings across correctness, security, performance, maintainability, and tests. |
| analyze_bugB | Analyze symptoms, stack traces, logs, and source to find the root cause of a bug. Returns a structured prompt that yields a hypothesis with evidence, severity, priority, recommended fix, and prevention actions. |
| generate_rcaA | Generate a detailed Root Cause Analysis report for a production incident. Returns a structured prompt the host LLM completes into a publish-ready RCA document with summary, timeline, root cause, impact, resolution, corrective actions, preventive measures, and lessons learned. |
| jira_get_issueC | Fetch a Jira issue by key. |
| jira_search_issuesC | Search Jira issues with a JQL expression. |
| jira_create_issueB | Create a Jira issue. Useful for filing bugs after analysis, opening tracking tickets for RCA action items, or creating stories from implementation plans. |
| jira_update_issueC | Update a Jira issue's fields. |
| jira_transition_issueB | Transition a Jira issue to a new status (e.g. 'In Progress', 'Done'). Optionally posts a comment with the transition. |
| jira_add_commentB | Add a comment to a Jira issue. Use to attach investigation notes, RCA summaries, or implementation updates. |
| jira_link_issuesC | Link two Jira issues. Link types are project-defined; common ones: 'Relates', 'Blocks', 'is blocked by', 'Caused by', 'Duplicate'. |
| jira_add_remote_linkC | Attach a remote link (e.g. PR URL, deployment URL, dashboard URL) to a Jira issue. |
| recommend_architectureA | Recommend a scalable system design for a stated goal. Returns a structured prompt covering architecture decisions, component diagram-as-text, data flow, scaling strategy, failure modes, and an explicit decision log. |
| review_architectureB | Review an existing architecture (API, database, microservice, event pipeline, or cloud infra) for scalability, reliability, security, and operability. Returns a structured prompt that yields graded findings and prioritized remediation. |
| identify_tech_debtB | Identify technical debt in a codebase and propose a refactoring strategy. Returns a structured prompt covering debt inventory, business impact, refactor roadmap, and quick wins. |
| review_cicd_pipelineA | Validate a CI/CD pipeline configuration for correctness, security, efficiency, and best practices. Returns a structured prompt yielding severity-tagged findings and recommended fixes. |
| review_infra_configA | Review Kubernetes, Docker, Terraform, Helm, or CloudFormation configuration for correctness, security, reliability, and cost. Returns a structured prompt with anchored findings and remediation. |
| deployment_readiness_checkA | Perform a pre-deployment readiness check. Returns a structured prompt assessing risk, validating rollback, observability, and go/no-go gates. |
| generate_documentationA | Generate technical documentation — design doc, API reference, runbook, README, or module overview — from supplied source material. Returns a structured prompt the host LLM completes into the document. |
| generate_adrA | Generate an Architecture Decision Record (ADR) in the MADR-style format. Returns a structured prompt the host LLM completes into a fully-formed ADR. |
| generate_implementation_planB | Generate a phased implementation plan for a feature or change. Returns a structured prompt yielding milestones, dependencies, risks, and a definition of done. |
| generate_migration_strategyB | Generate a migration strategy from one technology / version / pattern to another. Returns a structured prompt yielding stages, dual-write/dual-read plans, validation, cutover, and rollback. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 24 tools
Most tools are clearly distinct (generate_code vs review_code vs generate_rca). Minor overlap exists between review_architecture and recommend_architecture, and between analyze_bug and generate_rca, but descriptions help differentiate. Overall, an agent can select the right tool with minimal confusion.
Majority of tools follow a verb_noun pattern (generate_code, review_code, jira_*). The jira_ prefix adds consistency for that subgroup. Minor deviations like jira_add_remote_link (verb_noun_noun) are acceptable. No chaotic mixing; overall predictable.
24 tools is on the heavy side for a single server, especially since many are wrappers that return structured prompts rather than direct actions. While each tool has a clear purpose, the count feels excessive; consolidation or grouping (e.g., separate jira tools) would improve usability.
The toolset covers a wide range of development lifecycle activities (code generation, review, architecture, bug analysis, Jira integration, CI/CD, infra, documentation). However, it lacks tools for direct code manipulation (e.g., apply_patch, create_file) and for some domains like database schema generation or performance profiling. Notable gaps exist but core workflows are present.