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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses extensive behavioral details: tier-aware output, TTL-cached workflow registries, error behavior for invalid detail/section, service notices, catalog drift handling, and the exact meaning of `available_to_caller` flags. This goes far beyond what annotations provide and gives the agent a clear model of the tool's runtime 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 a single, very long paragraph with many clauses and nested details. While dense with information, it lacks clear structure (e.g., bullet points, separate paragraphs for different options). It is not front-loaded; the crucial summary is followed by a wall of edge cases. The sheer length makes it hard to parse, even though the content is relevant.

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 (2 params, 0 required, output schema, annotations), the description covers all relevant aspects: what each detail and section returns, error cases, tier-awareness, caching, and relationship to sibling tools. It is comprehensive and leaves no major gaps for an agent to 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?

Although the schema descriptions are already detailed (100% coverage), the tool description adds significant semantic value: it explains the interaction between detail and section, the validation order, the size implications of 'full' (>100k chars), and the behavior of unknown sections. This enriches the parameter meaning beyond the schema's basic 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 clearly states the tool's purpose: 'Discover what Ansvar can do for your agent.' It is a read-only capability discovery tool, distinct from siblings like get_my_capabilities (live tier/quota only), which is explicitly mentioned. The verb 'describe' and resource 'capabilities' are specific and differentiate it from other 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 detailed usage guidance, including default vs. full detail, section filtering, and error handling precedence. It also names the companion tool get_my_capabilities, implying when to use this tool versus that one. However, it does not explicitly state 'when not to use' or compare with other sibling tools beyond that one reference.

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?

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?

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, but the description adds substantial behavioral detail: counters reset at UTC midnight, per-worker semantics with N-worker gateway aggregation, service_notices for degraded subsystems, and the conditional presence of workflow_discovery and upgrade_url. This goes far beyond the annotations and fully discloses the tool's runtime 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 long but exceptionally well-structured: a one-sentence summary, followed by concrete usage guidance, then a detailed but organized breakdown of the JSON fields using semicolons and descriptions. Every sentence adds value (reset timing, per-worker semantics, degraded state handling). It is front-loaded with the core purpose and usage, making it 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?

Despite having an output schema, the description goes beyond it by explaining semantics like 'remaining_quota' being live and per-worker, 'workflow_discovery' being present only when a run can be started, and 'service_notices' listing affected tools. It also covers edge cases (company tier upgrade_url empty, team/company budget pooling). This is complete for a complex introspection 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?

With zero parameters, the schema is trivially 100% covered and baseline is 4. The description explicitly states 'takes no arguments,' which confirms the empty schema. It also adds meaning by explaining what the response contains (tier, capabilities, limits, usage), though that is output semantics rather than parameter semantics. No further parameter clarification is needed.

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 'Tier, capabilities, limits, and live usage for the calling identity,' which clearly and specifically states the tool's purpose. It distinguishes this tool from siblings by emphasizing the 'calling identity' introspection and by explicitly noting in the workflow_discovery section that related calls (list_workflow_types, describe_capabilities, start_workflow) are separate paths. 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?

Explicit guidance is given: '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 explains the benefit of avoiding wasted retries and deciding on upgrades. It also clarifies that workflow type ids come from list_workflow_types, not from this call, providing a clear exclusion. This fully satisfies when and when-not to use.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe, read-only nature is known. The description adds value by specifying that the tool 'Returns completed and remaining steps with a progress percentage and quality score,' giving insight into the output structure and behavior beyond annotations.

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

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

The description is concise and well-structured: purpose statement, usage examples, and output summary in three short sentences. There is no fluff or redundancy, and the most important information is front-loaded.

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

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

For a simple read-only tool with one parameter and an output schema, the description adequately covers purpose, when to use, and what to expect in return. It is complete enough for an agent to select and invoke the tool correctly.

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

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

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

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

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

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

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

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

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

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

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

The description adds substantial behavioral context beyond the readOnlyHint and destructiveHint annotations: it explains national transposition swapping, the 'Sources used' audit receipt, meta.render_contract, and the strict requirement to replay hint values to avoid corpus substitution. These are non-obvious behaviors that meaningfully shape how an agent invokes the tool.

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

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

The description is dense but well-organized with numbered addressing forms and inline examples. Every sentence contributes meaningful guidance, though the length is substantial for a tool description. The front-loaded purpose and clear segmentation help mitigate the verbosity.

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 and lack of an output schema, the description fully covers return values (full text, citation metadata), the 'Sources used' section, meta.render_contract, and edge cases like national transposition and non-jurisdictional catalogs. It leaves no obvious gaps for an agent to resolve provision lookup 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?

Although schema coverage is 100%, the description enriches parameter understanding far beyond the schema. It explains the relationships between law, article, canonical_ref, source_id, and jurisdiction, provides replay rules, and clarifies when each is required or forbidden. This transforms bare parameter definitions into actionable composite usage patterns.

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 'Look up the exact text of a specific legal provision or standards-catalog control,' using a specific verb and resource. It clearly distinguishes from sibling tools by detailing the three addressing forms and explicitly referencing search-row hints, which delineates it from search and other lookups.

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 addressing form, including concrete examples like 'show me Article 5 of GDPR' and the specific shape for NIST corpora. It also states what not to do ('Do not infer source_id from the legal document id') and clarifies when alternative forms apply, such as passing jurisdiction alongside canonical_ref when not embedded.

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 readOnlyHint and destructiveHint annotations by explaining the meaning of key statuses ('enrolled' requires cleared verdict AND verified proof), the possible values of dataset_state ('ok', 'degraded', 'unavailable') with their implications, and what fields like resolution_reason and degraded_since represent. This is 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 description is longer than strictly necessary but well-structured: the first sentence states the core purpose, the second paragraph clarifies a crucial interpretation caveat, and the third paragraph details a related subsystem. Some phrasing ('free surface for a premium tool') is slightly embellished, but every sentence provides meaningful 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?

In the absence of an output schema, this description carries the full burden of explaining the return values. It covers all major output categories (sources, freshness, enrollment, licensing, obligations calendar), enumerates the possible states, and gives an example user query. This is exceptionally complete for a zero-parameter status 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?

The input schema has zero parameters and the description correctly does not attempt to explain parameters. It instead clarifies the meaning of the tool's output, which is the only semantics that matter here. The baseline for 0 params is 4, and the description adds value beyond the empty 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 specific verb and resource: 'Report what this service actually monitors and how current each source is.' It clearly enumerates the report's contents (enrolled sources, freshness states, licensing verdict, obligations calendar) and distinguishes itself from sibling tools by focusing on regulatory intelligence status specifically.

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 when-to-use guidance: 'Read this before concluding anything from an empty search' and explains how callers whose deadlines request was refused or degraded can use this tool to understand why. However, it does not explicitly contrast against alternatives or state when not to use it.

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?

The description adds important non-obvious behavior beyond the read-only annotation: laws/provisions counts are whole-jurisdiction totals even under a domain filter, with count_scope=whole_jurisdiction, and only sources/frameworks are domain-scoped. This prevents the agent from misreporting counts. 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 dense but tightly organized: purpose, usage rule, examples, return shape, and a critical measurement warning. Each sentence adds value, and the examples are compact and illustrative rather than 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?

For a read-only exploration tool with an output schema and rich input descriptions, the description covers the return structure, edge-case semantics, and the relationship to sibling search. It gives the agent everything needed to invoke and interpret 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?

Although the schema already describes all three parameters at 100% coverage, the description adds practical semantics: accepted alias values ('drone'/'uas'), example invocations, and the key caveat that domain only narrows jurisdiction/source lists, not counts. This goes beyond the schema 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 clearly states the tool 'shows which countries, frameworks, and legal domains are available', using a specific verb and resource. It distinguishes itself from siblings by explicitly positioning it as a pre-search coverage/discovery tool that returns jurisdictions.

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 an explicit directive: 'Use this BEFORE calling search when the user's topic doesn't name a jurisdiction', and instructs how to handle the returned jurisdictions. Concrete examples with query patterns make the invocation conditions unambiguous.

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

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

Annotations already declare readOnlyHint=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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful constraints: 'Single-MCP diagnostic dispatch' (no fan-out) and the mcp:probe scope requirement. It does not detail error behavior, but the schema covers the unknown-id error.

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, front-loaded with the core purpose, then providing scope and restriction. Every sentence 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 only two required parameters, and an output schema exists. The description conveys the essential purpose, timing, and access restriction, which is sufficient given the rich schema and annotations. It could mention error behavior, but that is already 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?

