Ansvar: EU Compliance & Legal Intelligence

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the behavioral constraint of max 100 and 'one query', but does not disclose return format, error handling, or partial failure behavior.

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 description is two sentences with no wasted words. It front-loads the action and includes a concise usage tip. Every word 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 simple, read-only batch tool, the description covers the basic purpose and limit, and annotations cover safety. However, without an output schema, it does not specify what 'details' includes (e.g., which fields beyond KEV/EPSS) or behavior for invalid CVE IDs, leaving some gaps.

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%, with all three parameters documented (cve_ids, include_kev, include_epss). The description adds no additional parameter meaning beyond framing the batch nature, so it meets the baseline of 3.

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 clearly states the verb ('Get details'), resource ('multiple CVEs'), and scope ('in one query (max 100)'). It distinguishes itself from sibling tools like get_cve_details by emphasizing batch capability, making the purpose immediately clear.

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 phrase 'Efficient for bulk vulnerability assessment' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or when-not-to-use scenarios, such as pointing to get_cve_details for single CVE lookups.

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 destructiveHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: irreversibility ('cannot be resumed') and idempotency ('cancelling an already-cancelled workflow returns the same result'), which an agent needs for retry logic. It stops short of saying what happens to in-flight steps or whether cancellation is synchronous.

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, front-loaded with the action, followed by consequences and then the idempotency guarantee. Every sentence carries new information; nothing is repeated from the title or schema.

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?

An output schema exists, so return values need no explanation, and the description covers the key post-conditions: irreversibility, visibility in list_workflows, and exclusion from resume listings. A note on the effect on an in-flight workflow run would close the remaining gap.

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 workflow_id property already documents its origin ('as returned by start_workflow') and recovery path via list_workflows. The description adds only 'by id', so baseline 3 is correct with the schema doing the heavy lifting.

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 ('Cancel an active workflow by id'), with the scope qualifier 'active'. The agent can immediately distinguish this from resume_workflow and list_workflows 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.

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

Explicitly routes the agent by naming siblings: cancelled runs are excluded from resume_workflow's active listing and remain visible in list_workflows. It does not state an explicit when-not case (e.g., cancelling a run that already completed), but the context provided is well above implied usage.

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=true and destructiveHint=false. The description adds behavioral context by specifying the return value includes KEV details, remediation actions, and due dates, which goes beyond 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.

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

The description is two sentences: the first states the main purpose, the second lists the key return fields. Every word earns its place, with no redundancy or unnecessary detail.

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 simple one-parameter read-only tool with no output schema, the description is complete. It explains what the tool does and what it returns, making it sufficient for an agent 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.

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

Schema description coverage is 100%, with the required cve_id parameter described as 'CVE identifier'. The description reinforces the parameter's purpose but adds no additional semantic detail beyond what the schema already provides.

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 clearly states the tool checks if a CVE is in the CISA KEV catalog, using a specific verb and resource. It distinguishes itself from siblings like get_cve_details and search_cve by focusing on KEV-specific status.

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 description provides clear context for when to use the tool (whenever KEV status is needed) but does not explicitly mention alternatives or exclusions. The narrow scope makes the usage obvious, so it earns a 4 rather than a 3.

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?

Adds useful behavioral details beyond annotations: returns {mermaid, validation_errors, structural_warnings}, 'Bad input returns validation_errors with mermaid=null; it never raises', and lists validation checks. It does not disclose side effects despite readOnlyHint=false, but no direct contradiction arises.

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 description is long but dense, covering purpose, workflow, input structure, and error handling in a structured way. It front-loads the core action and uses the rest for necessary detail, so it is efficient despite length.

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 complex tool with nested objects, the description covers workflow context, input schema details, return values, and error behavior. It leaves no significant gaps for an agent to select and invoke the tool 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 description coverage is 100% and the description mirrors the schema's artifact structure almost exactly. It adds no new parameter semantics beyond what the schema already provides, 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 opens with 'Validate a DFD artifact and render it as styled Mermaid,' which is a specific verb+resource. It clearly distinguishes itself from siblings by referencing the DFD specialist workflow and submit_response, positioning it as the validation/rendering step.

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?

Explicitly states when to use: 'after the DFD specialist has finished extraction' and 'before the artifact is submitted via submit_response'. This gives clear workflow context. However, it does not name alternative tools or explicitly state when not to use it, so it falls 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 declare readOnlyHint/openWorldHint/destructiveHint, yet the description adds substantial non-obvious behavior: tier-aware gating with caveats rather than silent omission, a TTL-cached (15 min) workflow-registry snapshot with live/stale/unavailable status, catalog_drift entries, service_notices for degraded subsystems, and tool_status for zero-scope tools. This is exactly the kind of behavior an agent could not infer from structured fields.

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?

Purpose is front-loaded well, but the body is a very dense near-3000-character run-on covering output shapes, caching, drift, notices and tips that would benefit from structure. Much of the content is warranted by the tool's complexity, but the readability cost is real.

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?

