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 only mark readOnlyHint=false and destructiveHint=false, but the description adds crucial behavioral details: idempotency ('returns the same result'), irreversibility ('cannot be resumed'), and persistence ('record stays visible in list_workflows'). It also explains the impact on resume_workflow's active listing, which annotations cannot convey.

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, front-loaded with the core action, then condenses essential caveats (idempotency, resume exclusion, listing visibility) into a compact, well-structured format. Every sentence adds value.

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 single-parameter cancellation tool with an output schema, the description covers the core operation, irreversible side effects, idempotency, and the relationship to sibling tools (resume_workflow, list_workflows). It is complete enough for an agent to invoke safely and 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 has 100% parameter description coverage, including how to obtain workflow_id and how to recover a lost id. The description adds no additional parameter semantics beyond what the schema already provides, 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 opens with 'Cancel an active workflow by id', a specific verb+resource combination. It distinguishes itself from resume_workflow by noting cancelled workflows cannot be resumed and are excluded from its active listing.

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 clearly states when to use the tool (to stop an active workflow) and implicitly warns against use if resumption may be needed ('cannot be resumed'). However, it does not explicitly name alternative tools or provide a when-not-to-use list beyond the resumption caveat.

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 mark this read-only and non-destructive, and the description adds considerable behavior beyond that: detail validation happens before section validation, every view is tier-aware, gated families are shown with caveats rather than omitted, workflow lists are TTL-cache reconciled with live/stale/unavailable statuses, and degraded subsystems are surfaced via service_notices and tool_status. 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 long but well-structured and front-loaded, starting with the core purpose and default view before detailing edge cases. Nearly every sentence carries distinct information, though the length is substantial and some repository/file-location details could be seen as beyond what the agent needs for invocation.

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 discovery tool with 8 parameters and no enums, the description covers defaults, section routing, filter restrictions, error behavior, pagination cursor continuation, tier-aware output, caching/status semantics, degraded-system notices, and the relationship to the sibling tool. With an output schema present, the description does not need to restate return-value shapes.

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%, but the description adds cross-parameter constraints and semantics not visible in the schema: query/domain/jurisdiction/cursor/limit require section='sources', detail is validated before section even when section is passed, and unknown section values produce an error listing valid ids. It also enriches the meaning of section values like 'addons', 'tour', and category ids.

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 clear verb+resource: 'Discover what Ansvar can do for your agent,' then specifies the summary/full/section modes. It also differentiates itself from its closest sibling by naming get_my_capabilities as a companion limited to live tier/quota only.

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 explicit usage context for each mode: default summary for orientation, detail='full' for the complete catalog, section= for isolated sections, and filter parameters only with section='sources'. It explicitly contrasts with get_my_capabilities, telling the agent that live tier/quota queries belong to that sibling.

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 is known to be safe. The description adds significant behavioral context: it describes the structured diff (added, removed, modified text), the 'Sources used' audit table with zero-result note, and meta.render_contract for reproducing source attributions. This goes well beyond what annotations provide and gives the agent a clear picture of the output and its provenance.

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, each earning its place: the first states the core function, the second provides usage triggers with examples, and the third details the output format including the audit table and meta contract. It is front-loaded with the primary purpose and contains no fluff or repetition of schema content.

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

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

There is no output schema, so the description compensates by thoroughly explaining the return value: a structured diff with added/removed/modified text, a 'Sources used' section, and meta.render_contract. Combined with the exhaustive parameter schema and safety annotations, the agent has all necessary information to invoke the tool correctly and interpret results. The mention of zero-result note also handles an edge case.

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 covers all 5 parameters with descriptions (100% coverage), so the baseline is 3. The tool description does not elaborate on parameter details further, but it implicitly reinforces semantics through example queries ('DORA amendment', 'GDPR Article 17'). Since the schema already explains parameters clearly and the description adds minimal extra meaning, a 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+resource: 'Compare two versions of a legal provision to see what changed.' It distinguishes the tool from siblings like get_provision or search by focusing on the diffing use case, reinforced with concrete example queries ('what changed in the latest DORA amendment', 'differences in GDPR Article 17 after the update'). This fully clarifies the tool's purpose.

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...' followed by three representative user requests, giving clear context for when the tool is appropriate. It does not name alternatives or provide when-not guidance, but the usage scenarios are specific enough to differentiate from sibling tools. A missing explicit exclusion keeps it from 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?

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?

