ClevSec EU compliance tools

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds real behavioral content by disclosing the filtering rule: requirements DORA itself disapplies for microenterprises or the Art. 16 simplified framework are omitted. It does not state whether the checklist is exhaustive or versioned against an amendment date, but the filtering disclosure is a meaningful addition.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first front-loads the invocation triggers, the second delivers the output shape and the exclusion rule. No filler, no repetition of the title, and it ends on the constraint an agent would otherwise have to discover empirically.

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

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

With no output schema, the description still characterizes the return value (core requirements grouped by section, each with its article) and explains the one behavioral wrinkle (conditional exclusions). Both parameters are optional, both are documented, and the annotations cover the safety profile, so nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining the consequence of each flag — the two booleans cause disapplied requirements to be left out of the result, not merely labeled. That param-to-output linkage is genuine meaning beyond the schema's per-field prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Returns the core DORA (Regulation (EU) 2022/2554) requirements for financial entities' — and specifies the granularity (grouped by section, with the governing article). This is clearly distinguishable from sibling checks like nis2_gap_assessment or cra_reporting_check, which target different regimes.

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

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

Explicit triggers are given: 'what does DORA require?', DORA compliance checklists, or gap reviews. However, no when-not guidance is offered even though nis2_gap_assessment and dora_classify_incident sit in the same compliance-advice family and could be confused with a 'gap review' request.

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

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.

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.

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.

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.

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.

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.

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

Annotations only tell the agent this is a safe, idempotent read, so the description must carry the substance, and it does: it discloses the two decision branches (authority + affected people) and that exceptions are applied. It does not explain the verdict/output shape, keeping it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the trigger and then the decision and required input. The parenthetical breach-type list is slightly long but adds recognition value rather than filler, so it earns its place.

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

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

For a no-output-schema decision tool, the description supplies the regulatory framing, the required input, and the exceptions it applies, which is enough to call it correctly. It could do more to distinguish itself from the overlapping reporting_deadlines sibling, which keeps it from a 5.

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

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

Schema description coverage is 100% and every parameter (including the nuanced risk, role, and exception booleans) is fully documented in the schema. The description only restates the risk enum values, adding no syntax or interpretation 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.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific decision verb (decide whether to notify) and the exact resource (a personal data breach), naming Art. 33 supervisory-authority notification and Art. 34 data-subject notification. This clearly separates it from siblings like gdpr_fine_estimate and reporting_deadlines.

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

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

The opening trigger condition ('Use when a personal data breach has happened') with concrete examples is explicit and actionable. It gives strong when-to-use context, but never names alternatives or exclusions (e.g. how it relates to reporting_deadlines for the 72h clock), so it stops short of a 5.

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

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

Annotations already establish readOnly/idempotent/non-destructive, so the description only needs to add what they cannot. It does so usefully: 'Returns a starting range in EUR, not a prediction of a real fine' sets output expectations and guards against over-reliance, and the 'step 2' scoping signals the method's boundary. No rate limits or auth caveats, but none are relevant for a closed-world calculator.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Roughly four sentences, front-loaded with the trigger question and immediately followed by the method, inputs, and output caveat. Every sentence contributes, though the two quoted trigger phrasings are somewhat redundant with each other and could be compressed into one.

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

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

For an 8-parameter, 2-required calculator with no output schema, the description covers triggers, method, input expectations, and the nature of the return value (a EUR starting range). It is nearly self-sufficient; the only minor gap is no explicit statement about behavior when factual inputs are missing and seriousness is also omitted.

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

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

With 75% schema coverage and 5 enum-typed parameters, the schema carries most of the load. The description adds real value by explaining the inference contract: seriousness may be omitted and derived from the supplied facts (fault, damage, duration, data categories, people affected). It also frames the Art. 83(4)/83(5) tier and turnover adjustment as the calculation inputs, reinforcing what each drives.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb+resource (GDPR fine estimation) and frames it with the exact user questions it answers ('how big could a GDPR fine be?', 'how are GDPR fines calculated?'). It also states the method scope (step 2 of EDPB Guidelines 04/2022), which cleanly distinguishes it from siblings like gdpr_breach_decision or dora_checklist that handle obligations rather than quantification.

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

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

Explicit trigger phrasings plus concrete guidance on what to supply ('Give the seriousness, or the facts to let ClevSec suggest it') make the intended invocation context clear. It does not, however, name an alternative or state when NOT to use it (e.g., that it computes a range only, not a decision on whether a breach occurred, which is gdpr_breach_decision's job).

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

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), so the bar is lower, and the description still adds real behavior: output shape depends on whether answers are supplied, and 'unanswered questions count as gaps,' which affects how a score should be interpreted. It stops short of describing scoring weights or the readiness-level scale, hence not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, then the two call modes in a logical order; every clause carries information. The parenthetical enumeration of all nine domains is useful for coverage awareness but makes the second sentence long, keeping it just below the tightest possible phrasing.

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

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

