Skip to main content
Glama
renatomarinho

Codacy MCP Server

codacy_security

Destructive

Manage security findings across repositories: view dashboards, search vulnerabilities, ignore false positives, and assess supply chain risks with SBOM and OSSF Scorecard.

Instructions

Get the security dashboard summary for a repository.. Select operation via the action parameter. Actions: dashboard, ignore, ossf_scorecard, sbom_search, search_org, search_repo

Workflow:

  • 'dashboard': Get the security dashboard summary for a repository.

  • 'ignore': [INSTRUCTIONS] Use when the user explicitly wants to mark a security finding as ignored. Always provide a reason: FalsePositive, WontFix, or NotRelevant. Common mistakes: (1) Do NOT invent reasons. (2) Ignoring without user confirmation — this is a security decision, always confirm. This action is idempotent — calling it twice with the same srmItemId has no additional effect.

Ignore or unignore a security finding.. Requires: srmItemId, reason [DESTRUCTIVE]

  • 'ossf_scorecard': [INSTRUCTIONS] Accepts either a repository URL (e.g., https://github.com/org/repo) or a purl (e.g., maven:ch.qos.logback:logback-classic:1.2.3). At least one is required. Common mistake: not providing either url or purl — the API requires at least one identifier. Use the purl from SBOM search results.

Get the OSSF Scorecard for a repository or package. Returns security posture score.

  • 'sbom_search': [INSTRUCTIONS] Supply chain security investigation — search SBOM dependencies by name, vulnerability severity, or risk category. Common mistakes: (1) Confusing SBOM search with security findings — SBOM shows dependencies, use codacy_security.search_repo for code-level findings. (2) Risk categories: Forbidden, Risky, Normal — do NOT invent categories. Use purl (Package URL) as the universal identifier for cross-referencing with OSSF Scorecard.

Search SBOM dependencies across the organization. Find vulnerable packages by name, severity, or risk category.

  • 'search_org': [INSTRUCTIONS] Cross-repository security overview at the organization level. For repository-specific findings, use codacy_security.search_repo instead. Scan types: SAST, SCA, Secrets, IaC, CICD (repo-level). DAST and PenTesting are organization-level only. Common mistakes: (1) Using this for code quality issues — use codacy_issues instead. (2) Status values: OnTrack, DueSoon, Overdue (open), ClosedOnTime, ClosedLate, Ignored (closed) — do NOT invent statuses.

Search organization-level security findings across all repositories.

  • 'search_repo': [INSTRUCTIONS] Repository-scoped security search. Uses the organization-level API filtered by this repository. Scan types available at repo level: SAST, SCA, Secrets, IaC, CICD. For DAST and PenTesting, use codacy_security.search_org instead. Common mistake: using DAST or PenTesting scan types here — those are organization-level only.

Search security findings within a specific repository. [Cache-Control: no-store]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoRepository URL (e.g., https://github.com/org/repo). For: ossf_scorecard
purlNoPackage URL in purl format (e.g., maven:ch.qos.logback:logback-classic:1.2.3). For: ossf_scorecard
textNoSearch by dependency name or package URL. For: sbom_search
limitNoResults per page (max 100). For: sbom_search, search_org, search_repo
actionYesWhich operation to perform
cursorNoPagination cursor. For: sbom_search, search_org, search_repo
reasonNoReason for ignoring. Required for: ignore
statusNoFilter by status (OnTrack, DueSoon, Overdue, ClosedOnTime, ClosedLate, Ignored). For: search_org, search_repo
commentNoOptional explanation comment. For: ignore
categoryNoFilter by security category (e.g., Injection, XSS, CSRF). For: search_org, search_repo
priorityNoFilter by priority. For: search_org, search_repo
providerNoGit provider. For: dashboard, ignore, sbom_search, search_org, search_repo
scanTypeNoFilter by scan type. For: search_org, search_repo
srmItemIdNoSRM item identifier. Required for: ignore
repositoryNoRepository name. For: dashboard, search_repo
organizationNoOrganization name. For: dashboard, ignore, sbom_search, search_org, search_repo
riskCategoryNoFilter by risk classification. For: sbom_search
findingSeverityNoFilter by vulnerability severity. For: sbom_search
Behavior3/5

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

The description adds useful behavioral context (e.g., idempotency of 'ignore', cache-control for search_repo, destructive nature of ignore). However, it contradicts the annotation 'idempotentHint: false' by stating that the ignore action is idempotent. This reduces reliability.

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

Conciseness4/5

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

The description is well-structured with headers for each action, bullet points, and front-loaded purpose. While lengthy due to the complexity of six actions, it remains organized and avoids unnecessary fluff.

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

Completeness5/5

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

Given the 18 parameters, no output schema, and rich annotations, the description covers all necessary context: action-specific usage, parameter requirements, common mistakes, alternatives, and behavioral notes. It is thorough for a tool of this complexity.

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

Parameters5/5

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

Despite 100% schema coverage, the description enhances parameter understanding by explaining which parameters apply to which actions, providing common mistakes, and clarifying enumerated values (e.g., status values, risk categories).

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

Purpose5/5

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

The description clearly states it provides security dashboard summary and lists six specific actions, each with a clear purpose. It distinguishes itself from sibling tools (codacy_overview, codacy_quality, etc.) by focusing exclusively on security operations.

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

Usage Guidelines5/5

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

The description provides explicit instructions for each action, including when to use alternatives (e.g., using search_org for DAST/PenTesting instead of search_repo) and common mistakes to avoid. It also differentiates from other tools like codacy_issues.

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