sanctions

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

Annotations already indicate readOnlyHint and openWorldHint. The description adds valuable behavioral context about the exact-ID lookup and the fuzzy-match fallback with name, which goes beyond the structured data. No contradictions.

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 concise sentences, front-loaded with the core purpose and followed by usage guidance. 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?

For a simple lookup tool with only two parameters and no output schema, the description adequately covers the main usage and fallback behavior. It does not explicitly state the return format, but given the simplicity, the context is largely complete.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description's mention of 'pass `name` to also fuzzy-match if no direct hit' mirrors the schema's existing description, adding little new semantic value. 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: 'Check whether a Czech IČO (or any company by IČO) appears on sanctions lists.' It uses a specific verb and resource, and the distinction from siblings like search_entity/search_person is evident because it focuses on IČO-based sanctions lookup.

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: 'Direct exact-ID lookup; pass `name` to also fuzzy-match if no direct hit.' This indicates it's for cases where you have an IČO, but it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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

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

Annotations provide readOnlyHint and openWorldHint, already indicating a safe, open-world read. The description adds that it returns the 'full record', which is useful behavioral context about the response. The ID format is also meaningful 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?

A single, well-structured sentence that is front-loaded with the action and resource. Every piece of information (ID format, examples) is directly useful and not redundant with the schema or annotations.

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 retrieval tool with readOnly annotations, the description is complete. It specifies what it does, how to identify the listing, and the scope of the return ('full record'). No output schema is needed for this simplicity.

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 id property already includes an example, but the description goes further by stating the general pattern (`${source}:${source_list_id}`) and giving a second example (eu:EU.123.789), adding clarity beyond the schema alone.

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

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

The description clearly states the action ('Retrieve'), the resource ('full record for a single sanctions listing'), and the method ('by its ID'), distinguishing it from sibling search/check tools. The specific ID format and examples make the purpose 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 makes it clear that this tool is for retrieving a listing when an ID is known, with the format requirement. It does not explicitly contrast with search tools, but the context signals (sibling names like search_entity) imply those are for discovery vs. this for direct lookup.

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 provide readOnlyHint: true, so the safety profile is known. The description adds that updates can be added/removed/modified, but it does not disclose return format, pagination, or any limitations (e.g., openWorldHint implications). It adds some context beyond annotations but not rich 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 two sentences: the first states the function, the second states the intended use. Every word earns its place, 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?

The tool is a simple list operation with two well-documented parameters and read-only annotations. The description explains what it does and when to use it. It lacks a mention of response structure, but for a filtered-list tool with strong schema coverage, this is reasonably complete.

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

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

Schema description coverage is 100%, with both 'since' and 'source' having descriptive text. The description's phrase 'since a given date' aligns with the schema but adds no new semantic information 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 lists sanctions updates (added/removed/modified) since a given date. This is a specific verb+resource+time scope, and it distinguishes from sibling tools like search_entity or check_ico, which serve different purposes.

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 advises 'Use for daily monitoring against a watchlist,' which provides a clear context for when to use this tool. It doesn't explicitly mention alternatives or when not to use it, but the use case 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?

Annotations provide readOnlyHint and openWorldHint. Description adds key behavioral trait: tool is paid and requires payment via x402, including flow to call without payment to get terms. Does not contradict 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?

Two sentences, no redundancy. First sentence gives purpose, second contrast with sibling and payment note. Every sentence adds essential information.

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

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

Given no output schema, description adequately explains what the tool returns (which clients affected) and how to match results via ref field. Includes payment flow. Complete for a paid portfolio rescreening 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 covers 67% of parameters with descriptions. Description adds value by clarifying subjects parameter: 'Each needs at least a name or an ICO' and mentions batch cap. This supplements schema details.

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 re-screens a portfolio against sanctions changes since a date, specifying the resource (portfolio) and action (re-screen). It explicitly contrasts with sibling list_recent_updates, stating that this tool intersects global changes with user's list.

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 guidance: 'Answers which of MY clients were affected, which list_recent_updates cannot'. Also describes payment requirement and advises to call without payment first to receive terms, indicating 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 openWorldHint=true, so the safety profile is covered. The description adds the 'fuzzy-search' behavior and country narrowing, but does not disclose return format, ranking details, or what happens with no results. This is adequate but not rich for a search 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 one concise, front-loaded sentence with no filler. It communicates the core purpose and a key optional filter in minimal words.

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 simple search function, full schema coverage, and read-only annotations, the description is sufficient. It could optionally mention that results include confidence scores (implied by the threshold parameter), but this is not a critical gap.

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

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

Schema description coverage is 100%, with detailed descriptions for name, limit, country, and threshold. The description only adds that country 'narrows results', which is redundant with the schema. Baseline 3 is appropriate since the schema carries the parameter meaning.

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

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

The description clearly states the tool's verb ('Fuzzy-search') and resource ('sanctioned entity (company, organization)'), and the parenthetical disambiguates it from the sibling search_person. This is a specific, actionable purpose that distinguishes the tool.

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 usage for companies/organizations and mentions that country is an optional narrowing filter, giving some context. However, it does not explicitly name search_person as the alternative for individuals, so usage guidance falls short of a perfect score.

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

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

Beyond the annotations (readOnlyHint, openWorldHint), the description adds valuable behavioral details: it returns confidence scores (0-100) and explains their interpretation ('100 = exact ID match, 80+ = strong fuzzy match, lower = review needed'). It also notes that fuzzy search and transliteration are applied, which is behavior not captured by annotations. This enriches the agent's understanding of result quality and review requirements.

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: one sentence for the core action, one for optional filters, and one for output interpretation. Every sentence earns its place and is front-loaded with the most essential information. No wasted words or redundant details.

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 appropriately explains return values (matches with confidence scores and their meaning). It also covers search scope and optional narrowing. However, it does not mention limit/threshold behavior or what happens with no matches, though these are in the schema. The overall completeness is good for a read-only search tool, but not exhaustive.

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

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

The schema already provides 100% parameter descriptions, including format for dob, transliteration for name, defaults for limit/threshold, and ISO code for nationality. The description adds little beyond the schema—it only mentions that dob and nationality are optional filters. Since schema coverage is high, a baseline of 3 is appropriate; the description does not compensate for any missing parameter meaning.

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

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

The description clearly states the tool's function: 'Fuzzy-search a sanctioned person by name across all loaded lists.' This specifies the verb (search), resource (person), and scope (sanctioned lists), distinguishing it from the sibling 'search_entity' which likely targets entities rather than persons. The purpose is unambiguous and action-oriented.

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: it searches persons across all loaded lists and mentions optional filters (dob, nationality) that narrow results. However, it does not explicitly state when to prefer this tool over alternatives like 'search_entity' or provide exclusion criteria. Since the purpose clarity already differentiates siblings, the lack of explicit alternatives keeps this at a 4 rather than 5.

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