Skip to main content
Glama

Search current sanctions entries

sanctions_search_entries
Read-onlyIdempotent

Returns current entries on the official OFAC (SDN and Consolidated), UK, EU and Canada sanctions lists (Canada entity-only; Australia pending, not loaded yet) whose name or alias has a word starting with each word you give, in any order, ignoring case, accents and punctuation; if nothing matches, a one- or two-letter typo in words of 4 or more letters, except the first letter, is tolerated. When more than 2000 rows share your words, has_more is true and candidates_truncated is set: add words or a list. Use it when you have a name; use sanctions_get_entry for a known list and id, and sanctions_list_changes to watch what changed. Inputs: name (required, at least 3 letters/digits and at most 6 words, e.g. Rosneft or Ivanov Sergey), list (optional, one list) and limit (1 to 50, default 20; no paging, so narrow name or list when has_more is true). Output: matches[] with list, id, names, aliases, score (0 to 1), matched_name, match_type (exact_words or fuzzy), programmes, countries, first_seen and last_changed, plus has_more and lists[] with official file URLs and check times (about every 6 hours). This is a monitoring aid, not a clearance decision: no match does not clear anyone, the UN list is not covered, and the official lists are authoritative. Terms: read-only; MCP calls are never charged. Without a key, metered routes give 10 successful answers a day free, as short samples (up to 3 records, without file proof, history or paging cursor) where a paid HTTP address exists (unmetered routes are unlimited); errors do not count. On the paid HTTP routes, errors are free, and so are empty answers except a sanctions name search with no match when every loaded list it checks is fresh (lists not loaded yet are named in the answer). An optional API key keeps its prepaid-credit policy. When the free answers run out, the error names the HTTP alternative.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

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

Input Schema

NameRequiredDescriptionDefault
listNoOne list only Allowed: ofac-sdn, ofac-consolidated, uk, eu, ca, au; e.g. ofac-sdn.
nameYesName or words of it in any order, at most 6 words, e.g. Rosneft; at least 3 normalized letters/digits; case/accent/punctuation-insensitive; no handler-specific maximum length
limitNoMatches, 1 to 50 (default 20); e.g. 20.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous value: -"Name word prefix, e.g. Rosneft; at least 3 normalized letters/digits; case/accent/punctuation-insensitive; no handler-specific maximum length"New value: +"Name or words of it in any order, at most 6 words, e.g. Rosneft; at least 3 normalized letters/digits; case/accent/punctuation-insensitive; no handler-specific maximum length"
  2. Changed2 schema fields changed
    • changedInput schema / properties / list / description
      Previous value: -"One list only Allowed: ofac-sdn, ofac-consolidated, uk, eu; e.g. ofac-sdn."New value: +"One list only Allowed: ofac-sdn, ofac-consolidated, uk, eu, ca, au; e.g. ofac-sdn."
    • changedInput schema / properties / list / enum
      Previous value: -[
      -  "ofac-sdn",
      -  "ofac-consolidated",
      -  "uk",
      -  "eu"
      -]New value: +[
      +  "ofac-sdn",
      +  "ofac-consolidated",
      +  "uk",
      +  "eu",
      +  "ca",
      +  "au"
      +]
  3. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, open-world and non-destructive, but the description adds substantial context the annotations do not: truncation flags (has_more, candidates_truncated) above 2000 rows, list freshness (~6 hours), coverage caveats (Canada entity-only, Australia not loaded, UN not covered), and free-tier metering behavior. The 'read-only' and 'never charged for MCP calls' statements are consistent with readOnlyHint, so nothing contradicts. Only the somewhat confusing distinction between MCP calls and 'paid HTTP routes' keeps this below a 5.

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

Conciseness3/5

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

The core purpose and routing are front-loaded, but the opening is a single very long semicolon-chained sentence and the closing third is dense metering/billing text about HTTP routes that is only marginally relevant to selecting and calling this MCP tool. The information earns its place individually, but the packaging makes it harder to scan than it needs to be.

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

Completeness5/5

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

There is no output schema, and the description compensates fully by enumerating the returned fields (list, id, names, aliases, score, matched_name, match_type, programmes, countries, first_seen, last_changed, has_more, lists[]) plus file URLs and check times. It also covers coverage limits and the 'monitoring aid, not a clearance decision' caveat, which is exactly the context an agent needs before using results.

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

Parameters4/5

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

Schema description coverage is 100%, so the schema already documents name constraints, the list enum and limit bounds; the description largely restates these, which earns the baseline rather than more. It does add value beyond the schema by explaining matching tolerance for name (typo tolerance, first-letter exception) and the operational consequence of limit ('no paging, so narrow name or list when has_more is true').

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?

States a specific verb and resource ('Returns current entries on the official OFAC ... UK, EU and Canada sanctions lists') and pins down the exact matching semantics (word-prefix, any order, case/accent/punctuation-insensitive, limited typo tolerance). It is immediately distinguishable from sanctions_get_entry (known list+id) and sanctions_list_changes (change monitoring).

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

Usage Guidelines5/5

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

Gives explicit routing: 'Use it when you have a name; use sanctions_get_entry for a known list and id, and sanctions_list_changes to watch what changed.' It also tells the agent what to do when truncated ('add words or a list') and warns that there is no paging, which is actionable when-to-use guidance rather than inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.