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 twice a day). 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. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark it read-only, idempotent and non-destructive, and the description adds a lot beyond that: truncation at 2000 shared rows with has_more/candidates_truncated, no paging, data refreshed about twice a day, Canada entity-only, Australia not loaded, UN list out of scope, and a no-match-is-not-clearance disclaimer. It also discloses the metering and free-quota behavior, which is operationally important and not in any structured field.

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?

Purpose is front-loaded well, but the body is a single dense run-on paragraph in which the matching algorithm, truncation, output shape, disclaimers and a long metering/credit section are chained with semicolons. All of the content is relevant, yet the pricing paragraph in particular is bulky enough to bury the call-critical guidance.

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?

For a three-parameter search with no output schema, the description covers inputs, the matching semantics, the truncation escape hatch, the described return fields (matches[] with list, id, names, aliases, score, match_type, first_seen, last_changed; has_more; lists[] with file URLs and check times), list coverage caveats and freshness. An agent has essentially everything needed to call it and interpret the response.

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 baseline is 3; the description still adds meaning: words may be given in any order, case/accent/punctuation are ignored, a 1-2 letter typo is tolerated in words of 4+ letters except the first letter, and limit has no paging so a truncated result must be narrowed via name or list. Remaining gap is minor, e.g. it does not restate the enum list values, which the schema already covers.

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?

It states a specific verb (returns entries) and resource (current sanctions entries on named OFAC/UK/EU/Canada lists) plus the precise matching rule (each word must prefix a word in the name or alias, any order, case/accent/punctuation-insensitive, with typo tolerance). That is enough for an agent to distinguish it from sanctions_get_entry or sanctions_list_changes without opening the schema.

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?

It gives an explicit trigger ('Use it when you have a name') and names both alternatives with their selecting conditions: sanctions_get_entry for a known list and id, sanctions_list_changes for watching changes. It also tells the agent what to do when has_more is true: add words or a list.

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.

Resources