Skip to main content
Glama

ClevSec EU compliance tools

Cyber Resilience Act: must the manufacturer report?

cra_reporting_check
Read-onlyIdempotent

Use when a manufacturer of hardware or software sold in the EU learns of an actively exploited vulnerability or a security incident in its product. Applies Art. 14 of the Cyber Resilience Act (Regulation (EU) 2024/2847), in force since 11 September 2026: whether a report is due, the 24-hour, 72-hour and final report deadlines, where to report, and informing users.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
eventYesactively_exploited_vulnerability: reliable evidence that a malicious actor exploited it; severe_incident: an incident affecting the product's security
malicious_codeNoSevere incident test, Art. 14(5)(b): it led or can lead to malicious code in the product or in users' systems
is_manufacturerNoDevelops or manufactures the product, or has it designed or made, and markets it under its own name or trademark
product_with_digital_elementsNoSoftware or hardware product (and its remote data processing) made available in the EU whose intended or foreseeable use includes a data connection to a device or network (Arts. 2(1), 3(1)); some products under sector laws, such as medical devices and vehicles, are excluded (Art. 2(2)-(4))
affects_data_or_functions_protectionNoSevere incident test, Art. 14(5)(a): it harms or can harm the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare this a read-only, idempotent, closed-world check, so the safety profile is covered. The description adds meaningful context beyond that: the operative legal article, its entry-into-force date (11 September 2026), and the substance of what the assessment returns (report due, deadlines, reporting channel, user notification), which is valuable given no output schema exists.

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?

Two tightly written sentences: the first front-loads the activation condition, the second enumerates the scope of the answer. No redundant restatement of the name or title.

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 five-parameter decision tool with no output schema, the description conveys the trigger, the legal basis, and the shape of the result, and the annotations cover safety semantics. Minor gap: no note on how the March 2026/September 2026 phase-in or transitional dates affect applicability.

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% and the enum values plus the boolean tests are documented in detail with statutory citations (Art. 14(5)(a)/(b), Arts. 2(1), 3(1), 2(2)-(4)). The description adds nothing beyond what the schema already provides, 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?

The description names a specific regulatory assessment (Art. 14 CRA, Regulation (EU) 2024/2847) and enumerates exactly what the tool answers: whether a report is due, the 24/72-hour and final deadlines, where to report, and user notification. It is unambiguously distinguishable from the GDPR, NIS2 and DORA siblings by regulation and legal basis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The trigger is explicit: use when a manufacturer of EU-sold hardware/software learns of an actively exploited vulnerability or security incident. It does not, however, disambiguate against the overlapping sibling 'reporting_deadlines', so the agent must infer which deadline tool to prefer.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources