Distributed Risk desk

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine behavioral value by disclosing that this is an aggregation over four upstream sources (CVE.org, CISA SSVC/KEV with federal due date, FIRST EPSS, internal AI-stack classification) in one answer, which tells the agent it need not fan out to get_kev/get_epss style calls. It does not cover behavior on unknown CVE IDs or partial upstream availability.

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

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

A single front-loaded sentence that opens with the outcome ('Everything the record says about one CVE, in one answer') and then enumerates the payload. Zero filler, though the long comma-chain of sources is slightly denser than it needs to be and could have been split for scannability.

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 carries the burden of explaining returns — and it does so thoroughly by naming each data block. Only gaps are the not-found / partial-data case for a single-ID lookup tool with an openWorld hint.

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

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

Schema coverage is 100% and the schema already supplies the CVE-ID pattern plus a worked example (CVE-2025-62593), so the description adds nothing about the format. It only reinforces that exactly one CVE is fetched. 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?

States a concrete resource and scope: the full record for exactly one CVE, with the specific data categories returned (CVE.org record, SSVC, KEV, EPSS, AI stack membership). This makes it distinguishable from retrieval siblings like search_kev and list_ai_stack_vulnerabilities by shape, though it never names an alternative explicitly.

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

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

Usage is only implied: 'one CVE' plus a required single-ID parameter signals 'use when you already have a CVE ID', but there is no explicit when-to-use, when-not, or pointer to the search/list siblings for discovery workflows. An agent can infer the entry condition but gets no routing guidance.

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

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

Annotations already establish that this is a safe, idempotent, non-destructive read. The description adds useful behavioral detail by saying the response is full Markdown with numbered sources and links to the official record.

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?

It is a single front-loaded sentence with no wasted language. The core return shape is stated immediately.

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-item read tool with full schema coverage and clear annotations, the description is complete enough. Since there is no output schema, it helpfully states the response format and included links.

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 single slug parameter is already documented as coming from list_notes or search_notes. The main description does not add syntax or example guidance beyond that schema-level meaning.

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

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

The description clearly identifies a single note being returned in full as Markdown, along with numbered sources and official-record links. The word 'One' implies a single-item read versus list/search siblings, but it does not explicitly name those alternatives.

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

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

Usage is only implied: fetch a full note when you have a note slug. The description does not explicitly say when to use this instead of list_notes or search_notes, though the schema separately notes the slug comes from those 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?

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds useful result context: no-rate mode returns the latest of each rate, while with-rate mode returns N days including percentiles, volume, and the EFFR target range.

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

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

A compact single sentence that front-loads the resource and conditional behavior, with no filler. The dense acronym list and semicolon clause make it slightly harder to parse, but it remains efficient.

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, but the description sketches returned content in both query modes and lists all rate options. With rich annotations and complete schema coverage, an agent has enough to call it correctly, though exact response structure and sibling routing are left unstated.

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 both parameters are already fully documented. The description mostly restates those schema semantics and adds return-content context rather than new parameter meaning.

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

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

Names the New York Fed reference rates and enumerates all covered rate types, making the resource scope clear. It lacks an explicit verb in the description and does not distinguish itself from the sibling get_treasury_yields, so it stops short of full sibling differentiation.

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

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

Provides conditional usage for the rate parameter: omit rate for the latest of each, include a rate for its last N days. It never states when to choose this tool over get_treasury_yields or other financial-data siblings, so tool-selection guidance is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context the annotations lack: that results are ordered newest-first and that coverage spans tenors from 1 month to 30 years. It says nothing about source freshness, caching, or business-day gaps.

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 short sentences, front-loaded with what is returned and immediately followed by how to shape the request. No filler, though the parenthetical example is slightly redundant with the schema.

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

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

With no output schema, the description carries the burden of describing the return, and it does so at a high level (yields keyed by tenor, newest first). For a two-optional-parameter read tool with rich annotations, that is nearly sufficient; row-level shape and units (percent) are the only 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 coverage is 100% and the schema itself documents both parameters, including tenor naming and the 1-30 day bound. The description's example tenor list (["2 Yr", "10 Yr"]) largely restates the schema's examples rather than adding format or edge-case guidance.

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

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

States a specific resource (Treasury daily par yield curve) with its shape (yields by tenor, 1 Mo to 30 Yr) and ordering (newest first). It never names a sibling such as get_reference_rates, which is the nearest overlap, so differentiation is left implicit.

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

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

"Ask for the last N days, and optionally only some tenors" describes how to use the parameters rather than when to choose this tool over get_reference_rates or other rate-like siblings. No exclusions or preconditions are stated.

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

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

Annotations already declare read-only, idempotent, open-world behavior, so the description does not need to re-establish safety. It adds real context beyond that: the default window is 14 days reaching back 30, malicious-package reports are returned ahead of vulnerabilities, and KEV entries are folded in. Return fields (package, severity, fixed versions, CVEs, EPSS, advisory) are also disclosed, though pagination/truncation behavior is not.

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 core scope and ordering rule, with the long ecosystem list kept as a parenthetical clause. Dense but every clause carries scope information; it could tighten the model-name enumeration slightly.

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

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

No output schema exists, so the description's enumeration of returned fields (package, severity, fixed versions, CVEs, EPSS, advisory) is necessary and present. Default window and KEV inclusion are covered; the main remaining gap is what limit does to results when the feed exceeds it, and no pointer to sibling advisory tools.

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

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

Schema coverage is 67%, so the schema carries most parameter meaning. The description adds taxonomy for the layer enum (agent frameworks, gateways, MCP, model serving, ML platforms, model libraries, AI apps, coding agents) and explains include_kev behavior implicitly ('CISA KEV entries in the same stack are included'). It adds nothing about limit, package, or since beyond what the schema already states.

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

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

States a specific verb (list) and a precisely scoped resource: new advisories against AI/agent stack software, with the ecosystem enumerated (LangChain, LiteLLM, MCP, vLLM, MLflow, etc.). This makes it clearly distinct in substance from the generic list_cyber_advisories sibling, though the sibling is never named to make the boundary explicit.

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

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

Usage is implied by 'new advisories' and the ordering rules (newest/most severe first, malicious-package reports first), which tells the agent what the feed emphasizes. However, there is no explicit when-to-use / when-not-to-use guidance and no pointer to list_cyber_advisories or get_cve for overlapping needs.

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

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

The annotations already establish that this is a safe, idempotent read-only operation. The description adds useful behavioral context by stating that results are newest first and by listing the fields returned for each advisory. It does not discuss rate limits, auth, or whether multiple filters combine.

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 resource and ordering, then efficiently covers the advisory types, return fields, and filters. Every sentence carries useful information and there is 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?

There is no output schema, but the description names the key returned fields and gives ordering, while the schema and annotations cover parameters and safety behavior. It leaves some gaps, such as how multiple filters combine and whether results are paginated beyond the limit parameter.

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

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

Schema description coverage is 80%, so the schema already documents most parameters, including kind, query, since, and ai_stack. The description maps the filters in natural language but adds no syntax, defaults, or constraints beyond the schema, and it does not mention limit.

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 identifies the resource as CISA cybersecurity advisories and enumerates the advisory kinds, so an agent can understand what it returns. It does not explicitly differentiate this tool from siblings such as list_ai_stack_vulnerabilities or list_cyber_incident_filings, which keeps it below a 5.

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 says what can be filtered, but gives no explicit guidance on when to use this tool versus sibling tools, nor when not to use it. Usage is only implied by the filter list, not stated as a selection rule.

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 the safe read-only, idempotent, open-world profile, so the description's job is to add context — and it does: it discloses sort order, the default inclusion of non-material Item 8.01 reports, and the exact fields returned per filing. It stops short of stating pagination or result-count behavior, which keeps it off a 5.

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

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

A single dense but well-ordered sentence: resource, sort order, item semantics, then the returned field list. Nothing is repeated and every clause carries information the agent cannot get from the schema.

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

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

With no output schema, enumerating the returned fields (company, tickers, dates, items, state, industry code, EDGAR link) is exactly the right compensation, and the 90-day default plus the 2023-12-18 Item 1.05 start date are covered by the schema. Only pagination/total-count behavior is left unstated for this five-parameter list 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 coverage is 80% and the schema already documents query, since, until and material_only. The description adds real meaning by explaining the Item 1.05 vs 8.01 distinction that material_only operates on ('unless excluded'), so an agent understands what filtering that boolean actually removes.

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

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

States a specific resource (cybersecurity incidents on SEC Form 8-K), the item types covered (Item 1.05 and Item 8.01), and the ordering (newest first). It is clearly distinguishable from the advisory/CVE siblings, which cover a different corpus entirely.

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

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

