Provides read-only access to an OWASP DefectDojo Community Edition instance's REST API v2, letting an assistant list products and their finding counts, retrieve critical or severity-filtered actionable findings, group the same vulnerability (by CVE, else CWE+title) across all products by blast radius, list duplicate findings, and fetch full details and DefectDojo URLs for individual findings — enough to draft a single tracker issue per vulnerability.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DefectDojo MCP Server list critical findings for the Payments API and group them by vulnerability"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A read-only Model Context Protocol server for DefectDojo Community Edition — so an AI assistant can read your vulnerability findings, group the same vulnerability across every product, and draft issues for whatever tracker you use.
Unofficial. This is an independent open-source project. It is not affiliated with, endorsed by, or supported by DefectDojo Inc. or OWASP. "DefectDojo" is used only to describe what this server connects to.
If you run DefectDojo Pro, you probably don't. Pro has a built-in MCP server — use that instead; it is maintained by the vendor and more capable.
DefectDojo Pro (built-in) | This project | |
Edition | Pro only — AI features are Pro-only | Community Edition (works with Pro too) |
Requires | DefectDojo v2.51.2+, enabled by a superuser | Any version with API v2 |
Runs | Inside your instance, at | On your machine, as a local MCP process |
Transport | Streamable HTTP | stdio |
Tools | 18 in the read-only | 7 |
Writes | None in | Never — see Safety model |
This project exists because Community Edition has no MCP server at all. It talks to the ordinary REST API v2 with a normal API token, so it needs nothing enabled server-side and no particular DefectDojo version.
Not to be confused with the unrelated
defectdojo-mcppackage on PyPI, which is a different third-party project. This one isdefectdojo-community-mcp.
Related MCP server: MCP Vulnerability Checker Server
Tool | What it does |
| Verify connectivity and auth; returns the instance URL and product count |
| Every product, with its findings count |
| Actionable criticals, optionally scoped to one product |
| The same, for any severity |
| The useful one. Groups criticals across all products by CVE (else CWE+title), widest blast radius first |
| Findings DefectDojo marked as duplicates |
| Full detail for one finding |
"Actionable" means active and not false-positive, duplicate, risk-accepted,
out-of-scope or mitigated — the set actually worth someone's time.
group_critical_by_vuln is the reason this exists. A monorepo-shaped scanner
setup reports the same upstream CVE once per product; this collapses them into one
group per vulnerability listing every affected product, which maps cleanly onto one
tracker issue.
Requires Python 3.10+.
pip install defectdojo-community-mcpOr from source:
git clone https://github.com/systechgd/defectdojo-community-mcp.git
cd defectdojo-community-mcp
pip install -e .Two environment variables are required.
Variable | Required | Default | Notes |
| yes | — | Base URL, e.g. |
| yes | — | API v2 token. See below for scoping it down. |
| no |
|
|
| no |
| Per-request HTTP timeout. |
Get a token from DefectDojo → your user → API v2 Key.
Create a dedicated read-only user for it. The token inherits that user's permissions, and nothing in this server needs write access. If the token leaks, a read-only one cannot be used to alter your findings.
Check it works before wiring up a client:
defectdojo-community-mcp --check
# ok: https://defectdojo.example.com reachable, 23 product(s) visibleclaude mcp add defectdojo \
--env DEFECTDOJO_URL=https://defectdojo.example.com \
--env DEFECTDOJO_API_KEY=your-token \
-- defectdojo-community-mcp{
"mcpServers": {
"defectdojo": {
"command": "defectdojo-community-mcp",
"env": {
"DEFECTDOJO_URL": "https://defectdojo.example.com",
"DEFECTDOJO_API_KEY": "your-token"
}
}
}
}If the console script is not on your PATH, use
"command": "python", "args": ["-m", "defectdojo_community_mcp"].
The server speaks MCP over stdio, so run it attached (-i), not detached:
{
"mcpServers": {
"defectdojo": {
"command": "docker",
"args": [
"run", "--rm", "-i",
"-e", "DEFECTDOJO_URL",
"-e", "DEFECTDOJO_API_KEY",
"ghcr.io/systechgd/defectdojo-community-mcp:latest"
]
}
}
}Group every critical finding by vulnerability and show me the ones affecting more than three services.
The assistant calls group_critical_by_vuln and gets back, per vulnerability, the
CVE, title, affected product list and a direct DefectDojo URL per finding — enough
to write one issue covering all of them, instead of twelve near-identical ones.
Read-only is a design invariant, not a default.
No tool issues a POST, PUT, PATCH or DELETE.
The HTTP client class exposes no method capable of doing so, so a mutating tool cannot be added by accident — only by deliberately changing that class.
A test asserts that every request made by every tool is a GET.
Adding write support would be a breaking change to this guarantee. If it ever happens it will be a separate server, so operators can keep granting read without granting write.
Findings data is attacker-influenced — scanner output can contain text from dependency metadata, file paths and commit messages. Treat tool results as data, never as instructions. See SECURITY.md for the full threat model and how to report a vulnerability.
git clone https://github.com/systechgd/defectdojo-community-mcp.git
cd defectdojo-community-mcp
python -m venv .venv && . .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -e ".[dev]"
pytest # 57 tests, no network or live instance needed
ruff check .The test suite runs entirely against httpx.MockTransport. CI additionally runs the
suite on Python 3.10–3.13 and against both MCP SDK generations (mcp<2, which has
FastMCP, and mcp>=2, which renamed it to MCPServer).
See CONTRIBUTING.md and CODE_OF_CONDUCT.md.
Apache-2.0. See NOTICE.
Full detail for one finding: description, mitigation, references, CWE/CVE and location.
| Name | Required | Description | Default |
|---|---|---|---|
| finding_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose the shape of the returned payload, which is useful. It does not state that this is a read-only lookup, whether it errors or returns empty for a missing ID, or any auth/permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler; the returned-field list is compact and readable. It is a fragment rather than a sentence, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup with no output schema, enumerating the returned fields does much of the work an output schema would do. The main omission is how to obtain a valid finding_id, which matters because this is presumably a second-step tool after a listing call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the single parameter finding_id is completely undescribed in both schema and text. The description implies a per-finding lookup but never says where the ID comes from (e.g., a preceding list_findings call) or what format it takes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Full detail for one finding') and enumerates what the detail contains (description, mitigation, references, CWE/CVE, location). This implicitly separates it from the list_*/group_* siblings, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The natural workflow (call a list tool, then call this for one item's full record) is only implied, and there is no warning about what happens with an invalid or unknown finding_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Group actionable CRITICAL findings across every product by unique vulnerability.
Keyed on CVE where present, else CWE plus title. Useful for filing one tracker issue per vulnerability that lists every affected product. Widest blast radius first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers meaningful behavior: the grouping key rule ('Keyed on CVE where present, else CWE plus title'), the scope ('across every product'), the filter ('actionable CRITICAL'), and the ordering ('Widest blast radius first'). It does not explicitly state read-only/non-mutating semantics or whether results are truncated, which are the remaining gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each carrying distinct information: grouping scope, key derivation, intended use, and result ordering. The core action and scope are front-loaded, with no redundant restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter aggregation tool with an output schema covering return structure, the description supplies what matters: grouping key logic, actionability filter, and ordering. Minor ambiguities remain, such as what qualifies as 'actionable' and whether products appear once or per finding, but these are narrow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the 100% schema coverage leaves nothing to compensate for. The description adds no parameter meaning because none exists to add, which is the appropriate baseline for a zero-arg tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Group actionable CRITICAL findings across every product by unique vulnerability.' This distinguishes it semantically from siblings like list_critical_findings and list_findings_by_severity, which enumerate rather than aggregate. It stops short of naming those siblings explicitly, so an agent must infer the contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
A concrete use case is given: 'Useful for filing one tracker issue per vulnerability that lists every affected product,' which tells an agent when this aggregation is preferable to a flat listing. It does not state exclusions or negative conditions (e.g., when to use list_duplicate_findings instead), keeping it short of a full when/when-not guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify connectivity and auth to DefectDojo. Returns the instance URL and product count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly conveys that this is a non-mutating probe and names the returned fields, but it is silent on failure behavior (throws vs. returns a falsy/negative status), whether it consumes a request against rate limits, and what auth form is expected — meaningful gaps for a connectivity/auth test whose whole purpose is the failure path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the action first and the return value second; nothing is redundant and there is no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic with no output schema, this is close to sufficient: it says what is checked and what is returned. The missing piece is how a failed check is surfaced, which an agent needs in order to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain; the baseline of 4 applies. The description makes clear that no input is needed by framing it as a pure probe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Verify connectivity and auth to DefectDojo', and adds the concrete return payload (instance URL, product count). This is clearly distinguishable from all siblings, which fetch findings or product lists rather than probing the instance itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the nature of a health check; the description never says when to prefer it, e.g. before a batch of calls, or after a credentials change, nor that it should not be used to retrieve product data (list_products covers that). No explicit when/when-not guidance or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List actionable CRITICAL findings (active, not false-positive/risk-accepted/mitigated).
Optionally scope to one product. Set include_duplicates=True to also see duplicates.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | ||
| include_duplicates | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden, and it does disclose meaningful behavior: the result set is restricted to active findings and excludes three non-actionable statuses. It still omits read-only confirmation, result ordering, pagination/limits, and whether counts or truncation apply to large result sets, which matters for an unbounded list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the result-set definition front-loaded and parameter guidance after it. Nothing is redundant and every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-shape explanation is not required, and the filter semantics are well covered. For a two-parameter filtered list tool, though, missing ordering, pagination, and product identifier format leaves gaps an agent could stumble on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 address both parameters — product scoping and the include_duplicates toggle with its default-false behavior implied. It falls short on how product is identified (name vs. ID/slug), which is the main ambiguity an agent would hit when calling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ("List actionable CRITICAL findings") and defines the filter precisely by enumerating excluded statuses (false-positive/risk-accepted/mitigated). It is clear on its own, but never distinguishes itself from siblings like list_findings_by_severity or list_duplicate_findings, leaving the agent to 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives operational hints (scope to one product, set include_duplicates=True for duplicates), which is useful when-configuration. However it offers no when-to-use-vs-alternative guidance despite three closely related sibling tools, and no note that this is the narrowed 'critical only' view versus the severity-parameterized sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List findings DefectDojo has marked as duplicates, optionally scoped to one product.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It discloses only the read-like listing behavior and the optional product scoping; nothing is said about pagination, result limits, required permissions, or what happens when the product is unknown. An output schema exists, which relieves it of explaining return values, but the remaining gaps are material for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the resource stated first and the optional scoping clause attached. No filler and nothing redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, single-optional-parameter list tool with an output schema and no nested objects, the description covers the essential purpose and scoping. The unresolved identifier format for 'product' is the only meaningful shortfall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% – the single 'product' parameter has no description and is typed as a plain string. The description only says it scopes to one product, without indicating whether the value is an ID, name, slug, or host, so it does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('findings DefectDojo has marked as duplicates'), with the duplicate qualifier implicitly separating it from severity-based siblings like list_critical_findings and list_findings_by_severity. It does not explicitly name a sibling as an alternative, so it falls short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'optionally scoped to one product' implies when the parameter is relevant, but there is no explicit when-to-use guidance, no when-not-to-use, and no pointer to a sibling such as list_findings_by_severity for non-duplicate queries. Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List actionable findings of a given severity (Critical, High, Medium, Low or Info).
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | ||
| severity | Yes | ||
| include_duplicates | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. The word 'actionable' hints at a filtering behavior but is never defined, and nothing is said about pagination, result size, permission requirements, or what 'actionable' excludes -- a meaningful omission for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, and the severity vocabulary is placed inline where it is most useful. It is efficiently sized, though brevity here comes partly from omission rather than discipline.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, which relieves some burden. Still, for a three-parameter tool with zero annotation and zero schema-description coverage, the description leaves the optional filters and the 'actionable' qualifier unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across three parameters. The description usefully enumerates severity values that the schema does not constrain with an enum, but 'product' and 'include_duplicates' remain entirely undocumented in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List actionable findings') plus the scoping dimension ('of a given severity') and enumerates the accepted severity values. An agent immediately knows the operation, though it does not explicitly distinguish this from the overlapping sibling list_critical_findings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is given, and no alternatives are named despite list_critical_findings covering an overlapping case (Critical severity). The agent must infer routing on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all DefectDojo products (each product is typically one repo or service).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'List all' does convey a read-only, unfiltered enumeration, which is useful context, but it says nothing about result size, pagination, ordering, or permission requirements for a tool that could return a large set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero filler. The parenthetical clarification earns its place by explaining a domain term the agent would otherwise have to guess at.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only, zero-parameter list tool and an output schema exists, so return values need not be explained. The only real gap is the absence of pagination or result-size expectations, which is minor 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no per-argument meaning for the description to add. The baseline for a parameterless tool applies, and the parenthetical about what a product represents adds useful contextual meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List all DefectDojo products') and adds domain meaning with the clarification that each product is typically one repo or service. It does not explicitly name a sibling tool to contrast against, but the resource is clearly distinct from the findings-oriented siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, and no alternative tools are named. The phrase 'all' implicitly signals an unfiltered full enumeration, but the agent must still infer whether filtering or pagination requires a different call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_findinggroup_critical_by_vulnhealth_checklist_critical_findingslist_duplicate_findingslist_findings_by_severitylist_productsScored across 7 tools
Several tools overlap around finding listing: list_critical_findings is essentially a specialized case of list_findings_by_severity for Critical severity, and it also has an include_duplicates option that overlaps with list_duplicate_findings. Descriptions clarify intent somewhat, but an agent could reasonably hesitate between these tools when triaging critical or duplicate findings.
Most tools follow a clear snake_case verb_noun pattern, especially the list_* and get_* tools. Minor deviations like group_critical_by_vuln using an abbreviation and health_check being a noun-like operation keep it from being fully uniform, but the convention is still predictable.
Seven tools is well-scoped for a focused DefectDojo MCP server, with each tool earning its place in a read-only triage workflow. The set is neither thin nor bloated.
The surface covers critical/severity/duplicate finding listing, grouping, detail, products, and health, which supports core triage. However, it lacks a general findings query with product plus severity filters, product detail, and any update/mitigation workflow, creating notable gaps for agents that need more than high-level read-only inspection.
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
ZEN SecDB MCP server for CVE intelligence, CVSS/EPSS scoring, advisories, SSVC, and package audits.
