qrp-mcp

Overview Schema Source Related Servers Discussions Admin

export_cbom

Read-onlyIdempotent

Export a directory scan as a CycloneDX 1.6 CBOM with coverage details, ready for auditors, customers, or pipeline artifacts.

Instructions

Scan one directory and return a CycloneDX 1.6 CBOM that carries its own coverage.

Same reading as scan_repo; a different document. Use this when the result has to leave the machine -- an auditor, a customer, a pipeline artefact -- and scan_repo when a person or an agent is going to read it here.

What the document carries beyond the components: compositions.aggregate states how complete the list is in the schema's own vocabulary, complete only when every file present was examined; properties carries the whole coverage block flattened, including every file not examined with its reason; and each asset carries evidence.occurrences with file, line and matched text.

The coverage block travels as properties because the CycloneDX root object is additionalProperties: false and the format has no field for it. That is the point of emitting it this way rather than a limitation to work around.

The serial number is derived from the target, the two pins and a digest of the findings, so two runs of the same code over the same corpus that find the same things share it and a different result does not. The timestamp and coverage window record when each run happened.

The matched text in evidence.occurrences is masked by default, for the reason given on scan_repo and one more: this document is the one built to be sent. An auditor needs the algorithm, the file and the line; the contents of the line are not part of the claim being made.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`path`	Yes	Directory to scan and export, same argument as `scan_repo`.
`level`	No	How much of each matched line to carry in `evidence.occurrences`. Same three levels and the same default as `scan_repo`.	masked

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.17.0Sep 22, 2026

addedInput schema / properties / level

Added value: +{
+  "default": "masked",
+  "description": "How much of each matched line to carry in `evidence.occurrences`. Same three levels and the same default as `scan_repo`.",
+  "enum": [
+    "full",
+    "masked",
+    "trimmed"
+  ],
+  "title": "Level",
+  "type": "string"
+}

Addedv0.7.0Sep 11, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark the tool read-only and idempotent, and the description adds substantial behavioral detail: how coverage is represented in `compositions.aggregate` and `properties`, how serial numbers are deterministically derived, why the coverage block travels as `properties`, and that matched text is masked by default. Nothing contradicts the annotations.

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?

The description is long but every paragraph earns its place: purpose, usage routing, document contents, format rationale, determinism, and masking policy. It is front-loaded with the core purpose and then layers detail in a logical order with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a rich output document, an output schema, and annotations covering safety/idempotence, the description is complete: it explains what the document carries, why it is structured that way, when to choose this tool over `scan_repo`, and the masking default. An agent has everything needed to select and invoke it correctly.

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?

Input schema coverage is 100%, so the schema already documents `path` and `level` fully. The description adds helpful cross-references to `scan_repo`'s semantics and notes the default level, but it does not significantly extend what the schema already provides.

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?

The opening sentence names a specific verb ('Scan'), a specific resource ('one directory'), and a precise output ('CycloneDX 1.6 CBOM'). It explicitly contrasts itself with `scan_repo` ('Same reading... a different document'), so an agent can distinguish this tool from its closest sibling without needing to inspect schemas.

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?

The description gives explicit selection criteria: use this when the result must leave the machine (auditor, customer, pipeline artefact) and use `scan_repo` when a person or agent will read it here. This is direct, unambiguous routing guidance with the named alternative.

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

Deploy Server