An output schema exists, so return-value enumeration is partly redundant, yet the description still rounds out operational context (error semantics for unknown section, tier-awareness, degraded-state signaling). For a complex multi-mode catalog tool with 8 optional params, the coverage is effectively complete.

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%, so the baseline is 3. The prose largely restates the schema's dependency rules (domain/cursor/limit require section='sources'; detail validated before section) and the law_map filtering behavior already documented per-parameter, adding little genuinely new parameter meaning.

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 opens with a specific verb+resource ('Discover what Ansvar can do for your agent') and explicitly separates itself from the nearest sibling: 'Companion to get_my_capabilities (live tier / quota only)'. An agent can distinguish this catalog-discovery tool from live tier/quota tools without opening either 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?

It gives concrete selection rules: default detail='summary' for a compact orientation view, detail='full' for the complete catalog, section=<id> for one section alone. It also routes the agent elsewhere for live data (get_my_capabilities) and for corpus retrieval (search in en, fetch hits via get_provision's language arg). No explicit when-NOT-to-use beyond the sibling callout, so not a full 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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses bounded results, per-edition currency state, hold reasons, crosswalk behavior, and exact search/lookup hints. The explicit warning that lexical matches are not coverage claims is especially valuable for setting agent expectations.

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 description is dense but well-structured, leading with the core purpose and then adding high-value caveats and return characteristics. No sentences are wasted, and the most decision-relevant information appears first.

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 tool with no output schema, the description covers returns at a useful level: bounded candidates, currency state, hold reasons, crosswalk, and hints. It also documents refusal and ambiguity cases in the parameter descriptions. A minor gap is the lack of explicit cursor/pagination semantics, though the cursor parameter exists in the schema.

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?

The schema descriptions for query, topics, sectors, and expand already provide detailed semantics, and the main description adds the lexical matching model and bounded-result behavior. Undocumented parameters like availability, document_types, cursor, and limit are less explained, but their enums and constraints offer partial self-documentation.

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 opens with a specific verb and resource: "Find EU legal acts" by CELEX/ELI identifier, official title, reviewed alias, or lexical match. It clearly distinguishes this from generic siblings like search and search_by_product by naming EU-specific identifiers, EuroVoc labels, and Ansvar sectors.

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 description and query parameter explicitly explain when the tool can be called: query-only, filter-only, or both, and that omitting both refuses with empty_request. It also warns that matching is lexical, not semantic, and that a short candidate list is not a coverage claim. However, it does not explicitly name sibling alternatives or state when to prefer another tool.

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 a safe read (readOnlyHint=true, destructiveHint=false), and the description adds substantial behavior beyond that: the quality-gate refusal with failing check and hint, the render key with short-lived download URLs, the render_error fallback that never drops the report JSON, tier-based serving, and watermark rules for lower tiers. This is unusually rich disclosure for a read-only tool.

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?

Purpose is front-loaded in the first sentence, followed by triggers and then behavior. The tier/watermark sentence is dense but every clause carries operational information; no filler, though the definition runs long.

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 an output schema present, return values need not be reiterated, and the description still covers failure modes, tier gating, and artifact delivery. Nothing an agent needs to invoke and interpret the tool correctly appears to be 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 adds material meaning the schema does not: that the advertised format enum is narrowed by tier and that unserved formats are refused rather than downgraded. It does not re-explain workflow_id or include_report, so it sits just above baseline.

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 ('Produce the final compliance report') and scopes it to 'a completed workflow', clearly separating it from workflow-control siblings like start_workflow or resume_workflow. An agent can identify the operation without opening the 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?

Provides explicit natural-language triggers ('generate the gap analysis report', 'I need the DPIA report as a document', 'create the threat model output') and a clear exclusion: it refuses until every quality gate passes. The when-to-invoke condition 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?

Beyond the read-only annotation, the description discloses key nuances: questions_for_user is advisory while requires_user_input is server-enforced, and it explains user_provided_fields gating submit_response. This adds significant operational context not available from annotations alone.

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 sentences, each earning its place: the main purpose, usage examples, and important field semantics. It is dense with useful information and contains no redundant phrases.

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 an output schema present, the description doesn't need to enumerate return fields, but it explains their behavior (advisory vs. enforced, user_provided_fields). This covers the core functionality and edge-case semantics, making it complete for an agent to use 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?

The input schema already fully documents workflow_id, including its origin from start_workflow and recovery via list_workflows (100% coverage). The description does not add further parameter semantics, so the baseline score of 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 clearly states the tool checks which step a compliance workflow is currently on and what input is needed next. It names the specific resource (compliance workflow step) and a concrete verb (check), and the example queries distinguish it from related tools like get_progress.

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 description provides explicit usage triggers: 'Use this when someone asks...' with concrete example phrasings. It does not explicitly mention when not to use it or alternatives, but the context is clear and actionable for an agent.

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=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context by specifying that the tool returns 'live advisory context' and includes CISA ICS/OT advisories with affected industrial products, indicating a comprehensive multi-source lookup. No contradiction with annotations.

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 description is a single, well-structured sentence that front-loads the core purpose ('Get complete details') and efficiently lists the key outputs before giving a use case. Every word earns its place; no fluff or repetition.

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?

Given the lack of an output schema, the description does an excellent job of conveying what the tool returns by enumerating seven distinct data categories, including the unique CISA ICS/OT advisory details. It also provides a practical use case, making the tool's broader context clear. The information is sufficient for an agent to decide when and how to use this tool.

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% for all 4 parameters, with clear descriptions for each. The tool description lists the data types returned (CVSS, references, CPE, etc.) which partially maps to the include_* parameters, but does not add new parameter-level meaning beyond what the schema already provides. 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 clearly states the tool's function: 'Get complete details for a specific CVE' and enumerates the specific data categories (CVSS scores, references, CPE mappings, KEV status, EPSS score, exploit references, CISA ICS/OT advisories). This specific verb+resource+scope distinguishes it from sibling tools that focus on individual aspects (e.g., get_epss_score, check_kev_status).

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 description provides a clear context for use: 'use this to enrich an OT/ICS or robot-cell TARA with live advisory context.' It implies when to choose this tool over more specialized ones, but does not explicitly mention alternatives or exclusions. This matches 'clear context, no exclusions'.

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=true and destructiveHint=false. The description adds valuable behavioral detail about the return payload (timestamps, age, counts, health status categories) and the exact data sources covered. It doesn't describe edge cases like partial failures, but for a read-only status tool this is adequate.

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 description is two sentences: the first is a dense summary of functionality and outputs, the second is a clear usage recommendation. No filler or repetition of the name/title, and the most important information is front-loaded.

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?

Despite lacking an output schema, the description fully enumerates the return fields and data sources, making the tool's behavior predictable. Given the zero-parameter input and simple read-only nature, the description covers all necessary context without requiring more detail.

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?

The tool has zero parameters, so the baseline is 4. The description correctly makes no parameter claims, and since the schema is empty, there is no additional documentation needed. The description adds value by explaining what data the tool actually provides.

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 clearly states the verb 'Check' and the resource 'freshness and sync status of all data sources', and it lists specific return fields (last sync time, data age, record counts, health status) and the covered sources (NVD, CISA KEV, EPSS, ExploitDB). This distinguishes it from sibling tools that target individual sources or specific details.

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 description provides explicit usage context: 'Use this to verify data is up-to-date before making security assessments.' While it doesn't name alternative tools or when NOT to use it, the context is clear and sufficient for an agent to decide when this tool is appropriate.

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=true and destructiveHint=false, so the tool's safety profile is known. The description adds value by specifying the return values (probability and percentile), but does not cover potential caveats like data freshness or error handling.

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 description is two sentences long, front-loads the primary purpose, and contains no redundant information. Every word contributes to understanding the tool's function.

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 simple one-parameter read tool with no output schema, the description adequately explains the return format (probability and percentile). A mention of potential error behavior when the CVE is not found would make it fully complete, but it is otherwise sufficient.

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?

The input schema fully documents cve_id with a pattern and description (100% coverage). The description aligns with the schema ('for a CVE') but adds no extra meaning beyond what the schema already provides.

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 clearly states the tool retrieves the EPSS score for a CVE, with specific output context (probability within 30 days and percentile ranking). This distinctively separates it from sibling tools like get_cve_details or get_exploits.

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?

No explicit guidance is given on when to use this tool versus alternatives. The description implies usage for EPSS scores, but does not mention when not to use it or name alternative tools, leaving the agent to infer context from sibling names.

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=true and destructiveHint=false, so safety is covered. The description adds useful context by specifying that it returns 'references' (not exploit code itself) and lists aggregation sources. However, it does not describe result format or pagination, which would be additional behavioral detail.

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 description is a single sentence of 14 words that front-loads the action and resource. Every word earns its place, with no redundancy or 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?

The tool is simple with two parameters and good annotations. The description provides key context (sources, reference-only nature) and is sufficiently complete for a read-only lookup tool, though it could optionally mention the output shape (e.g., list of URLs).

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 schema already explains cve_id format and verified_only default/filtering. The description adds no extra parameter-specific semantics, so 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 uses a specific verb ('Get') and resource ('public exploit code references') scoped to a CVE, and enumerates concrete sources (Metasploit, ExploitDB, GitHub PoCs). This clearly distinguishes it from siblings like get_cve_details and search_cve.

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 description clearly indicates when to use the tool: when you need exploit code references for a given CVE. It does not explicitly name alternative tools or exclusions, but the context is unambiguous given the sibling tool names.

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=true and destructiveHint=false. The description adds useful behavioral context beyond annotations: it specifies the data source ('Public-domain CISA CSAF data') and the exact contents of the response, setting expectations for what the call returns. No contradictions with annotations.

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?

A single, tightly written sentence that front-loads the core action and then enumerates the return contents. Every word adds value; there is no fluff or repetition of schema properties.

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 simple read-only lookup tool with one well-documented parameter, the description fully covers what the tool does and what the response will contain. The absence of an output schema is compensated for by the explicit list of returned components. No critical information 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?

The schema already fully documents the single parameter with an example format, so description-level parameter guidance is not necessary. The description implicitly connects advisory_id to the advisory being fetched, but adds no extra semantic detail beyond the schema. Baseline of 3 applies due to 100% schema coverage.

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 verb and resource: 'Get full details of a CISA ICS/OT advisory' and enumerates the exact contents (affected products, CVEs with CVSS, summary, CSAF source URL). This clearly distinguishes it from sibling tools like search_ics_advisories (search vs. full detail) and get_cve_details (CVE-specific vs. advisory-scoped).

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 description implies the tool is used when you have an advisory ID and need the complete advisory record, but it does not explicitly state when to use this over alternatives or mention that search_ics_advisories should be used to find IDs. The usage context is understandable but 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 cover the safety profile (readOnly, non-destructive, not open-world), and the description adds substantial behaviour beyond them: counters reset at UTC midnight, Redis-backed quota/concurrency shared across workers and replicas so adding workers does not multiply allowance, in-memory counters in Redis-less development, per-org pooled budgets, and null-with-unavailable_reason rather than zero on failed document reads. These are non-obvious operational traits an agent cannot infer from annotations.

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?

Purpose is front-loaded, but the body is a single dense run-on paragraph that enumerates nearly every return field (tier, capabilities, limits, workflow_run_search_allowance, usage_today, documents, tool_surface, workflow_discovery, upgrade_url, service_notices) plus ADR citations, much of which duplicates the output schema that already exists. Many clauses do not need to be in the description to call this zero-argument read tool.

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-argument, read-only tool with an output schema, nothing needed to invoke it correctly is missing: audience (visible to all tiers), argument behaviour, quota/reset semantics and degraded-subsystem signalling are all covered. Completeness is in fact beyond what the task requires.

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?

The tool takes zero arguments, so the baseline is 4, and the description reinforces this with 'takes no arguments' and 'visible to all tiers'. There is no parameter surface left to explain.

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?

Opens with a concrete noun phrase naming exactly what is returned: tier, capabilities, limits and live usage for the calling identity. It also disambiguates against siblings by naming describe_capabilities, list_workflow_types and start_workflow in the workflow-discovery section, so an agent can position this tool against neighbours 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?

Explicitly states when to reach for it: before calling tools or fan-out paths, and before issuing more requests to check remaining quota, with a motivating scenario (lower-tier agents avoiding wasted retries or upgrading mid-conversation). No explicit when-not-to-use or direct statement that describe_capabilities is the alternative for the catalog view, which keeps it 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 declare readOnlyHint=true and destructiveHint=false, so the safe, read-only nature is known. The description adds value by specifying that the tool 'Returns completed and remaining steps with a progress percentage and quality score,' giving insight into the output structure and behavior beyond annotations.

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 description is concise and well-structured: purpose statement, usage examples, and output summary in three short sentences. There is no fluff or redundancy, and the most important information is front-loaded.

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 simple read-only tool with one parameter and an output schema, the description adequately covers purpose, when to use, and what to expect in return. It is complete enough for an agent to select and invoke the tool 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?

The schema description for workflow_id is complete (100% coverage), so the baseline is 3. The tool description does not add parameter-specific details, but the schema already provides sufficient meaning for the single parameter.

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 clearly states the tool's function: 'See how far along a compliance workflow is and which steps remain.' It specifies the resource (compliance workflow) and the action (get progress), and distinguishes it from related tools like get_current_step by mentioning remaining steps and a progress percentage.

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 description provides explicit usage scenarios: 'Use this when someone asks how much of the gap analysis is done, what percentage is complete, or how many steps are left.' This gives clear context for when to use the tool, though it does not explicitly name alternatives or when-not-to-use cases.

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?

The annotations already declare read-only, non-destructive, closed-world behavior, so the bar is lower. The description adds substantial behavioral context beyond that: it explains that unenrolled or critical sources are not covered, that `null` disposition counts never mean the register is empty, that duplicates are suppressed and counted rather than silently dropped, and that the obligations dataset can be degraded or unavailable. This is rich, non-redundant disclosure.

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 description is an approximately 450-word essay dense with nested key specifications, backticks, and repeated state explanations. It is front-loaded with purpose, but far from appropriately sized: many granular return-value details could be compressed or delegated to an output schema (which is absent). It reads like documentation rather than a tool description.

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 carries the full burden of explaining return values, and it does so exhaustively: source enrollment, freshness states, licensing verdict state, obligations dataset state, the `lane_f` fleet lane, and the `disposition_summary` block with its null semantics and exact key shapes. Nothing an agent needs to interpret the tool's output 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?

The tool takes zero parameters, so the baseline is 4. There are no parameters for the description to clarify, and it does not attempt to add meaning to a non-existent schema.

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 opening sentence states a specific verb and resource: 'Report what this service actually monitors and how current each source is.' It distinguishes itself from siblings by naming `get_regulatory_deadlines` and positioning itself as 'the free surface for a premium tool.' An agent can tell what this tool does and how it differs from the deadlines tool without opening either.

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 explicit usage contexts: 'Read this before concluding anything from an empty search' and 'a caller whose deadlines request refused, or came back degraded, can find out here why.' It implicitly contrasts with `get_regulatory_deadlines`, but stops short of stating when not to use this tool, so it misses the top mark.

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=true and destructiveHint=false, so safety is covered. The description adds context about the prerequisite ('completed STRIDE analysis steps') and mentions that returns include severity ratings and mitigations, which is useful beyond the annotations but not deeply behavioral (e.g., no auth, rate limits, or error-handling nuances).

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 description is three sentences with no redundant phrasing. Front-loaded with the main purpose, followed by example queries and a summary of return content. Every sentence 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 simple read-only tool with one parameter and an output schema, the description covers purpose, usage triggers, return content, and a prerequisite (completed STRIDE steps). The schema handles parameter semantics, annotations handle safety, and the output schema presumably handles return structure. Nothing significant 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 description coverage is 100%, and the workflow_id parameter has a rich description in the schema itself ('as returned by start_workflow. Recover a lost id with list_workflows.'). The tool description adds no additional parameter meaning, so the baseline 3 for high schema coverage 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 clearly states the tool's function with a specific verb ('Review') and resource ('threats identified during a threat-modeling workflow'). It also provides example natural-language queries ('what threats were found'), which helps the agent map user intent to the tool. This differentiates it from sibling tools like start_workflow or get_progress by focusing on the threat output.

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 description explicitly says 'Use this when someone asks ...' with concrete example phrases, giving clear context for when the tool is appropriate. It does not mention alternatives or exclusions, but the context is strong enough to distinguish it from siblings without needing an explicit alternative list.

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 cover only the safety profile (readOnly/openWorld/destructive). The description adds non-obvious behavioral context: the response shape (`jurisdictions` array and its fields), that `count_scope` is `whole_jurisdiction`, that counts are NOT domain-scoped under a `domain` filter, and that incomplete rows carry a `coverage_note`. These caveats directly prevent an agent from misreporting counts.

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 core instruction, then examples that each earn their place by mapping a real user phrasing to a call. The trailing sentence about searching in 'en' and fetching with get_provision's `language` argument drifts into sibling-tool workflow and is mild scope creep for a coverage-listing tool.

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?

An output schema exists, so return values need not be documented, yet the description still summarizes them and flags the count-scoping caveat. For a read-only discovery tool with 100% schema coverage, nothing an agent needs 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. The description earns extra credit by showing parameter values in worked examples (jurisdiction='DE', domain='cybersecurity', content_kind='court-decisions') and by restating the domain-vs-count scoping rule that governs how `domain` behaves.

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 opens with a concrete verb+resource: 'Show which countries, frameworks, and legal domains are available.' It immediately distinguishes itself from the sibling `search` by framing itself as a pre-search discovery step, so an agent can route between the two without inspecting schemas.

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 when-to-use: 'Use this BEFORE calling `search` when the user's topic doesn't name a jurisdiction,' followed by the follow-up action ('present the returned jurisdictions to the user or ask which applies'). Five worked query-to-call examples remove any remaining ambiguity about invocation.

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=true and destructiveHint=false, so the safety profile is known. The description adds behavioral context about pagination: 'Results are paginated with limit (default 20, max 100) and offset; follow next_offset until null.' It also lists the returned fields, which is useful beyond annotations. No contradiction with annotations.

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 description is concise and front-loaded with the purpose. It uses four short sentences, each adding value: purpose, filters, pagination, and use cases. No redundant or filler content. Well-structured and easy to parse.

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?

Given the read-only nature, the presence of an output schema, and comprehensive annotations, the description covers all essential aspects: purpose, parameters, pagination behavior, and use cases. It is complete for a straightforward list operation, with no significant gaps in context.

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 description largely restates what the schema already provides (e.g., status values, limit default and max, offset semantics). It does not add significant new meaning beyond the schema, so the baseline of 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 clearly states the tool's function: 'List your organisation's workflows' with specific fields (id, type, status, current step, last update). This distinguishes it from siblings like list_workflow_types (which lists types) and get_current_step (which retrieves a specific step). The verb 'List' plus resource 'workflows' is unambiguous.

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 description provides clear guidance on when to use the tool: 'Use it to recover a lost workflow_id or review past assessments.' This gives concrete use cases. However, it does not explicitly exclude alternatives or mention when not to use it, retaining a clear context but no exclusions.

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=true and destructiveHint=false, but the description adds substantial behavioral context beyond that: the tool is 'live' and authoritative, failures 'fail explicitly,' and no static list is returned as if live. It also details tier-locking behavior with caveats, such as 'a tier-locked row is never a bare false,' which is not inferable from annotations.

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 description is a single dense paragraph but is front-loaded with the core purpose. Each sentence provides meaningful information: purpose, usage, output fields, tier behavior, and failure handling. It is longer than minimal but every sentence earns its place; no wasted words. The structure is logical and readable.

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?

Given it has zero parameters and an output schema, the description is exceptionally complete. It explains the tool's role, when to invoke it, what fields each entry carries, how tier availability affects results, and how errors are handled. There are no significant gaps in understanding the tool's behavior and context.

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?

The tool has zero parameters, so the schema covers 100% with nothing to explain. Per the baseline for 0-param tools, this earns a 4. The description adds value by describing the output fields (workflow_type, base_type, produces, required_slots, etc.), which is useful even though an output schema exists.

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 clearly states it provides 'the authoritative live structured-workflow registry,' with specific verb and resource. It distinguishes itself from start_workflow by saying to call it 'before start_workflow instead of guessing an id,' and from static catalogs by emphasizing 'live.' It also enumerates covered workflow families, fully clarifying the tool's scope.

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?

Explicitly tells the agent when to use this tool: 'Call this before start_workflow instead of guessing an id from examples or a static catalog.' It also explains tier-dependent availability, which is crucial for deciding whether a workflow can be started. It does not describe exclusions for other sibling tools, but the direct call-to-action and context are strong.

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?

Beyond the readOnlyHint, the description reveals what the tool returns: 'which analysis prompts to run, with what arguments, which can run in parallel, and an inline fallback for MCP clients that cannot invoke prompts.' This adds concrete behavioral context and confirms it is a planning-only operation.

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 description is three compact sentences, front-loaded with the primary purpose, followed by the return shape and usage context. No wasted words; every sentence 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?

With an output schema present, the description need not detail return fields, but it summarizes them anyway. It covers the phase enum, the source of the ID, the optionality, and the fallback behavior, making it complete for an AI agent to select and invoke 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%, so the baseline is 3. The description adds value by linking phase_id to 'get_current_step' and noting that 'Richer context produces a more specific breakdown,' which goes beyond the bare schema definitions.

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 opens with a specific verb+resource: 'Plan the parallel sub-analyses for a threat-modeling phase.' It clearly distinguishes this tool from siblings by focusing on workflow phase planning and returning a breakdown, rather than executing or mutating workflow state.

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 explicitly says when to use: 'Optional — the workflow works without it; use it to speed up large systems by fanning phases out to subagents.' It also tells the agent where the phase_id comes from (get_current_step), which is a clear contextual trigger.

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=false and destructiveHint=false, so the description adds the context that this resumes a paused workflow. It does not disclose specific side effects or state changes, but with annotations the bar is lower. The description adds moderate value beyond the structured fields.

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 purpose, then usage examples, then the prerequisite. Every element earns its place with no redundancy or fluff.

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?

The tool is simple (one parameter, no required fields, output schema present). The description combined with the schema fully covers what the agent needs: what it does, when to use it, and how to obtain the workflow_id. No gaps remain.

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 description for workflow_id already explains it comes from start_workflow and can be recovered via list_workflows. The description repeats the requirement without adding new parameter nuances, so it earns the baseline for high schema coverage.

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 clearly states the tool continues a paused or interrupted compliance workflow, using a specific verb ('Continue') and resource ('compliance workflow'). It also distinguishes from siblings by giving concrete example utterances and referencing start_workflow as the origin of the required ID.

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?

Provides explicit usage scenarios with example phrases and a clear prerequisite (workflow_id from start_workflow). It does not explicitly mention when not to use or name alternative tools, but the context is clear enough to guide selection.

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?

Beyond the annotations (readOnlyHint/destructiveHint=false/openWorldHint=false), the description discloses unmetered cost, tier-invariant recommendations, determinism as a projection of the registry, snapshot provenance fields (fetched_at, age_seconds), instruction to re-scope rather than replay across a registry change, and explicit failure on a missing or stale snapshot with no static catalog substitution. This is unusually rich behavioral context for a read-only tool.

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 core purpose and the sibling routing before the detail, and structured as what/why/how/guarantees. It is long (~300 words) with some near-redundancy between 'Unmetered and visible at every tier: scoping never spends a run' and 'the recommendation is the same id whatever the caller pays', which costs it a point.

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?

Even though an output schema exists (so return values need not be explained), the description still names the return shape (next question with options, or the single workflow_type plus rationale and tier note), covers failure modes and staleness, and closes the ambiguity question ('ambiguity comes back as the next question, never as a list of maybes'). Nothing an agent needs 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 baseline is 3, but the description adds genuinely new meaning: the iterative call pattern ('call it with whatever you already know — every argument is optional', empty objective on first call triggers a question), and semantics for documents_available ('does not change which workflow is recommended'). It also maps natural language to the objective value ('which laws apply ... EV charger in Sweden' -> 'regulatory_applicability_register').

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 opening states a specific verb and resource with scope: 'Scope a compliance workflow down to ONE concrete workflow id before spending a run', and immediately positions it against siblings ('this answers what the catalog cannot', 'treat list_workflow_types as the authority when the two disagree', 'pass the id it returns to start_workflow'). An agent can distinguish it from list_workflow_types and start_workflow 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?

Explicit when-to-use with worked examples ('the user says Using Ansvar, we need a NIS2 gap analysis for our Dutch plant'), an explicit when-not plus the alternative to take ('for a framework it does not list, call list_workflow_types and start_workflow directly'), and the iterative protocol ('put that question to the user, then call again with their answer'). Nothing about routing is 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 readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral context such as pagination, rate limits, or result format, so it only minimally adds to what annotations provide.

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 description is only two sentences, with no unnecessary words. Both sentences contribute to understanding the tool's purpose and typical use, making it highly concise and well-structured.

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?

Given the tool's moderate complexity (5 parameters, all documented) and strong annotations (read-only), the description is adequate. It conveys the core purpose and use case, while the schema covers parameter details. The lack of an output schema is offset by the clear implication that the tool returns CVE data.

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%, so all parameters are well-documented in the schema. The description only mentions product and version conceptually, which doesn't add new meaning beyond the schema.

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 clearly states the tool finds CVEs for a specific product and version, which is a specific verb+resource. It distinguishes itself from generic search tools by emphasizing specificity, but doesn't explicitly differentiate from sibling tools like search_cve.

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 description gives a clear context for use: vulnerability assessment of software components. It implies the tool is for targeted CVE lookups but does not provide exclusions or mention alternative tools, so it doesn't fully meet the 5-criteria.

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=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by stating the return payload includes CVSS scores, KEV status, and EPSS data, and that full-text search on descriptions is supported. No contradictions with annotations.

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 description is three sentences and about 40 words. It is front-loaded with the primary action, followed by return data and an alternative tool reference. Every sentence earns its place without redundancy or 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?

Even though there is no output schema, the description specifies the key return fields (CVSS, KEV, EPSS) and points to get_cve_details for deeper information. It does not mention pagination limits or result ordering, but the schema covers the limit/offset parameters. For a complex 12-parameter search tool, the description provides sufficient context without needing to enumerate every aspect.

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%, with each parameter already documented concisely. The description's reference to 'keyword, severity, score range, and filters' is a high-level summary that doesn't add meaning beyond the schema. The note about full-text search on descriptions duplicates the keyword parameter's schema description.

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 clearly states the tool's purpose: 'Search CVEs by keyword, severity, score range, and filters.' It specifies the resource (CVEs) and the action (search), and distinguishes itself from get_cve_details by directing users there for full details on a specific CVE. The verb+resource+scope is specific and actionable.

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 description explicitly names get_cve_details as an alternative for full information on a specific CVE, which provides a clear when-not-to-use signal. However, it does not contrast with other search-related siblings like search_by_product or batch_search, leaving some ambiguity about when to use this tool over those.

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=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating the returned summary fields (affected vendors, CVE counts, severity) and the data source (public-domain CISA CSAF), which are not visible in 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.

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

Three short sentences front-load the core action, then cover return contents, sibling routing, and data source with no filler. Every sentence contributes useful information, and the structure is easy to scan.

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 read-only search tool with six optional parameters and no output schema, the description covers the filter options, result summary, full-detail fallback, and data licensing context. It could mention pagination or ordering behavior, but the provided information is sufficient for correct invocation in most cases.

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 83%, so the schema already documents vendor, keyword, min_cvss, advisory_kind, and published_after. The description mostly restates these filter dimensions without adding new syntax or format details, which is acceptable given the high schema coverage but does not go beyond it.

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 verb ('Search'), a precise resource ('CISA ICS/OT security advisories'), and enumerates the advisory families (ICSA / ICSMA / ICSV) plus filter dimensions. This clearly distinguishes the tool from generic siblings like search or search_cve by tying it to CISA OT advisory data.

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 description explicitly routes agents to get_ics_advisory for full details, establishing that this tool returns search summaries rather than complete records. It does not explicitly state when not to use siblings like search_cve or search_by_product, but the advisory-specific scope provides enough situational context.

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 declare readOnlyHint=false and non-destructive; the description adds substantial context beyond that — run allowance spend semantics, no-refund on cancel at free/solo, the quality-gate behavior, the requires_user_input gate distinction, and enum fallback behavior when the registry snapshot is stale.

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?

Exceptionally long single paragraph with no formatting, repeating tier details ("free and solo", "Premium", "Team or Company") multiple times. Much of the run-allowance and no-refund content belongs to sibling tools (get_my_capabilities, cancel_workflow) rather than this one. Front-loaded purpose is good but the body is dense and overwrought.

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?

Given there's an output schema and rich sibling ecosystem, most return-format concerns are covered elsewhere. The description covers tier restrictions, prerequisites, gating semantics, and cost — enough for an agent to call correctly, though redundancy with sibling tools dilutes the value.

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 each parameter already has its own description carrying framework-validity, jurisdiction ISO-2, parent_run_id/succession_reason pairing, and enum source. The tool description adds the tier-fencing angle (framework accepts only nis2/dora/cra/eu_ai_act at free/solo) but otherwise restates schema content. Baseline 3 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?

States a specific verb (Begin) and resource (structured workflow selected from live registry) and enumerates the catalog domains. Passively differentiates from siblings via enum examples matching list_workflow_types' authoritative-ids role.

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?

Explicitly names the prerequisite (call list_workflow_types first), names get_my_capabilities for remaining runs, names cancel_workflow's non-refund behavior on free/solo, and instructs the agent to confirm workflow_type with the user before calling. Tier-fencing tells the agent which types are/aren't available.

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?

The description explains that 'The workflow engine validates the response and advances to the next step,' revealing the tool's side effects beyond the annotations. It also highlights the guardrail against misrepresenting automation as human review by asserting approved_by only accepts 'auto', which is valuable behavioral context not present in 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.

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

The description is detailed but every sentence earns its place: it opens with the purpose, followed by usage triggers, then key parameter behaviors, and closes with the auto-approval caveat. It is appropriately sized for a tool with 9 parameters and complex gating semantics, with 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?

Given the complex input schema, the description covers the critical context: what the workflow does, when to use it, how to handle evidence references, and how to correctly assert human vs. automated approval. With an output schema present, it doesn't need to explain return values, so the description is complete for an agent to select and invoke the tool 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%, so the baseline is 3. The description adds meaningful semantic nuance by providing real-world examples of responses, clarifying evidence_references accepted formats, and reinforcing the distinction between approved_by='auto' and user_acknowledged for human review, which goes beyond the schema parameter descriptions.

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 uses a specific verb+resource construction: 'Provide an answer to the current step in a compliance workflow.' This clearly distinguishes the tool from siblings like start_workflow, cancel_workflow, and get_current_step by focusing on submitting a response for the current step.

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 description explicitly states 'Use this when someone provides information requested by the workflow' and gives concrete examples. It also covers conditional usage for unattended gates, clearly specifying when to set approved_by='auto' and user_acknowledged=false, which orients the agent on when to use this variant.

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=true, destructiveHint=false, and openWorldHint=false. The description adds rich behavioral context beyond that: refetch scope, concurrency up to 6, shared 25-second deadline, session pool default, expiry behavior with bounded/unreached_clauses, claim_support always not_checked, resolved evidence nodes capping dependents at UNVERIFIED, and no overall pass verdict.

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 purpose is front-loaded, and most dense detail is relevant for a complex validation tool. However, the lack of bullet points or headings and minor repetition (claim_support is always not_checked; claim support stays not_checked) make the text harder to scan than it could be.

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?

No output schema exists, but the description explains return behavior in detail: checked/not_checked lists, summary.display_markdown, summary.attention_items, bounded and unreached_clauses on expiry, and limits. It also clarifies what is not checked, making it complete for a complex tool.

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%, so the schema already documents both graph and answer parameters in detail. The description adds that answer quotations may optionally be compared, but it does not add new syntax, formats, or constraints for the graph parameter beyond what the schema provides.

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 ('Check') and resource ('claim graph') and scopes the tool to before relying on or presenting conclusions. However, it does not explicitly mention sibling tools like validate_citation or verify_citations, so the boundary between this and related validation tools is left implicit.

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 clear context for use: before relying on or presenting a claim graph's conclusions, and optionally for checking quotations in a prose answer. It also lists things the tool does not verify (legal in-force status, facts, satisfiability, entailment), but names no alternative tool for those cases, so alternatives are missing.

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?

The description adds substantial behavioral context beyond annotations (which only declare readOnly/openWorld/destructive). It explains concurrency (6), time budget (25s), subject limit (60), bounded response on exhaustion, tier-dependent attestation, the refusal semantics (withheld, not_served, identity_absent), the specific stale-feed rule and exception, and the 'never means the law does not exist' caveat. It also clarifies that attestation is integrity/provenance, not legal validity.

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 description is very long (over 500 words) and dense with jargon. While it contains necessary information, it is not front-loaded: key operational limits and verdict meanings are buried in the middle. It could be restructured with bullet points or clearer sections. Every sentence may earn its place, but the delivery is not concise.

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?

Given the complexity (multi-lane verification, many verdicts, tiered attestation), the description is thorough. It covers all lanes, edge cases (stale feed refusal, alias resolution, doc:// pinpoints), limits, and what verdicts do not assert. With an output schema present, it doesn't need to explain return values, and it doesn't.

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?

The schema already has 100% description coverage, including detailed per-key semantics for subjects (subject_id, reference, source_id, quotation, language, identity_shape). The description reiterates some of this (e.g., source_id needed, quotation length, lanes) but does not consistently add meaning beyond the schema; it mainly restates with some extra context about lanes. With high schema coverage, 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 opens with a specific verb and resource: 'Verify submitted legal citations against what this gateway actually serves.' It then distinguishes itself from validation tools by explaining the gateway re-retrieves provisions to establish evidence, and enumerates the verdicts. The sibling 'validate_citation' is close, but the description's scope of 'established evidence' and the per-lane retrieval behavior differentiates it implicitly.

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 explains when to use it — to record which citations are established evidence — and provides detailed per-lane conditions for source_id and reference types. But it doesn't explicitly state when to prefer this over 'validate_citation' or 'validate_claim', which are likely alternatives. It also doesn't mention prerequisites beyond tier for attestation.

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