The description implies use ('incidents public companies report') and hints that Item 8.01 filings are included 'unless excluded', which points at the material_only filter, but it never states when to prefer this over siblings like list_cyber_advisories or search_federal_register, and gives no exclusions or prerequisites.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add beyond that, which it does: it discloses sort order and the meaning of total and next_offset. It stops short of anything like rate limits or result-set ceilings beyond the schema's maximums.

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 dense sentences, with the resource and ordering front-loaded and no filler. The second sentence packs pagination and filtering together a bit hastily, but every clause carries 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?

With no output schema, the description usefully enumerates returned fields and pagination metadata, which is the main gap it needed to fill. It omits any mention of the date-based 'since' filter, a minor but real omission given five optional parameters.

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

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

Schema coverage is 100%, so baseline is 3; the description earns a bump because it explains pagination response fields (total as matching count, next_offset as next page) that the schema cannot convey in the absence of an output schema. The filter semantics themselves are mostly restated from the schema, and the 'since' parameter is not mentioned at all.

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

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

States a specific resource (published desk notes), the ordering (newest first), and enumerates the returned fields, so an agent knows exactly what it gets. It does not explicitly differentiate itself from search_notes or get_note, which is the only thing keeping it from a 5.

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?

Filtering by topic or reader is mentioned and pagination is explained, giving an implied usage context. However, there is no explicit guidance on when this list should be preferred over search_notes, and no exclusions or prerequisites are stated.

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

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

Annotations already declare the read-only, idempotent, open-world, non-destructive profile. The description adds useful behavioral context: results are newest first, each item includes its date, categories, and official page link, and the content spans several OFAC action types. It does not discuss rate limits, pagination, or the recency-window limitation, but the annotations lower the burden.

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 dense sentences: the first front-loads what the tool returns and how it is ordered, the second states the available filtering. There is no redundant or filler language.

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 listing tool with robust annotations and no output schema, the description does a good job explaining the returned item structure and ordering. The main omission is the limit parameter's default/max and how it interacts with pagination, though the schema supplies its numeric constraints.

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 description echoes the intent of the query and since parameters ('filter by date or words in the title'), while the schema provides the detailed syntax and limits. The limit parameter has no description in the schema and is not addressed by the tool description, so partial compensation for the 67% schema coverage is missing.

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 resource: OFAC recent actions, ordered newest first, and enumerates the content types (designations, removals, licenses, FAQs, regulations, settlements). This is specific enough to distinguish it from siblings like search_federal_register or search_screening_lists, though it does not explicitly name those alternatives.

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 only usage-like statement is 'Filter by date or words in the title,' which describes parameters rather than when to choose this tool over alternatives. There is no explicit guidance on when to use it versus sibling search tools, nor any exclusions or prerequisites.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the bar is lower; the description still adds useful context by disclosing sort order ('most recently updated first') and the shape of returned records. It stops short of noting pagination or rate-limit 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?

Two sentences, zero waste: the first front-loads what is returned and its ordering, the second lists the filters. Every clause 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 no output schema, the description helpfully enumerates returned fields, making the tool callable without further guesswork. The only gap is the undocumented 'limit' parameter and no hint about result volume, which is minor.

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?

Description names three of the four filters and clarifies level semantics ('level (1 to 4)'), complementing the schema's 75% coverage. It says nothing about the 'limit' parameter, which the schema leaves with only constraints and no 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?

States a specific verb+resource ('US State Department travel advisories') and even enumerates the returned fields (country, level, summary, official page) and ordering. The domain is clearly distinct from siblings like list_cyber_advisories, though it does not explicitly name any sibling.

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 clause 'Filter by country, minimum level or update date' implies how to narrow results but gives no when-to-use/when-not guidance or alternative tools. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real value by disclosing what a hit contains (title, type, agencies, publication and effective dates, citation, abstract, official link), which matters because there is no output schema. It stops short of mentioning pagination, total counts, or ranking behavior beyond the order enum.

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 resource and document types, followed immediately by the narrowing options. The field list is dense but each item earns its place given the absence of an output schema.

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

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

