Skip to main content
Glama

search_screening

Read-only

Check entities against consolidated sanctions and export-control screening lists like OFAC SDN, BIS Entity List, and ITAR Debarred. Filter by name, list source, entity, or minimum match similarity for compliance and due-diligence.

Instructions

Check entities against consolidated sanctions / export-control screening lists (OFAC SDN, BIS Entity List, ITAR Debarred, etc.). Filter by entity, name, list source, or minimum match similarity. Use for compliance / due-diligence questions.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_screening"
  }
}

Input Schema

NameRequiredDescriptionDefault
listNoSubstring match on screening list source (e.g. SDN, Entity List, ITAR)
nameNoSubstring match on entity or matched name
limitNoMax rows returned (default 50, max 500). The response total is the full match count regardless of limit; rows cannot be paged, so answer counting questions from total. Output keeps the rows that fit in about 40 KB and says how many it left out
entity_idNoFilter by resolved entity UUID
min_similarityNoMinimum match similarity 0-1 (e.g. 0.9)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.0
    • changedInput schema / properties / limit / description
      Previous value: -"Max results (default 50, max 500)"New value: +"Max rows returned (default 50, max 500). The response total is the full match count regardless of limit; rows cannot be paged, so answer counting questions from total. Output keeps the rows that fit in about 40 KB and says how many it left out"
  2. First observedv0.3.1

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds useful domain context that results are fuzzy/similarity-scored ('minimum match similarity'), but it does not say what a no-match result means for a compliance determination, how similarity is computed, or that responses are truncated by size. Adequate but not rich.

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 the core action and list scope, followed by the filter summary and the usage cue. No redundancy or filler.

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 read-only search tool with full schema coverage and no output schema, the description covers purpose, filters, and use case well enough to invoke correctly. The remaining ambiguity — whether an empty result constitutes a clean screening outcome versus an unmatched query — is left unaddressed.

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 description coverage is 100% and each parameter is documented in detail in the schema (including the unusual limit/no-paging/40KB behavior). The description only restates the filter dimensions (entity, name, list source, min similarity) and omits `limit`/`entity_id` nuance. Baseline 3 is correct when the schema does the heavy lifting.

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

Purpose4/5

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

The description names a specific verb (check entities against) and a concrete resource (consolidated sanctions / export-control screening lists), with examples (OFAC SDN, BIS Entity List, ITAR Debarred). That is far more specific than the many generic `search_*` siblings, though it never explicitly contrasts itself with `search_entities` or `get_entity_dossier`, which an agent could plausibly confuse it with.

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?

"Use for compliance / due-diligence questions" gives a clear situational trigger, which is exactly the context needed to pick this over the sibling search tools. There are no explicit exclusions (e.g. "use search_entities for general entity lookup, not screening"), so it stops 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.