DefectDojo MCP Server

reimport_scan

Update an existing DefectDojo test by reimporting new scan results, with options to close old findings and match tests by ID or product context.

Instructions

Reimport a scan report (update existing test with new results).

Either test_id OR (product_name + test_title + auto_create_context) must be provided. Either file_path or scan_data must be provided.

Args: scan_type: Scanner type (e.g., "ZAP Scan", "Nessus Scan", "SARIF", etc.) test_id: Existing test ID to reimport into file_path: Path to the scan results file scan_data: Raw scan data as string product_name: Product name (for auto-create context) product_type_name: Product type name (for auto-create context) engagement_name: Engagement name (for auto-create context) test_title: Test title (for matching existing test) auto_create_context: Auto-create context if it doesn't exist active: Mark findings as active verified: Mark findings as verified close_old_findings: Close findings not in new scan (default True) close_old_findings_product_scope: Close at product scope push_to_jira: Push to JIRA minimum_severity: Minimum severity do_not_reactivate: Don't reactivate closed findings environment: Environment name version: Version being scanned build_id: Build ID branch_tag: Branch or tag commit_hash: Commit hash service: Service name group_by: Group findings by field tags: Tags to apply

Input Schema

TableJSON Schema

Name	Required	Default
`tags`	No
`active`	No
`service`	No
`test_id`	No
`version`	No
`build_id`	No
`group_by`	No
`verified`	No
`file_path`	No
`scan_data`	No
`scan_type`	Yes
`branch_tag`	No
`test_title`	No
`commit_hash`	No
`environment`	No
`product_name`	No
`push_to_jira`	No
`engagement_name`	No
`minimum_severity`	No	Info
`do_not_reactivate`	No
`product_type_name`	No
`close_old_findings`	No
`auto_create_context`	No
`close_old_findings_product_scope`	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

A4/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 burden. It usefully discloses the destructive side effect that close_old_findings (default True) closes findings absent from the new scan, and do_not_reactivate's effect. But it omits any mention of auth/permission requirements, whether reimport runs asynchronously, or how failures are surfaced, leaving material behavior undisclosed.

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

Conciseness5/5

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

Well front-loaded: purpose first, then the two either/or requirements, then the argument list. Given 24 undocumented parameters, the arg list earns its place rather than padding, and there is no redundant prose.

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?

For a 24-parameter mutation tool with no annotations and an existing output schema, the description covers the calling requirements and all parameters. It is close to complete; only permission requirements and asynchronous/processing behavior are missing, which are minor given the output schema answers the return-value question.

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% across 24 parameters, so the description must compensate, and it does gloss every parameter with a short meaning. Gaps remain for some (e.g. 'Minimum severity' gives no allowed values, 'group_by'/'tags' give no format), so it improves on the bare schema without being fully self-sufficient.

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?

States a specific verb (reimport) and resource (scan report) and immediately clarifies the semantic with '(update existing test with new results)', which cleanly distinguishes it from the sibling import_scan that creates new tests. An agent can select between them without opening either schema.

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

Usage Guidelines3/5

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

The description gives the mutual-exclusivity constraints ('Either test_id OR product_name + test_title + auto_create_context'; 'Either file_path or scan_data'), which is genuine usage guidance. However, it never states when to prefer reimport_scan over import_scan or what prerequisites/permissions the caller needs. Usage is implied by the constraints rather than explicit.

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

Deploy Server