The description goes far beyond the readOnlyHint/destructiveHint annotations. It discloses refusal behavior with failure feedback, render failure handling ('attach render_error and never drop the report JSON'), tier-based restrictions, watermark behavior on free/solo, and the policy of refusing unsupported formats instead of quietly downgrading. This is rich behavioral context that the annotations alone do not 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 front-loaded with the core purpose, then usage triggers, then behavioral details, each sentence earning its place. Despite its length, it is dense with actionable information and has no filler or redundancy.

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 description covers the return format ('structured report with findings, citations, and recommendations'), failure modes, tier-specific behavior, error keys, and even the fact that render failures never drop the JSON. With an output schema present and full parameter coverage, this description is complete for the tool's complexity.

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 provides 100% coverage for both parameters, so the baseline is 3. The description adds meaningful behavior around the format parameter: 'branded rendered artifacts as short-lived download URLs', 'sibling render key', and explicit tier consequences. However, there is a slight inconsistency between the schema enum (json/html/pdf) and the description's mention of docx/all, which creates minor ambiguity even though the schema's own description also lists those values. Hence 4 rather than 5.

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: 'Produce the final compliance report from a completed workflow.' It also provides concrete trigger phrases ('generate the gap analysis report', 'I need the DPIA report as a document') that distinguish it from sibling tools like start_workflow or get_workflow_threats. This is a clear, differentiated statement of purpose.

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 guidance is given via example user requests. It also states preconditions ('from a completed workflow', 'Refuses until every quality gate passes') and an explicit when-not: formats the caller's tier does not serve are refused rather than downgraded. This fully meets the 5-level criteria of explicit when/when-not and alternatives.

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 goes well beyond the readOnly/destructive annotations by disclosing important runtime behaviors: empty responses are not evidence of no amendments, capability misses name supported scopes, responses include a 'Sources used' section, and meta.render_contract carries the evidence-curation contract.

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 overly verbose and repetitive, with long clauses and duplicated concepts like capability-miss behavior and source attribution. It would benefit from tighter structuring and shorter sentences.

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 absence of an output schema, the description supplies important output context including the 'Sources used' markdown table, zero-result note behavior, and the render_contract field, making it reasonably complete for correct invocation.

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 covers 100% of parameters, and the description adds useful operational nuances such as limit clamping, per-corpus coverage, amendment-capable dispatch for jurisdictions, and the regulation/regulation_id alternative.

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 'find[s] observed rows from legislative change feeds' and distinguishes it from related tools such as diff and search_regulatory_updates, making the purpose and boundaries explicit.

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 provides explicit when-to-use guidance with examples like 'what laws changed in Sweden this month', specifies the amendment-capable scope condition, and tells the agent to use diff for known provisions and search_regulatory_updates for newly published acts.

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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description goes far beyond that by detailing counter reset at UTC midnight, behavior under Redis (shared counters, no multiplication with workers), failure handling for document service (returns null and reason instead of zero), and service_notices for degraded state. This is rich behavioral context that an agent needs, fully disclosed.

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 extremely long (~400 words) for a no-parameter tool, far beyond what is typically needed. While it is front-loaded with the main purpose and each sentence adds informational value, it is not 'appropriately sized' – details like development-without-Redis configuration and worker semantics could be trimmed. The structure is good (it flows from purpose to fields to limits), but it lacks conciseness.

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 has an output schema, but the description still explains every returned field (tier, capabilities, limits, usage_today, documents, tool_surface, workflow_discovery, upgrade_url, service_notices). It covers edge cases (null with unavailable_reason, team/company pooling, budget sharing) and provides the full context an agent needs to interpret the response. Nothing 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 has zero parameters and the schema confirms an empty object. The description explicitly says 'takes no arguments', which is all that is needed. Since there are no parameters to document, the baseline 4 is appropriate – the statement adds clarity without redundancy.

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 returns 'Tier, capabilities, limits, and live usage for the calling identity' – a specific verb and resource. It also names the sibling tools that share the same budget (get_provision, validate_citation), preventing confusion with other metadata endpoints. The purpose is unambiguous and distinct.

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 tells the agent when to call it: 'Use this to decide what tools and fan-out paths are available before calling them, or to check remaining quota before issuing more requests'. It also explains why (avoid wasted retries, decide whether to upgrade) and that it takes no arguments. This is direct guidance on when and why to use this tool instead of siblings.

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?

