Skip to main content
Glama

sanctions-screening-mcp-server

by io.github.cyanheads
OverviewDiscussionsAdmin

sanctions-screening-mcp-server: screen identifier

sanctions_screen_identifier
Read-onlyIdempotent

Look up an identifier — a vessel IMO number, a SWIFT/BIC code, a digital-currency wallet address, a passport or national ID number, or any other identifier a list publishes — against all loaded sanctions watchlists at once: OFAC SDN + Consolidated, EU, UK, and UN. Exact match after normalization, with no fuzzy or partial matching and no score: spacing, letter case, and the separators - . / are ignored, an IMO number matches with or without its IMO prefix, a SWIFT/BIC code compares on its first eight characters so a branch code matches its institution, and a wallet address folds case only where its encoding is case-insensitive (hex, bech32, cashaddr — never base58). Returns every designation that publishes a matching identifier, one per designation — an OFAC party both OFAC lists publish under one entry ID is one hit, its sources naming both lists — with the identifiers that matched as published; sanctions_get_designation pulls the full record. This is a screening AID for a human/compliance review, NOT a compliance determination: a hit means "review this candidate against the official source," and an empty result never means "cleared" — an identifier a list prints only in free-text remarks, or bundled with other numbers in one field, does not match.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoRestrict to one identifier category, matched on the label each list publishes, or "any" (default) to search every published identifier, including categories with no name here (MMSI, call signs, tail numbers, tax and registration numbers, email, websites).any
valueYesThe identifier to look up, as you hold it (e.g. "IMO 7406784", "DCBKKPPY", a wallet address, a passport number). Must contain at least one character other than whitespace and - . /
sourcesNoRestrict to specific source lists. Omit to search all loaded lists.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hitsNoDesignations that publish a matching identifier, one per designation (an OFAC party on both OFAC lists once), ordered by source list then entry ID. Not paged — the most widely shared published identifiers map to about a dozen designations.
errorNoPresent when the call failed. Absent on success.
caveatNoDecision-support caveat — this is a screening aid, not a compliance determination.
noticeNoGuidance when no designation matched — what to try next, and what an empty result does NOT mean.
totalCountNoNumber of designations returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedOutput schema / properties / hits / description
      Previous value: -"Designations that publish a matching identifier, one per designation, ordered by source list then entry ID. Not paged — the most widely shared published identifiers map to about a dozen designations."New value: +"Designations that publish a matching identifier, one per designation (an OFAC party on both OFAC lists once), ordered by source list then entry ID. Not paged — the most widely shared published identifiers map to about a dozen designations."
    • changedOutput schema / properties / hits / items / properties / source / description
      Previous value: -"Which watchlist this candidate is on — its provenance."New value: +"The watchlist whose record this hit's fields come from — its provenance. For an OFAC party both OFAC lists publish, ofac_sdn unless the Consolidated record matched alone; sources names every list."
    • addedOutput schema / properties / hits / items / properties / sources
      Added value: +{
+  "description": "Every screened list this candidate is on, in list order: one list, or ofac_sdn and ofac_consolidated together for an OFAC party both OFAC lists publish under one entry ID — one hit, not two. Read this, not source, for every list; the entry ID resolves in sanctions_get_designation under each.",
+  "items": {
+    "enum": [
+      "ofac_sdn",
+      "ofac_consolidated",
+      "eu",
+      "uk",
+      "un"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedOutput schema / properties / hits / items / required
      Previous value: -[
-  "source",
-  "sourceLabel",
-  "sourceEntryId",
-  "primaryName",
-  "entityType",
-  "matchedIdentifiers"
-]New value: +[
+  "source",
+  "sourceLabel",
+  "sourceEntryId",
+  "sources",
+  "primaryName",
+  "entityType",
+  "matchedIdentifiers"
+]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare read-only/idempotent/no-open-world; the description adds the substantive behavior: exact match after normalization, no fuzzy or partial matching, the precise folding rules for case, separators, IMO prefixes, SWIFT/BIC eight-character truncation, and per-encoding wallet case folding. It also discloses the return shape (one hit per designation) and the negative-space caveat that identifiers printed only in free-text remarks do not match.

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

Conciseness4/5

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

Front-loaded with the core action and scope, and the normalization/return/caveat sentences each carry non-obvious information an agent cannot get from the schema. The first sentence, however, is a long run-on of em-dash clauses that is denser than it needs to be, costing a little readability.

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 screening tool with an output schema, an agent needs matching semantics, result interpretation, and the follow-up tool — all of which are present. The normalization rules, the one-hit-per-designation return contract, and the 'empty is not cleared' caveat close the correctness gaps that would otherwise cause misuse.

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 coverage is 100%, so the baseline is 3, but the description goes beyond the schema by spelling out what 'value' normalization means in practice (prefixes and separators ignored, so an agent knows it can pass a raw identifier as held) and by clarifying that 'any' also searches categories not enumerated in the type enum. The individual parameter docs largely restate the schema, keeping this just under a 5.

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 ("Look up") and resource (an identifier against all loaded sanctions watchlists), enumerating the identifier categories it accepts and the five source lists it covers. It also names the sibling sanctions_get_designation as the path to the full record, so an agent can tell it apart from relatives without opening a schema.

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?

Gives clear context: use it to screen a held identifier, and follow a hit with sanctions_get_designation for the full record. It also frames the tool as a screening aid rather than a determination and warns that an empty result is not a clearance. It stops short of explicitly contrasting itself with the sibling sanctions_screen_name (name vs identifier screening), so a genuine exclusion is left to inference.

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

All sanctions-screening-mcp-server toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources