Skip to main content
Glama

Screen several names

screen_names
Read-onlyIdempotent

Screens up to 100 names against the OFAC SDN list, returning potential match counts and the best match per name so you can identify sanctioned parties and follow up.

Instructions

Screens up to 100 names against the OFAC SDN list and returns, for each, the number of potential matches and the best one. Use screen_name for full details on any name that has matches.

Input Schema

NameRequiredDescriptionDefault
namesYesThe names to screen (at most 100).
minScoreNoLowest score to count as a potential match, 0-100. Default 85.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover the read-only and idempotent profile, and the description adds the screening target (OFAC SDN only), the batch ceiling, and the summarized nature of the response. It does not state whether the screen is local or remote, latency, or what the 'best match' object contains, so it stops short of full disclosure.

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

Conciseness5/5

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

Two sentences, front-loaded with capability and return shape, followed by the sibling fallback. No filler or restatement of the title.

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

Completeness4/5

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

For a two-parameter read tool with no output schema, the definition explains what comes back in summary form and where to go for depth. A note on whether lists other than OFAC SDN exist (the presence of get_list_info hints at that) would close the remaining gap.

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

Parameters3/5

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

Schema coverage is 100%, so both the names array and the minScore threshold are already fully documented in the schema. The description's 'up to 100' and 'number of potential matches' loosely reinforce those parameters but add no new semantics or formatting guidance, which meets the baseline-3 case.

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

Purpose5/5

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

The description names a specific verb (screens), a specific resource (OFAC SDN list), a bounded scope (up to 100 names), and the return shape (match count plus best match per name). It distinguishes itself cleanly from the sibling screen_name, which handles a single name.

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

Usage Guidelines4/5

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

It explicitly routes the agent to screen_name when full details are needed for a name that has matches, which is a real when-to-use split. It does not discuss when to prefer a single-name call outright or what happens past the 100-name cap, but the primary alternative is named.

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