Draugr

Official

Overview Schema Source Related Servers Discussions Admin

summarize_report

Reads an existing Draugr scan's results.sarif and returns prioritized, deduplicated findings with rule docs plus accepted decisions, so you can see what to fix first without rerunning.

Instructions

Read the results.sarif an earlier draugr scan wrote and return its findings ranked by priority, deduplicated, with the rule documentation link for each. Answers 'what should I fix first?' from a scan that already ran, without starting a new one. A finding the project accepted comes back in accepted, with who decided, why and until when; report it as a decision and do not propose fixing it. It covers the controls that scan ran and nothing else, so treat it as a floor to build on rather than a complete account of a codebase's security. Given a report.json, read the results.sarif in the same directory, since report.json holds the verdict and the fix list and names each finding only by its fingerprint.

Input Schema

Name	Required	Description
`path`	Yes	path to the results.sarif draugr scan wrote; report.json beside it holds the verdict and the fix list, and names each finding only by its fingerprint
`limit`	No	maximum findings to return; defaults to 20
`minPriority`	No	only return findings at this priority or above: p1, p2, p3 or p4

Output Schema

Name	Required	Description
`next`	Yes	what to do with this result
`note`	No
`feeds`	No	exploitability datasets the scan consulted; absent means no finding was checked against KEV or EPSS
`total`	Yes	findings the report judged, before any priority filter; excludes suppressed
`counts`	Yes
`accepted`	No	the suppressed findings with who decided and why, most severe first, capped at limit; report each as a decision, never as work to fix
`findings`	Yes
`returned`	Yes
`suppressed`	No	findings a recorded decision took out of the ranking; not part of total

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 25, 2026

TDQS

A4.5/5.0

Behavior4/5

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

No annotations, so the description carries the burden and does well: it discloses that accepted findings return with decider/reason/expiry, that scope is limited to controls the scan ran ('a floor, not a complete account'), and the report.json/results.sarif relationship. It doesn't discuss permissions or limits, but those are low-relevance here. Output schema exists, so return-shape disclosure is adequate.

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 with the core action and result, then caveats. Dense but nearly every sentence earns its place; the report.json guidance at the end is slightly repetitive with the schema but still functional.

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?

Read-only summarization tool with an output schema and 100% param coverage, so return values needn't be explained. It covers scope limitations and accepted-finding handling thoroughly. Minor gap: no explicit note on ordering when priorities tie or on dedup semantics, but not essential.

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 coverage is 100% (baseline 3), and the description adds real value by explaining the workflow: given report.json, read results.sarif in the same directory because report.json only fingerprints findings. That resolves a likely agent confusion beyond what the schema states.

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?

Specific verb+resource: reads results.sarif from an earlier draugr scan and returns prioritized, deduplicated findings with doc links. It is clearly distinguished from scan (no new scan started) and implies a distinct role vs diff_reports/fix_list.

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?

Explicitly frames when to use it ('what should I fix first?' from a scan that already ran) and when not (without starting a new one). It also gives handling guidance for accepted findings — report as a decision, don't propose fixing — which is rare actionable guidance.

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

Deploy Server