For a six-parameter search tool with no output schema, the description covers both the corpus and the result shape well. Remaining gaps are the default page size, how ordering interacts with relevance, and whether results are truncated or counted.

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 67%, so the schema already documents term, type, since and agency, including the agency slug examples that the description repeats. The description adds nothing about limit (default 5, max 20) or order (newest vs relevance) semantics, so it neither compensates for nor extends the schema meaningfully.

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 ('Search Federal Register') and enumerates the document classes covered (rules, proposed rules, notices, presidential documents) plus the returned fields, so the agent knows exactly what corpus is queried. It does not explicitly contrast itself with siblings such as list_ofac_actions or search_screening_lists, so it lands at 4 rather than 5.

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?

'Narrow by agency ..., type or date' implies how to scope a query, but there is no statement of when this tool is the right choice versus the sibling list_* / search_* tools, nor any exclusion or prerequisite. Usage is inferable but not guided.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description adds the non-obvious result ordering ('newest first') and the full field projection including EPSS and ransomware flags. It stops short of describing pagination or what a truncated 10-item default means for completeness.

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

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

Two sentences: the first packs catalog identity, ordering and output fields; the second packs usage modes and the sibling hand-off. Front-loaded with the resource, zero filler.

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

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

With no output schema, the description usefully enumerates what comes back (CVE, vendor, product, dates, ransomware flag, required action, EPSS, AI-stack flag). Combined with the stated lookup modes and the get_cve alternative, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 83%, so the schema already documents cve, query, since, ai_stack and ransomware. The description maps lookup modes onto those parameters but says nothing about 'limit' or 'ransomware', and adds no format or combination detail beyond the schema text. Baseline 3 for high 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?

States a specific verb ('search') and resource (CISA's KEV catalog) plus the exact return fields, and explicitly separates the tool from get_cve. An agent can identify both the tool's domain and its scope without opening the schema.

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

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

Enumerates the four concrete invocation modes (single CVE, vendor/product words, since-a-date, AI-only) and names the alternative tool with its selecting condition: 'For one CVE in full, use get_cve.' No inference required.

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 read-only, idempotent, closed-world behavior, so the description isn't carrying the safety burden. It still adds real value by disclosing the 'published only' filter and the strict AND-matching rule ('every word'), which are not visible in annotations.

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

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

A single front-loaded sentence with the key matching rule stated first; the parenthetical examples are compact and useful. Marginal clutter from the long example list, but nothing wasted.

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 search with no output schema, the description covers matching behavior and the published-only constraint. Only minor gaps remain: default result count and what shape results take are left implicit.

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 50%: `query` is documented in the schema with an example, but `limit` is undocumented in both places. The description contributes matching semantics (AND across title/summary/sources/body) beyond the schema, but says nothing about the limit 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?

States a specific verb+resource ('Find published notes') and adds scope detail: all query words must match, and the searchable fields are enumerated. It is clearly different from get_note (single fetch) and list_notes (enumeration), though it never names those siblings explicitly.

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

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

Usage is implied — this is the keyword-lookup path into the notes corpus — but there is no explicit guidance on when to prefer it over list_notes or get_note, nor any note that the query is required or that results are limited.

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?

With readOnly/idempotent/openWorld already declared in annotations, the description adds real context: matching is fuzzy ("close spellings match"), each hit includes list, programs, addresses, IDs, remarks and an official link, and the response reports list freshness. It stops short of noting rate limits or result truncation 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?

Front-loaded with the resource and its list coverage, then matching behavior, then return shape — a logical order. The parenthetical list enumeration is long but genuinely load-bearing, not 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?

No output schema exists, and the description covers what results contain and what the freshness signal says, filling that gap. For a 6-parameter read-only search, the only omission is pagination/limit guidance, which is minor.

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

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

Schema coverage is 67%, but the description compensates by specifying that `query` accepts aliases and concrete identifier types (IMO, SWIFT/BIC, registration number) — information not present in the schema. It does not clarify `type`, `limit`, or `min_score` behavior beyond the schema's own text.

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?

Specific verb (search) plus the exact resource (Consolidated Screening List) and an explicit enumeration of the constituent lists (OFAC SDN, BIS Entity/DPL/UVL/MEU, State ITAR). It is clearly distinguishable from sibling list_ofac_actions, which covers enforcement actions rather than screening entries.

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

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

Usage is strongly implied — search by name, alias or identifier — and the fuzzy-match behavior hints at the intended lookup workflow. However, it never states when to prefer this over list_ofac_actions, nor any exclusion or prerequisite, so the agent must infer the boundary.

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