Draugr

Official

Overview Schema Source Related Servers Discussions Admin

fix_list

Convert a Draugr SARIF report into prioritized remediation actions, ordered by urgency, with each action showing how many findings it resolves.

Instructions

Turn a report into the things to do about it, most urgent first, each saying how many findings it clears. Ask this rather than summarize_report when the question is what to change: one upgrade usually clears many findings, and an image somebody else publishes is one action however many packages are wrong inside it.

Input Schema

Name	Required	Description	Default
`path`	Yes	path to a results.sarif produced by draugr scan
`limit`	No	maximum actions to return; defaults to 20

Output Schema

Name	Required	Description
`note`	No
`clears`	Yes	findings the returned actions clear between them, each counted once
`actions`	Yes	things to do, most urgent first; each says how many findings it clears
`totalClears`	Yes	findings every action clears between them, each counted once
`totalActions`	Yes	actions the report implies, returned or not

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 25, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses result ordering (most urgent first), that each action reports its finding count, and a real deduplication rule (a externally published image is one action no matter how many packages inside it are wrong). It omits failure behavior for a bad or non-SARIF path, but the return shape is covered by the output schema.

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?

Two sentences, no filler, with the core transformation front-loaded before the sibling comparison. The phrase 'the things to do about it' is slightly indirect where 'actions' or 'fixes' would be sharper, but nothing is wasted.

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 two-parameter read tool with a full output schema and full parameter documentation, the description covers the remaining cognitive gap: what the output is for, how it is ordered, and how it differs from its nearest sibling. Only the input-failure/precondition story is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both `path` (a results.sarif from draugr scan) and `limit` (default 20) are already documented. The description adds no syntax, format, or truncation detail beyond 'a report', so the baseline 3 applies.

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 concrete transformation: a report becomes an ordered list of actions, most urgent first, each annotated with how many findings it clears. That is specific enough to separate it from summarize_report and from diff_reports without opening any schema.

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 names the alternative ('Ask this rather than summarize_report') and states the selecting condition ('when the question is what to change'). It even explains why the two diverge — one upgrade clears many findings — so the routing decision is unambiguous.

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

Deploy Server