DefectDojo MCP Server

accept_risk

Accept the risk of findings with a mandatory expiration date, automatically reactivating them upon expiry.

Instructions

Accept the risk of one or more findings (risk acceptance with mandatory expiration date).

Creates a RiskAcceptance object. The expiration date is MANDATORY: findings are reactivated automatically when it passes (unless reactivate_expired=False). Risk acceptance is discouraged in favor of fixing; always require an explicit business justification and a named approver.

Args: finding_ids: List of finding IDs to accept accepted_by: Name/email of the person accepting the risk justification: Business justification for accepting expiration_date: Mandatory expiration (ISO date "YYYY-MM-DD" or full ISO datetime). Must be in the future. decision: Risk treatment by risk owner: A=Accept, V=Avoid, M=Mitigate, F=Fix, T=Transfer decision_details: Details of the decision / compensating controls recommendation: Security team recommendation: A=Accept, V=Avoid, M=Mitigate, F=Fix, T=Transfer recommendation_details: Details of the recommendation reactivate_expired: Reactivate findings when the acceptance expires (default True) restart_sla_expired: Restart SLA when the acceptance expires (default False) owner_id: Owner user ID (defaults to the authenticated user) name: Acceptance name (defaults to "Risk acceptance ( findings)")

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No
`decision`	No
`owner_id`	No
`accepted_by`	Yes
`finding_ids`	Yes
`justification`	Yes
`recommendation`	No
`expiration_date`	Yes
`decision_details`	No
`reactivate_expired`	No
`restart_sla_expired`	No
`recommendation_details`	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

Behavior4/5

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

With no annotations, the description carries the burden well: it discloses that expiration is mandatory, that findings reactivate automatically on expiry unless reactivate_expired=False, and that an explicit justification and named approver are required. It stops short of stating permission/auth requirements, keeping it from a 5.

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-loads the critical constraint (mandatory expiration) in the opening line. The Args block is long but justified given zero schema coverage; only minor redundancy between the prose and the parameter list.

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 12-parameter mutation tool with no annotations but an existing output schema, the description supplies the missing behavioral and parameter context. It does not explain side effects on related findings beyond expiration or the risk of creating duplicates, leaving a small gap.

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?

Schema coverage is 0%, and the description fully compensates: it documents all 12 parameters, decodes the decision/recommendation enum letters (A/V/M/F/T), specifies the ISO date format and future-date constraint for expiration_date, and lists defaults for reactivate_expired, restart_sla_expired, owner_id, and name.

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 ('Accept the risk of one or more findings', 'Creates a RiskAcceptance object') with a scope detail. Clear on its own, but it never distinguishes itself from close siblings like create_risk_acceptance or accept_risks_vulnerability, so the agent must infer the boundary.

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?

It offers one directional cue ('Risk acceptance is discouraged in favor of fixing'), which implies the preferred alternative is remediation. However, it names no concrete sibling tool to use instead and gives no conditions for choosing this over close_finding_mitigated or create_risk_acceptance.

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

Deploy Server