Schema description coverage is 100%, so the baseline is 3. The tool description itself contains no parameter-level guidance; all parameter semantics are already in the input schema. The extra 'Keep to plain concept terms' note appears in the schema, not the tool description, so no additional value is added.

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 with a specific verb ('Test') and resource ('a specific data source'), and explicitly contrasts it with 'running a full search'. This distinguishes it from sibling tools like search and batch_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 provides clear context on when to use the tool ('before running a full search') and includes an important restriction ('Not for customer use — requires mcp:probe scope'). It does not explicitly name alternative tools, but the timing and scope are well specified.

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?

Adds extensive behavioral context beyond annotations: tier limits, query shaping rules (FTS5 implicit AND, OR handling, CJK spacing), strict miss behavior (meta.outcome, broadening advice), and scope interaction (intersection of jurisdictions and sectors). Annotations only provide readOnlyHint and destructiveHint, which the description reinforces without 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 very long (over 1500 words) and includes many details, examples, and edge cases. While all information is valuable, it lacks conciseness and is not front-loaded effectively. The structure is somewhat jumbled, mixing tier limits, query shaping, and error handling without clear sections. A more streamlined version would improve agent usability.

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 (7 parameters, no output schema, many edge cases), the description is remarkably complete. It covers scope requirements, tier limits, query shaping, strict miss behavior, broadening, CJK scripts, and error handling. It also describes the response structure (meta fields, Sources used section). No gaps are evident for the intended use 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?

With 100% schema coverage, the description still adds significant value: explains limit clamping, query language details, maximum values for sectors (5) and jurisdictions (10), and the interaction between parameters (e.g., intersection of jurisdictions and sectors). The description provides context that the schema alone does not, such as the error behavior for mixed scopes.

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?

Description clearly states the tool's purpose: 'Find laws and regulations on a specific topic.' It distinguishes from siblings like batch_search, search_by_product, and search_cve by focusing on legal/regulatory content. It also explicitly mentions the alternative search_guidance tool for agency guidance alone, reinforcing 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?

Explicit guidance on when to use: 'when someone asks what does the law say about X in country Y' or 'which regulations cover Z'. Includes when-not-to-use: license questions need explicit sources, and for guidance only use search_guidance. Also advises calling list_coverage first for topics without a country. Provides clear context 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?

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 only indicate readOnlyHint=false and destructiveHint=false; the description adds that starting 'SPENDS a run from the monthly allowance' and that cancellations don't refund on free/solo tiers. It also explains the dynamic enum behavior (caller-authorized vs string) and the server-enforced human-input gate. This is substantial behavioral context beyond the structured fields, 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 comprehensive but dense, packed into one long paragraph with many conditional clauses. It is not broken into sections, and the critical call-list_workflow_types-first guidance is buried mid-paragraph. However, each sentence contributes necessary operational detail, which is justified given the tier and run allowance complexity.

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 tier fencings, run accounting, dynamic enums, and step-gate behavior, the description covers all required concepts: registry, variants, alternatives, quotas, and outputs (JSON or watermarked reports). An output schema exists to detail return values, so omission is acceptable. It gives the agent everything needed to decide when and how to call.

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 critical semantics: workflow_type is an exact id from list_workflow_types, not a guess, and the enum is caller-authorized with a stale-catalog caveat. It explains the framework argument's tier restriction to four values and the default behavior. Entity_description is described as grounding the first steps, adding to schema explanations.

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 'Begin a structured workflow selected from the live workflow registry,' clearly identifying a specific verb and resource. It distinguishes from sibling tools like list_workflow_types and cancel_workflow by focusing on starting, not listing or canceling. The registry coverage enumerates many workflow families, making the tool's scope 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?

It explicitly instructs to 'Call list_workflow_types first' as the authoritative source for ids and availability, and to check get_my_capabilities and obtain user approval before spending a run. It explains tier restrictions and run consequences, giving clear when-to-use and pre-call steps. No explicit 'when not to use' but alternatives are implicitly covered through the referral to sibling tools.

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.