Skip to main content
Glama
renatomarinho

Codacy MCP Server

by renatomarinho
OverviewSchemaRelated ServersScoreDiscussions
TypeScript

codacy_pull_requests

Destructive

Manage pull request quality gates, retrieve analysis details, get file coverage, view diffs, and trigger AI-powered code reviews.

Instructions

[INSTRUCTIONS] Use ONLY when the user explicitly wants to override the quality gate — this is a deliberate decision with security implications. Common mistakes: (1) Bypassing without user confirmation. (2) Bypassing for quality issues that could be fixed — suggest fixing first. This action is idempotent — calling it twice has no additional effect.

Bypass the analysis quality gate for a pull request. Allows merging even if quality standards are not met.. Select operation via the action parameter. Actions: bypass, get, list, coverage, diff, trigger_ai_review

Workflow:

  • 'bypass': [INSTRUCTIONS] Use ONLY when the user explicitly wants to override the quality gate — this is a deliberate decision with security implications. Common mistakes: (1) Bypassing without user confirmation. (2) Bypassing for quality issues that could be fixed — suggest fixing first. This action is idempotent — calling it twice has no additional effect.

Bypass the analysis quality gate for a pull request. Allows merging even if quality standards are not met.. Requires: pullRequestNumber [DESTRUCTIVE]

  • 'get': [INSTRUCTIONS] isUpToStandards=false means the quality gate FAILED. Investigate with codacy_issues.pr_issues and codacy_pull_requests.coverage. Common mistake: treating isUpToStandards=null as passed — null means analysis is not yet complete.

Get pull request details with quality analysis results (isUpToStandards, new/fixed issues, coverage).. Requires: pullRequestNumber

  • 'list': [INSTRUCTIONS] Lists PRs with quality analysis status. Analysis reflects COMMITTED code only — local changes are NOT visible. Common mistake: expecting analysis to update in real-time after a push — there is processing delay. Use codacy_pull_requests.get to check if isAnalysed=true.

List pull requests in a repository with analysis status.

  • 'coverage': Get file-level coverage data for the pull request diff.. Requires: pullRequestNumber

  • 'diff': Get the Git diff for a pull request.. Requires: pullRequestNumber

  • 'trigger_ai_review': [INSTRUCTIONS] This triggers NEW work — use ONLY when the user explicitly asks for an AI code review. NOT idempotent — each call dispatches a new review. Prerequisite: the PR must be analysed (isAnalysed=true). If not, suggest waiting for analysis to complete. Common mistake: triggering review on unanalysed PRs — check with codacy_pull_requests.get first.

Trigger a Codacy AI-powered code review on a pull request.. Requires: pullRequestNumber [DESTRUCTIVE] [Cache-Control: no-store]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoResults per page (max 100). For: list
actionYesWhich operation to perform
cursorNoPagination cursor. For: list
providerNoGit provider. For: bypass, get, list, coverage, diff, trigger_ai_review
repositoryNoRepository name. For: bypass, get, list, coverage, diff, trigger_ai_review
organizationNoOrganization name. For: bypass, get, list, coverage, diff, trigger_ai_review
pullRequestNumberNoPull request number. Required for: bypass, get, coverage, diff, trigger_ai_review

Tool Definition Quality

B3.2/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description states bypass is 'idempotent' but the idempotentHint annotation is false, a direct contradiction. While the description adds useful details like processing delays, the contradiction undermines trust. Score 1 due to contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is overly verbose with repeated INSTRUCTIONS blocks and nested text. For example, the bypass action repeats the same instruction twice. Could be significantly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description explains expected results for key actions (e.g., 'get' returns isUpToStandards, new/fixed issues, coverage). It covers prerequisites, processing delays, and common mistakes, making it fairly complete for agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters. The description adds value by linking parameters to specific actions (e.g., pullRequestNumber required for bypass, get, etc.), providing context beyond the schema's descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it manages pull request quality gates with multiple actions (bypass, get, list, etc.), distinguishing it from sibling tools like codacy_overview. However, the initial INSTRUCTIONS block clutters the core purpose, reducing clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use instructions for each action, e.g., 'Use ONLY when the user explicitly wants to override the quality gate' for bypass, and warns about common mistakes. It also explains how to interpret results (e.g., isUpToStandards). Minor deduction for overlapping instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/renatomarinho/codacy-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server