Bulk-screen up to 50 entities in one call against all federal exclusion/sanctions lists. Pass an array of names (or {name,npi,state} objects). Returns one verdict per row. Free tool (rate-limited).
| Name | Required | Description | Default |
|---|---|---|---|
| entities | Yes | Array of names or {name,npi,uei,state} objects (max 50). |
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.
Add one secure layer between your agents and this server.
Each tool targets a distinct use case: full roster rescreen with compliance receipt, bulk screening up to 50 entities, single entity check, and continuous daily monitoring. No overlap in purpose.
Three tools follow verb_noun pattern (screen_batch, screen_exclusion, watch_entity), but roster_rescreen reverses the order (noun_verb). Still, all use snake_case and are readable.
Four tools are appropriate for the domain of exclusion screening, covering single, batch, roster-wide, and ongoing monitoring without unnecessary bloat.
Covers all primary workflows—one-off, batch, full roster, and continuous watch. Minor gap: no tool to remove entities from watchlist, but this can be handled externally.