DefectDojo MCP Server

list_findings

Retrieve vulnerability findings from DefectDojo using optional filters like severity, status, product, or CVE. Supports targeted searches and audits.

Instructions

List findings with optional filters.

Args: severity: Filter by severity (Critical, High, Medium, Low, Info) active: Filter active findings only verified: Filter verified findings only is_mitigated: Filter mitigated findings duplicate: Filter duplicates false_positive: Filter false positives (false_p) out_of_scope: Filter out-of-scope findings risk_accepted: Filter findings under an active risk acceptance test_id: Filter by test ID engagement_id: Filter by engagement ID (via test__engagement) product_id: Filter by product (asset) ID (via test__engagement__product) product_name: Filter by product (asset) name (server-side contains) title: Filter by title (server-side contains) title_exact: Filter by exact title cwe: Filter by CWE number vulnerability_id: Filter by CVE/vulnerability ID (e.g. CVE-2024-1234) reporter_id: Filter by reporter user ID mitigated_by_id: Filter by the user who mitigated outside_of_sla: Filter findings outside SLA tag: Filter by tag name (contains) ordering: Ordering fields (e.g. "-severity", "created", "-date") limit: Number of results per page (default 25) offset: Pagination offset

Input Schema

TableJSON Schema

Name	Required	Description	Default
`cwe`	No
`tag`	No
`limit`	No
`title`	No
`active`	No
`offset`	No
`test_id`	No
`ordering`	No
`severity`	No
`verified`	No
`duplicate`	No
`product_id`	No
`reporter_id`	No
`title_exact`	No
`is_mitigated`	No
`out_of_scope`	No
`product_name`	No
`engagement_id`	No
`risk_accepted`	No
`false_positive`	No
`outside_of_sla`	No
`mitigated_by_id`	No
`vulnerability_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 11, 2026

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose useful traits such as pagination (limit default 25, offset), server-side 'contains' matching for product_name/title, and that some filters traverse relations ('via test__engagement'). It omits permissions, ordering defaults, or any note on result size/cost.

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?

Front-loaded purpose sentence followed by a clean 'Args:' block where each line maps to one parameter. The length is justified by 23 parameters, though it reads as generated documentation rather than curated guidance.

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?

An output schema exists, so return-value explanation is unnecessary, and all parameters are documented. The main gap is the absence of any guidance about alternatives or interaction with sibling finding tools, but for a filtered list operation the definition is largely sufficient.

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 description coverage is 0%, so the description must compensate, and it does: every one of the 23 parameters gets an explanation, including enum values for severity, relation traversal paths, and exact-vs-contains matching distinctions. This meaningfully exceeds the bare schema.

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?

States a specific verb and resource ('List findings') and clarifies it takes optional filters. However, it does not differentiate from siblings like get_finding, list_finding_metadata, or get_finding_duplicates, so an agent must infer selection from the name alone.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus alternatives (get_finding, list_finding_metadata, get_finding_duplicates). The 'optional filters' phrasing implies a broad listing use case, but neither when-to-use conditions nor exclusions are stated.

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

Deploy Server