exclude-feed

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

With no annotations, the description adequately explains the tool's behavior: it screens against specific lists, returns per-entity verdicts and a verifiable receipt URL. However, it does not mention prerequisites, authorization needs, or whether the tool is read-only or creates data (minting implies creation). No side effects or rate limits are disclosed.

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

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

The description is relatively long but each sentence adds value: purpose, regulatory context, audit significance, output details. It is front-loaded with the core action. While it could be slightly tighter, the length is justified by the tool's complexity and context.

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 has 3 parameters, no output schema, and no annotations, the description provides a solid understanding of inputs and outputs. It explains the output (verdicts, receipt URL) and regulatory relevance. However, it lacks details on error handling, response format, or whether rosters are persisted.

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 baseline is 3. The description adds value beyond the schema by specifying 'max 250' for the roster, defaulting period to 'YYYY-MM', and explaining that org is printed on the receipt. This provides meaningful context for parameter usage.

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 screens an entire roster against specific federal exclusion lists and mints a compliance receipt. It uses specific verbs ('Re-screen', 'mint') and identifies the exact resources (roster, lists, receipt). While it doesn't explicitly distinguish from siblings, the emphasis on 'ENTIRE ROSTER' and 'ONE call' implies differentiation from single-entity or batch 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 strong contextual guidance by referencing OIG-mandated monthly exclusion checks for healthcare compliance. This implies when to use (monthly full roster screens). However, it does not explicitly state when not to use or directly compare with sibling tools like screen_batch or screen_exclusion.

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?

Discloses rate-limiting and return behavior (one verdict per row) but, with no annotations, does not confirm read-only nature or potential side effects. Adds some context beyond schema.

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: purpose and batch size in first, input format and return in second. No wasted words, information 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?

With no output schema, description only vaguely promises 'one verdict per row' without format details. Lacks error handling or safety information, but adequate for a batch tool given sibling 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 describes the 'entities' parameter fully (including uei field). Description omits uei, creating an inconsistency that may mislead agents. Does not add meaningful detail beyond 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?

Clearly states verb 'Bulk-screen' and resource 'entities against all federal exclusion/sanctions lists'. Distinguishes from siblings by specifying batch of up to 50, contrasting with likely single-entity screen_exclusion.

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?

Indicates when to use (for multiple entities) and provides input format. However, does not explicitly name alternatives or state when not to use this tool over siblings.

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

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

No annotations provided; description carries full burden. It comprehensively details databases checked, result types (match/possible-match/no-match), output elements (source, exclusion type, dates, confidence score), and notes FCRA-SAFE status, ensuring the agent understands behavior and limitations.

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 purpose, but the description is a single verbose paragraph. Could be more concise by breaking into sentences or bullets, but all information 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?

No output schema, but description adequately explains return values (match level, matched records with details, confidence score). Given the tool's complexity (multiple databases, legal compliance), description is thorough and leaves no critical 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?

Input schema has 100% description coverage. The description adds value by explaining the purpose of optional parameters, e.g., 'npi for an exact LEIE match', enhancing understanding 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 screens a business entity for federal exclusions and sanctions, listing specific databases. It effectively distinguishes from sibling tools screen_batch (batch) and watch_entity (monitoring) by emphasizing one-time screening.

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: 'before you onboard or pay it' and notes it's for KYB/sanctions compliance. Does not mention when not to use or alternatives, but the use case is well-defined.

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 no annotations, description carries full burden. It discloses daily re-screening, first-time alerting, and alert methods (webhook/email). However, it does not address behavior on duplicate adds, subsequent appearances, or removal/editing, leaving 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 sentences with no filler. First sentence states core action and key behavior; second sentence recommends use case. Front-loaded and 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?

Sufficient for basic understanding given parameter count and lack of output schema. But omits edge cases (duplicates, removal) and does not compensate for schema gaps. Sibling tool names provide some context for when to use.

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% (only email and webhook have descriptions). The description adds no parameter-specific details (e.g., what 'npi' means, that 'name' is required). It relies on schema for two params but leaves 'npi' and 'name' unexplained.

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 adds an entity to a daily re-screened watchlist and alerts on first appearance on exclusion/sanctions lists. It distinguishes from sibling tools (screen_batch, screen_exclusion) which are likely one-time checks, by specifying continuous monitoring.

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 context is provided via 'Use for continuous vendor / counterparty monitoring,' implicitly contrasting with one-time screening tools. No explicit when-not-to-use or alternatives, but sibling names help infer differentiation.

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