There is no output schema, so the description must explain returns, and it does precisely: 53 questions across nine domains mapped to articles in the no-answers mode, and per-domain scores, an overall readiness level, and gaps in the answers mode. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100% and the schema already documents the single answers object, its example, the yes/partial/no enum, and the unanswered-equals-gap rule. The description reinforces that same format but adds no new parameter-level detail, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('assess how ready an organisation is for NIS2 ... or find its gaps') and goes further by naming the nine domains and the NIS2 articles the questions map to. This is clearly a readiness/gap-scoring tool, distinguishable from siblings like nis2_scope_check (applicability) and dora_checklist (different regulation).

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

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

Gives explicit branching instructions: 'Call without answers to get the 53 questions' vs 'Call with answers ... to get a score per domain, an overall readiness level and the gaps.' The condition that selects each mode is stated rather than left to inference.

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

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

Annotations already declare readOnly and idempotent, so the safety profile is covered. The description adds genuinely useful behavioral context: the tool is 'an indication only' and national law plus the member state's list are the final determiners, warning the agent not to treat the output as authoritative.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with no filler. The main capability statement and the limitation caveat are both present, though leading with usage examples rather than the core purpose delays the essential information slightly.

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

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

For a 9-parameter classification tool with no output schema, the description indicates what is returned (applicability plus category) and flags the important legal limitation. Combined with the well-described schema, an agent has what it needs to call it and interpret results.

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

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

Schema coverage is 67%, and the description references the applicable legal basis (Arts. 2 and 3, size rule of Recommendation 2003/361/EC), which helps the agent understand why sector, size and type matter. However, it adds little concrete meaning beyond what the schema's own field descriptions already provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific outcome: indicates whether the NIS2 Directive applies to an organisation and classifies it as essential or important, derived from sector, size and type. This is clearly distinct from siblings like nis2_gap_assessment or reporting_deadlines, so an agent can route correctly.

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

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

Gives concrete example user phrasings ('does NIS2 apply to my company?', 'are we an essential or important entity?') that map directly to invocation contexts. It lacks explicit when-not guidance or named alternatives, but the trigger conditions are clear.

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

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

Annotations already establish this as a safe, read-only, idempotent query. The description adds genuine value beyond them by disclosing that output is conditional on the supplied situations and by sketching the return content (items with articles, timing, exceptions).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly written sentences, front-loaded with the trigger condition, followed by what it returns and how to drive it. No filler.

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

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

With no output schema, the description adequately explains what comes back (required items with articles, when notice must be given, exceptions) and how parameters shape it. Enough for an agent to call it correctly; only individual parameter coverage is thin.

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

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

Schema coverage is only 50%, so the description must compensate. It explains the functional role of the inputs ('situations that apply') as filters that drop irrelevant items, which is a useful semantic layer, but it does not clarify the three booleans lacking schema descriptions (relies_on_consent, transfers_outside_eea, relies_on_legitimate_interests).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('lists every item the GDPR requires') and scopes it precisely with Art. 13 vs Art. 14, timing, and exceptions. An agent can immediately distinguish this reference/checklist tool from siblings like gdpr_breach_decision or gdpr_fine_estimate.

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

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

Clearly states when to use it ('when writing or checking a privacy policy or privacy notice') and gives practical guidance ('tell it which situations apply to drop items you do not need'). It does not name alternatives or explicit exclusions, but the use context is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description goes beyond them by specifying the return content in detail: who must report, to whom, by when, with the governing article and the point at which the clock starts — genuine behavioral disclosure about what comes back.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is front-loaded with the use case before the content inventory, and no sentence is filler. The second sentence is long and list-heavy (four regimes plus article and clock-start details), which makes it slightly dense, but every clause carries information an agent needs.

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

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

For a one-parameter, read-only lookup with no output schema, the description is nearly complete: it names the scope, the regimes and the shape of the answer. The only omission is whether results are regime-partitioned or returned as a single merged list when no filter is supplied.

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

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

There is a single optional 'regimes' parameter with 100% schema description coverage ('Limit to these regimes; omit for all'), so the schema already does the work. The description's mention of GDPR, NIS2, DORA and CRA names the same set but adds no syntax or semantics beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (incident/breach reporting deadlines in the EU) and verb-equivalent (lists who must report what, to whom, by when), and enumerates the four regimes covered with their trigger types. This distinguishes it from siblings like gdpr_breach_decision, nis2_scope_check or dora_classify_incident, which assess or classify rather than return deadline tables.

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

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

It gives clear usage context with a canonical question example ('how long do we have to report a breach / a cyber incident?'), so an agent knows when to reach for it. It does not name alternatives or state when not to use it (e.g. use dora_classify_incident first to determine whether an incident is reportable), so it falls short of an explicit routing rule.

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