exclude-feed

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

With no annotations provided, the description carries full burden. It discloses the tool screens against specific lists (HHS-OIG LEIE, OFAC SDN+Consolidated, SAM.gov), mints a signed receipt, and returns per-entity verdicts plus a URL. It also explains the OIG guidance and legal implications. It does not mention rate limits or the max roster size (250, in schema) but is otherwise thorough.

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 moderately long but efficient. The first sentence clearly states the primary action and outcome. Subsequent sentences add regulatory context and output details. Minimal redundancy, though could be slightly trimmed without loss of meaning.

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 complexity of the tool (roster screening with legal compliance requirements) and the absence of annotations and output schema, the description covers purpose, context, behavior, and return values adequately. It explains why the signed receipt is important. Could mention the roster size limit, but that is documented 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 coverage is 100% (all three parameters have descriptions). The description does not add significant meaning beyond the schema: it repeats the purpose of the 'roster' parameter implicitly but does not explain the format or constraints (like max 250) that are in the schema. 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 specific verbs ('Re-screen an ENTIRE ROSTER', 'mint a ... COMPLIANCE RECEIPT') and clearly identifies the resource (employees, contractors, vendors against federal exclusion lists). It distinguishes from sibling tools by emphasizing the entire roster in one call, contrasting with likely single-entity screening (screen_exclusion, screen_batch, watch_entity).

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 the use case: 'the OIG-mandated MONTHLY exclusion check for healthcare billing / RCM / compliance teams' and explains the regulatory requirement. However, it does not explicitly say when NOT to use this tool or name alternative sibling tools for single-entity screening, though the regulatory context strongly implies the appropriate usage.

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 are provided, so description carries full burden. It discloses the tool is free and rate-limited, and returns one verdict per row. However, it does not state if the operation is read-only, potential side effects, or authentication requirements. Lacks some transparency but not misleading.

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 wasted words. The description is front-loaded with the action ('Bulk-screen up to 50 entities...') and efficiently covers key details (max count, list type, input format, output type, pricing). 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 tool with one parameter, no output schema, and no annotations, the description covers the essential: batch size, input format, output verdict, and rate limit. It could mention error handling or response details, but it is fairly complete for its 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 has 100% coverage with a description for the only parameter. The description adds clarifying detail: 'Pass an array of names (or {name,npi,state} objects).' This goes beyond the schema's description by showing the accepted object structure, which is helpful.

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 the tool bulk-screens up to 50 entities against federal exclusion/sanctions lists. The verb 'screen' and resource 'entities' are specific. The name 'batch' distinguishes it from siblings like 'screen_exclusion' (single entity) and 'roster_rescreen' (roster rescreening).

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 batch screening with a limit of 50 entities. It mentions rate limiting but does not explicitly state when to use this tool versus alternatives (e.g., use 'screen_exclusion' for single entity). Still, context signals and tool name make it reasonably clear.

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 provided, the description bears full responsibility for behavioral disclosure. It clearly explains the unified deduped check across multiple sources, the return types (match/possible-match/no-match), matched record details, and confidence score. It also explicitly states it is not a consumer report. This provides good transparency despite lacking rate limits or authentication details.

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: three sentences that front-load the core purpose, list key databases, explain return values, and add a critical legal disclaimer (FCRA-safe). No wasted words, and the structure is clear and scannable.

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 no output schema, the description adequately covers return values (match types, matched records, confidence score). It explains the scope (federal and state exclusions) and deduped nature. Missing details like pagination or example confidence thresholds, but overall fairly complete for this 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?

Schema description coverage is 100%, so the baseline is 3. The tool description does not add extra parameter semantics beyond the schema's own descriptions (e.g., NPI for LEIE, state for disambiguation). The schema descriptions are already informative, so the description adds minimal additional value. Score 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 it screens business entities for federal exclusions and sanctions, listing specific databases (OFAC, HHS-OIG, SAM.gov, state lists). It differentiates itself from siblings like screen_batch (batch) and watch_entity (ongoing) by focusing on pre-onboarding/payment checks. The purpose is precise and 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 indicates when to use ('before you onboard or pay it') and clarifies it's for entities only (FCRA-safe for KYB). However, it does not explicitly state when not to use this tool (e.g., for individual checks or ongoing monitoring) or compare with sibling tools. The guidance is adequate but lacks 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?

With no annotations, the description carries full burden. It discloses daily rescreening, alert on first hit via webhook/email. However, it does not cover whether the tool is idempotent, what happens on subsequent hits, how to remove entities, or any permission/auth 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?

Two sentences, front-loaded with the core action. Every clause adds value. No redundant or vague 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?

Moderate complexity (4 params, no output schema, no nested objects). The description covers the purpose and alert mechanism but omits lifecycle details (e.g., how to stop monitoring, what happens after a hit, idempotency) that would help an agent fully grasp the tool's behavior.

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 meaning to the required 'name' or optional 'npi' parameters beyond their names. It implies email and webhook are for alerts, but does not compensate for undocumented parameters.

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 the action: 'Add an entity to a watchlist that is RE-SCREENED daily.' Specifies the resource (entity to a watchlist) and the use case (continuous vendor/counterparty monitoring). Distinguishes from sibling tools by emphasizing ongoing monitoring vs. batch or 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: 'Use for continuous vendor / counterparty monitoring.' Provides clear context but does not explicitly mention when not to use or suggest alternatives among the listed siblings.

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