Annotations declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, which already signal a safe read operation. The description adds substantial behavioral context beyond that: the national-transposition swap (returning the national provision and naming it in meta.transposition), the typed disclosure when no mapping applies, the ambiguous-candidates retry mechanism with retry_args and retry_kind, the 'Sources used' markdown table, and the meta.render_contract for evidence curation. It even cautions against inferring source_id to prevent substitution across corpora. 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?

Although the description is long, every sentence serves a purpose and the structure is exemplary. It starts with the core purpose, then systematically walks through the three addressing forms with examples, then covers edge cases (transposition, ambiguity, source_id constraints), and ends with response details. There is no filler; the length is justified by the tool's complexity and the need to prevent misuse. It is front-loaded with the most critical information.

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 complexity—three addressing forms, national transposition logic, ambiguous candidate retries, source_id constraints, and response metadata—the description is remarkably complete. It covers what the tool returns (full text, metadata, sources-used section, render contract) even though there is no output schema. It also anticipates common failure modes (law_name_unresolved, near matches) and tells the agent exactly how to recover. Nothing an agent needs to call this tool 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?

The input schema already has descriptions for all five parameters, but the tool description enriches them significantly. It explains how the parameters combine into three distinct addressing forms, gives exact examples for each, clarifies the role of jurisdiction in canonical_ref (pass it when the ref does not embed one), and imposes validity rules on source_id and the bare-source-id form. This is precisely the kind of semantic depth that helps an agent invoke the tool correctly, exceeding the baseline set by a 100% coverage 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 opens with a clear, specific statement of the tool's function: 'Look up the exact text of a specific legal provision or standards-catalog control.' It immediately distinguishes three addressing forms and gives concrete examples (e.g., 'Article 5 of GDPR', '45 CFR § 164.410', 'nist-800-53 AC-5'). This goes far beyond a vague purpose and clearly separates it from sibling tools like search, which finds rows rather than resolving exact text.

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 when-to-use guidance for each of the three addressing forms, including when to prefer search first ('For a national statute you have not seen in a search row, search first and replay that row's citation.lookup'). It also states when not to use certain parameters (e.g., 'source_id... is valid only with the hint's nonblank canonical_ref; law and article must remain empty') and how to handle ambiguity. No other tool is confused with this one.

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, and the description adds substantial behavioral context beyond that: the meaning of 'enrolled,' the freshness state taxonomy, the degraded dataset behavior with resolution_reason and anomalous_release, and the condition under which the deadlines tool refuses to serve. This fully discloses what the tool reports and how states should be interpreted.

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 well-structured into paragraphs covering source status, obligations calendar state, response shape, and an example. It front-loads the core purpose and then adds necessary interpretive context; while a bit verbose, every section serves agent decision-making.

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-parameter, read-only status tool with no output schema, the description is exceptionally complete: it defines all reported states, explains edge cases, gives the response shape, and provides an example natural-language prompt. An agent would know exactly what this tool returns and when to rely on it.

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 parameter-level semantics are not needed. The description focuses entirely on return semantics and state interpretation, which is the appropriate substitute; the baseline of 4 for a no-parameter tool 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 states a specific verb and resource: 'Report what this service actually monitors and how current each source is.' It clearly enumerates the returned dimensions (sources, freshness states, verdict, obligations dataset state), making the tool's scope unmistakable and differentiating it from generic status or freshness tools.

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, including explicitly telling callers to read it before concluding anything from an empty search and explaining it is the diagnostic surface for refused or degraded get_regulatory_deadlines calls. It does not name sibling alternatives directly, but the specialized use cases are clearly articulated.

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?

Beyond the readOnly annotation, it discloses a non-obvious behavioral caveat: counts remain whole-jurisdiction and are not domain-scoped, so they must not be reported as per-domain counts. It also explains that incomplete rows carry coverage_note and that the domain-specific signal comes from sources/frameworks.

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 every sentence earns its place: core purpose first, then usage timing, examples, return shape, and the critical count-scope caveat. The bulleted examples make scanning easy and the warning is clearly separated.

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 coverage tool with four optional parameters and an output schema, the description fully explains what the agent needs: when to call it, what each example query means, what the response contains, and an important interpretation pitfall. Nothing material 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 input schema already covers all four parameters at 100%, so the baseline is 3. The description adds value by showing exact parameter values through examples and by linking natural-language queries to parameter choices, while also reinforcing how domain affects the response semantics.

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 ('Show which countries, frameworks, and legal domains are available') and is packed with concrete example user queries that map to tool invocations. It separates list_coverage from the sibling search tool by positioning it as the jurisdiction-discovery entry point.

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 to call this BEFORE search when the user's topic doesn't name a jurisdiction, and gives five natural-language examples covering different parameters. This gives an agent clear decision criteria and names the relevant alternative (search).

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 readOnlyHint=true annotation, the description discloses determinism, unmetered access, tier-independent recommendations, snapshot freshness (fetched_at, age_seconds), explicit failure on missing/stale snapshots, and the fact that no static catalog is served as live. This substantially exceeds the annotation baseline.

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; the first sentence front-loads the purpose, and every subsequent clause adds needed operational detail. Slightly verbose for the format, but aptly sized for an interactive tool with snapshot, tier, and failure-mode nuances.

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 output schema presence and complexity, the description fully covers the iterative question/response cycle, final recommendation details, authorization visibility, snapshot metadata, and disagreement handling with list_workflow_types. Failure modes are also specified; no significant gap remains.

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 interactive usage context: all arguments optional, take values from previous question options, use ['unscoped'], and the typical invocation example. The schema already carries the detailed field descriptions, so the marginal value is useful but not transformative.

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 precise verb and resource: 'Scope a compliance workflow down to ONE concrete workflow id'. It clearly distinguishes itself from siblings by stating it answers what the catalog cannot and explicitly contrasts with list_workflow_types. The return behavior (question vs recommendation) is also specified.

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 when-to-use and when-not-to-use guidance: call with any known info, use list_workflow_types and start_workflow directly for unlisted frameworks, and re-scope on registry changes. Includes a concrete typical opening example with parameters.

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=true and destructiveHint=false, and the description goes far beyond that: it discloses strict-miss semantics (meta.outcome='NO_STRICT_MATCH'), withheld relaxed matches, daily quotas, concurrency limits, ranking/companion-row behavior, and error contracts (unresolved_scope, query_too_long). This is unusually rich behavioral context.

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 critical constraint (at least one scope axis is required) is front-loaded, which is good, but the body is enormously oversized for a single search tool and repeats material already present in the schema and in meta-field documentation. Many sentences document downstream response contracts rather than what an agent needs to select or invoke this 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 12-parameter, no-output-schema tool with complex tiering and recovery flows, the description is more than complete — it covers scope resolution, query shaping, miss handling, budgets, and ranking. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents each parameter; the baseline would be 3. The description nonetheless adds non-schema meaning — e.g., the query-length refusal, OR-vs-AND handling, broadening semantics tied to allow_broadening, and the cross-axis intersection rule for jurisdictions+sectors — so it exceeds the 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?

The opening line states the core function — a keyword search that requires at least one jurisdiction/framework/sector/source scope — and explicitly distinguishes itself from siblings by noting there is no separate search_case_law or search_preparatory_works tool and that search_guidance handles guidance alone. It is a clear verb+resource, though the purpose is buried under a very long protocol body.

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?

