Co-dev review MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SONAR_URL | No | SonarQube/SonarCloud base URL | |
| GITLAB_URL | No | GitLab instance URL | |
| SONAR_TOKEN | No | Sonar token that can read the project | |
| CO_DEV_TRACE | No | Set to "off" to disable tracing | |
| GITHUB_TOKEN | No | GitHub token with repo (or fine-grained pull-request read/write) | |
| GITLAB_TOKEN | No | GitLab token with api scope | |
| GITHUB_API_URL | No | GitHub API base URL | |
| REVIEW_REPO_ROOT | No | Absolute path to the local checkout used by step=checks, step=blast_radius and local reviews | |
| GITLAB_PROJECT_ID | No | Default GitLab project (numeric id or group/repo) | |
| SONAR_PROJECT_KEY | No | Sonar project key | |
| AZURE_DEVOPS_TOKEN | No | Azure DevOps PAT with work-item read/write | |
| AZURE_DEVOPS_ORG_URL | No | Azure DevOps organization URL | |
| AZURE_DEVOPS_PROJECT | No | Azure DevOps project name | |
| REVIEW_DOTNET_PROJECT | No | Optional .sln/.csproj for step=checks when it cannot find one on its own |
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 | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| review_workA | request.step is one of: read, read_file, rubric, checks, blast_radius, prepare_comments, view_draft, publish. Review local changes before pushing or a GitLab MR/GitHub PR. Start with step=read; it returns the diff, a per-hunk ledger and the domain rubrics to load. step=rubric returns the full text of a rubric for clients that cannot load skill files. step=checks runs the repository's own compiler and linters over the change; step=blast_radius lists call sites outside the diff. The assistant examines code, explains blockers and suggestions, and can prepare French/English comments. Publishing requires the user to approve the saved draft locally. These steps support one review; they are not separate tools. |
| plan_ticket_tasksA | request.step is one of: read, prepare, view_draft, publish. Turn an Azure Bug/PBI into clear implementation and testing tasks with estimated hours. Start with step=read to understand requirements and existing children. The assistant proposes scope, dependencies, assumptions and total effort; step=prepare saves the plan for approval. Only step=publish creates the approved tasks. |
| review_sonarB | Inspect a PR/MR and its Sonar quality gate, coverage, duplication, issues and hotspots together. The assistant explains failures and, when asked, fixes code using its local editing/testing tools. Supply ruleKey for remediation details or filePath for source context. This tool reads evidence; a new Sonar analysis is needed to confirm a fix. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| review_workflow | Evidence-based bilingual review with ticket verification, Sonar analysis, and explicit human approval |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
review_work and review_sonar both concern reviewing PR/MR code and could be confused at first glance, but their descriptions clearly separate general diff/rubric/checks review from Sonar-specific quality-gate inspection. plan_ticket_tasks is clearly distinct for Azure ticket planning.
All tools use snake_case and follow a verb_noun style: review_work, review_sonar, plan_ticket_tasks. The only minor deviation is plan_ticket_tasks carrying an extra noun, but the convention remains predictable.
Three tools is well-scoped for this server: one for code review workflow, one for Sonar inspection, and one for ticket planning. Each tool aggregates multiple substeps rather than spawning many tiny operations.
The review_work and plan_ticket_tasks tools cover read, prepare, view, and publish stages, giving broad lifecycle support. Minor gaps remain around triggering a fresh Sonar analysis and directly posting review comments/approvals outside the draft workflow.