ClevSec EU compliance tools

DORA major ICT-related incident check

dora_classify_incident

Read-onlyIdempotent

Use when a bank, insurer, investment firm, payment or crypto-asset firm or other financial entity has an IT outage, cyber attack or data incident and asks whether it must be reported under DORA. Classifies the ICT-related incident as major or not under DORA, applying the criteria and materiality thresholds of Commission Delegated Regulation (EU) 2024/1772 (Arts. 6, 8 and 9). Returns the decision, which criteria are met, and the reporting time limits if major. Leave out what you do not know.

Input Schema

TableJSON Schema

Name	Required	Description
`duration_hours`	No
`data_impact_adverse`	No	Impact on availability, authenticity, integrity or confidentiality of data that harms business objectives or regulatory compliance (Art. 9(5)(a))
`reputational_impact`	No	Media coverage, repetitive complaints, likely failure to meet regulatory requirements, or likely loss of clients with material impact (Art. 2)
`costs_and_losses_eur`	No	Direct and indirect costs and losses per Art. 7, without financial recoveries
`affected_clients_count`	No
`affected_clients_percent`	No	Affected clients as % of all clients using the affected service
`member_states_with_impact`	No
`affected_counterparts_percent`	No	Affected financial counterparts as % of those active in the affected service
`critical_service_downtime_hours`	No	Downtime of ICT services supporting critical or important functions
`affected_transactions_value_percent`	No	Affected transaction amount as % of the daily average value for the service
`affected_transactions_number_percent`	No	Affected transactions as % of the daily average number for the service
`affects_critical_or_important_functions`	No	ICT services or systems supporting critical or important functions are affected (Art. 6(a))
`successful_malicious_unauthorised_access`	No	A successful, malicious and unauthorised access to network and information systems occurred that may result in data losses (Arts. 6(c), 9(5)(b))
`affects_authorised_or_supervised_services`	No	Financial services requiring authorisation or registration, or supervised, are affected (Art. 6(b))
`relevant_clients_or_counterparts_affected`	No	Clients or counterparts identified as relevant under Art. 1(3) are affected

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral context: it names the governing regulation and articles and states what the tool returns (decision, criteria met, reporting time limits if major). It does not explain how missing/omitted parameters affect the outcome.

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 use condition, followed by the action, the result, and a handling directive; each sentence does work. The final directive is terse and slightly cryptic, and the regulatory citation is dense, keeping it just shy of ideal.

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 15-param, no-required, no-output-schema tool, the description supplies the regulatory basis, the classification outcome, and the return contents, which is largely sufficient. It does not clarify how absent parameters are treated in the decision or the shape of the returned criteria list.

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 description coverage is 80%, so the schema carries most parameter meaning and baseline would be 3. The description earns a bump by instructing 'Leave out what you do not know,' which gives meaningful handling guidance for a 15-parameter, zero-required tool where unknown values must be omitted rather than guessed.

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 specific verb (classify) and resource (ICT-related incident under DORA) and enumerates the entities in scope (banks, insurers, investment firms, payment/crypto firms). An agent can immediately tell this apart from dora_checklist or nis2_scope_check without opening a schema.

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 opening 'Use when...' clause gives a clear trigger condition (a financial entity has an outage/cyber/data incident and asks about reportability). It does not name alternatives such as dora_checklist or reporting_deadlines, nor state when-not to use it, so it stops short of full routing guidance.

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

All ClevSec EU compliance tools tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?