Usage is exhaustively covered: explicit query-shape rules (one concept per call, bare OR for synonyms only, AND/NOT/NEAR stripped), tier limits, when to use sources vs jurisdictions, and how to respond to each recommended_action. Alternatives and when-not-to-do-things (never broaden unprompted) are stated.

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 only say readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description carries the real behavioral burden and does so richly: it discloses that starting SPENDS a run, that a cancel does not refund runs on free/solo, that questions_for_user is advisory while requires_user_input=true gates are server-enforced, that the workflow_type enum is caller-authorized only when a fresh registry snapshot exists, and that output can be JSON or watermarked html/pdf. This adds substantial context beyond the annotations with no contradiction.

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 and dense — roughly 300 words across several clauses — and is not a model of brevity. However, every sentence earns its place given the tool's complexity: tier-fencing, variant catalogs, run allowances, and advisory-vs-enforced input gates all need to be stated. The core purpose is front-loaded in the first sentence, and the parameter/semantic details follow logically. Slightly over-length but justified; not padded.

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 elaboration. The description covers prerequisites (list_workflow_types first, get_my_capabilities for allowance), tier restrictions, run-allocation consequences, the input-gate model, and output formats. For a stateful, tier-fenced workflow launcher with side effects, everything an agent needs to call it correctly is present. Nothing material 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 adds genuine value: it explains that workflow_type must come from list_workflow_types rather than guessing from an example, that the enum is caller-authorized and may degrade to a string, and that the base gap_analysis type requires a framework. It also clarifies the framework argument accepts only nis2/dora/cra/eu_ai_act on free/solo. This exceeds baseline by tying parameters to the live-registry semantics.

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 begins with a specific verb+resource ('Begin a structured workflow selected from the live workflow registry') and enumerates the exact catalog covered — threat/privacy modeling, risk/TARA, DPIA/FRIA, gap analysis, SORA, etc. It distinguishes itself from siblings like list_workflow_types (the authoritative id source) and list_workflows. An agent can clearly tell what this tool does and what it is not.

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 instructs 'Call list_workflow_types first' and names get_my_capabilities as the check for remaining allowance, and cancel_workflow as the companion. It gives tier-fencing rules (free/solo seven types, Premium adds the interview-grounded catalog, Team/Company required for document review/tender/adversary), which routes the agent to the correct usage path. It even mandates getting user OK before calling — explicit when-to-use guidance with named alternatives.

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 and destructiveHint=false, but the description adds significant behavioral context: it confirms the citation resolves in the served corpus rather than asserting real-world legal status, explains the response returns current served text, and describes the output structure including the 'Sources used' section and meta.render_contract. This goes far beyond the annotations and sets accurate 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 front-loaded with the primary purpose and is information-dense. However, the final sentence is a long, run-on construction that combines the 'Sources used' section, the zero-result note, and meta.render_contract into a single sentence. It is still efficient, but slightly less crisp than a fully bulleted or shorter structure would 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?

Given that there is no output schema, the description does a thorough job of explaining what the response will contain: current served text, a 'Sources used' table, a zero-result note, and meta.render_contract. It also covers limitations and alternatives, making it complete for an agent to know when to use the tool and what to expect.

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 parameters law, article, and jurisdiction are already fully described in the schema. The description does not add any parameter-specific meaning beyond what the schema provides; it discusses the overall behavior but not the semantics of individual arguments. This meets the baseline but does not exceed 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 opens with 'Verify a legal citation against the served corpus', which is a specific verb+resource+method. It clearly distinguishes from siblings by stating what it does NOT do (assert legal in-force status, consult amendment feeds) and explicitly names 'diff' as the alternative for provision-level change comparison. This fully differentiates it from tools like get_provision or search.

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 when to use the tool: "Use this when someone asks 'is this citation correct' or 'check whether Article 28 GDPR still says this'". It also provides an exclusion by noting it does not assert legal in-force status and does not consult amendment feeds, and it names 'diff' as the alternative for provision-level changes. This is clear, actionable guidance.

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

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

Annotations 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?

Beyond the readOnlyHint, openWorldHint, and destructiveHint annotations, the description explains source-pinned lookup, producer identity checks, byte-for-byte comparison, verdict semantics, stale-feed refusal behavior, attestation provisions, and tier restrictions. This gives an agent a rich, accurate picture of what will and will not happen.

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, but the density is justified by five distinct lookup lanes, many verdicts, freshness rules, and tier semantics. It is front-loaded with purpose and contains little filler, though the single unbroken block of text makes scanning harder than a structured format would.

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?

Everything an agent needs to invoke this tool correctly is present: verdict vocabulary, lane routing rules, coverage and freshness behaviors, authentication and tier requirements, quotas and concurrency, and explicit boundaries. With an output schema also available, no critical operational detail 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 complete, but the description adds essential meaning: source_id must be the routed corpus id rather than the citation's mcp_server, reference semantics differ by lane, empty quotation is a refusal rather than a mismatch, and quotation length rules are elaborated. This materially improves correct invocation beyond the schema alone.

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 the tool 'Verify submitted legal citations against what this gateway actually serves' with a clear resource and goal, and the verdict list makes its behavior concrete. However, it does not explicitly distinguish itself from the sibling tool validate_citation, which likely overlaps in purpose, so it misses the top tier for sibling differentiation.

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 the tool applies, including limits, quota effects, tier-gated attestation, and explicit exclusions such as 'First-party doc:// document pinpoints are not verified here' and KEV/EPSS quotations not being verified on the CVE lane. It does not name alternative sibling tools or provide direct 'use X instead' guidance, so it stops short of a 5.

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