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, pipeline, checkout, checks, blast_radius, tests, prepare_comments, request_approval, approve, revise, 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=pipeline reports the failing CI stages of a remote MR/PR with their cause and file:line. step=checkout puts a remote MR/PR head in a dedicated worktree. step=checks runs the repository's own compiler and linters over the change; step=blast_radius lists call sites outside the diff; step=tests runs the unit tests related to the change. Each returns a runId; prepare_comments requires the first two. The assistant examines code, explains blockers and suggestions, and can prepare French/English comments. Publishing requires the user approval of the saved draft: by default you show its preview and relay their reply with step=approve. These steps support one review; they are not separate tools. |
| plan_ticket_tasksA | request.step is one of: search, read, prepare, request_approval, approve, revise, view_draft, publish. Works with Azure DevOps, Jira and GitHub Issues. Turn a ticket into clear implementation and testing tasks with estimated hours, created under it after approval (Azure child Tasks, Jira sub-tasks, GitHub sub-issues). Use step=search to find tickets: WIQL or a saved query id for Azure, JQL or a filter id for Jira, a search query for GitHub. step=read returns the ticket, its children and discussion. step=prepare saves the plan for approval. |
| review_sonarA | 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 (and lines) for source context. Use review_work read for the diff. 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 |
| address-threads | Pull the open review threads of an MR/PR, check each one against the code, and write a ready-to-paste prompt for an agent to address them. |
| explain-ticket | Extract the knowledge behind a ticket: what is asked, why, where it lives in the code, and what is still unclear. |
| fix-pipeline | Explain the failing CI stages of an MR/PR, find the cause in the code, and propose or apply the fix. |
| fix-sonar | Read the Sonar quality gate and issues of an MR/PR, explain them, and fix them in the local checkout after agreement. |
| plan-ticket | Turn an Azure DevOps, Jira or GitHub ticket into estimated implementation and test tasks, created after approval. |
| qa-ticket | Build a test plan from a ticket's acceptance criteria and run it against the app running locally. |
| review-local | Self-review of the local branch or working tree against a base, nothing posted. |
| review-mr | Senior review of a GitLab MR or GitHub PR, with pipeline, rubrics, evidence and approval in the chat. |
| work-ticket | Read a ticket and its acceptance criteria, name the branch and the conversation after it, then write a prompt for a coding agent or implement it to review-ready quality, and finish with a detailed PR description. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
The three tools target mostly distinct domains: review_work handles general code review workflow, plan_ticket_tasks handles ticket decomposition, and review_sonar handles Sonar evidence. However, review_work and review_sonar both operate on PR/MR quality assessment, so an agent may be unsure which to call first without reading the descriptions carefully.
All names use snake_case, but the verb+object pattern is inconsistent: review_work and review_sonar share a 'review_' prefix, while plan_ticket_tasks uses 'plan_' with a three-word noun phrase. 'work' is also a vague noun compared to 'sonar', making the naming less predictable.
Three tools roughly map to the server's three apparent domains, which is reasonable. However, review_work alone packs thirteen distinct step operations into one tool, suggesting the surface is slightly under-factored and could benefit from narrower tools.
review_work provides an end-to-end lifecycle from diff reading to publishing comments, plan_ticket_tasks covers ticket search through approval and creation, and review_sonar covers Sonar evidence. Minor gaps exist, such as no explicit tool for updating existing tickets or merging MRs, but agents can work around them within the stated review scope.