Skip to main content
Glama

sanctions-screening-mcp-server

by io.github.cyanheads

sanctions-screening-mcp-server: resolve entity

sanctions_resolve_entity
Read-onlyIdempotent

Resolve a company or organization name (with an optional ISO 3166-1 alpha-2 jurisdiction) to candidate GLEIF Legal Entity Identifiers (LEIs), ranked. This turns a free-text counterparty name into a stable global identifier that sanctions_get_entity and sanctions_trace_ownership key off. Strict mode (default) matches exact-normalized then all-tokens-present; fuzzy mode (or auto when strict is empty) adds Jaro-Winkler scoring labeled approximate with a raw 0–1 score plus the count of query tokens the matched name covers, which orders candidates that tie on score. Results are paged: totalAvailable and hasMore report candidates beyond the returned page, and nextOffset retrieves them. Returns potential matches to confirm against the GLEIF record — name resolution is a candidate ranking, not an authoritative identification.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe company / organization name to resolve to an LEI.
limitNoMaximum LEI candidates to return in one page.
offsetNoZero-based index of the first LEI candidate to return. Re-call with the returned nextOffset to page through every candidate when hasMore is true; an offset past the end returns an empty page, not an error.
statusNoRegistration status filter: issued (default), lapsed, or any.issued
minScoreNoJaro-Winkler floor for fuzzy hits (0–1); defaults to the server's configured floor.
matchModeNostrict (default): exact then all-tokens-present. fuzzy: also scored Jaro-Winkler.strict
jurisdictionNoOptional ISO 3166-1 alpha-2 jurisdiction filter (e.g. "US", "GB"). Empty string disables it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when no LEI matched and how to broaden, or when the requested offset sits past the end of the result set.
hasMoreNoTrue when LEI candidates remain beyond this page — re-call with nextOffset.
matchesNoLEI candidates, ranked by match type, then score, then how much of the query each matched name explains.
nextOffsetNoThe offset to request next. Present only when hasMore is true.
totalCountNoNumber of LEI candidates returned in this page.
matchModeUsedNoThe match mode actually applied (strict may upgrade to fuzzy).
totalAvailableNoLEI candidates available across all pages, before limit and offset were applied.
normalizedQueryNoThe name as the server folded it for matching.
totalAvailableBasisNoHow to read totalAvailable: exact = the complete strict candidate set; lower_bound = a bounded scan produced it (every fuzzy pass, and any strict pass that hit the raw-row scan cap), so more may exist.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed6 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / anyOf
      Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "matches",
+      "normalizedQuery",
+      "matchModeUsed",
+      "totalCount",
+      "totalAvailable",
+      "totalAvailableBasis",
+      "hasMore"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]
    • addedOutput schema / properties / error
      Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `mirror_not_ready`: The GLEIF (LEI) mirror has never completed an initial sync. Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "mirror_not_ready"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}
    • removedOutput schema / required
      Removed value: -[
-  "matches",
-  "normalizedQuery",
-  "matchModeUsed",
-  "totalCount",
-  "totalAvailable",
-  "totalAvailableBasis",
-  "hasMore"
-]
  2. Changed11 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum LEI candidates to return."New value: +"Maximum LEI candidates to return in one page."
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "description": "Zero-based index of the first LEI candidate to return. Re-call with the returned nextOffset to page through every candidate when hasMore is true; an offset past the end returns an empty page, not an error.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedOutput schema / properties / hasMore
      Added value: +{
+  "description": "True when LEI candidates remain beyond this page — re-call with nextOffset.",
+  "type": "boolean"
+}
    • changedOutput schema / properties / matches / description
      Previous value: -"Ranked LEI candidates, highest-confidence first."New value: +"LEI candidates, ranked by match type, then score, then how much of the query each matched name explains."
    • addedOutput schema / properties / matches / items / properties / queryTokenCoverage
      Added value: +{
+  "additionalProperties": false,
+  "description": "How much of the query the matched name explains, as a literal token count — a second real measurement, never folded into score. It is the tie-break applied after score, because one shared exact token pins several candidates at the same score. Absent for exact/strong matches.",
+  "properties": {
+    "covered": {
+      "description": "Query tokens individually matched by one of the matched name's tokens at the applied score floor.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "total": {
+      "description": "Total tokens in the normalized query.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "covered",
+    "total"
+  ],
+  "type": "object"
+}
    • addedOutput schema / properties / nextOffset
      Added value: +{
+  "description": "The offset to request next. Present only when hasMore is true.",
+  "type": "number"
+}
    • changedOutput schema / properties / notice / description
      Previous value: -"Guidance when no LEI matched and how to broaden."New value: +"Guidance when no LEI matched and how to broaden, or when the requested offset sits past the end of the result set."
    • addedOutput schema / properties / totalAvailable
      Added value: +{
+  "description": "LEI candidates available across all pages, before limit and offset were applied.",
+  "type": "number"
+}
    • addedOutput schema / properties / totalAvailableBasis
      Added value: +{
+  "description": "How to read totalAvailable: exact = the complete strict candidate set; lower_bound = a bounded scan produced it (every fuzzy pass, and any strict pass that hit the raw-row scan cap), so more may exist.",
+  "enum": [
+    "exact",
+    "lower_bound"
+  ],
+  "type": "string"
+}
    • changedOutput schema / properties / totalCount / description
      Previous value: -"Number of LEI candidates returned."New value: +"Number of LEI candidates returned in this page."
    • changedOutput schema / required
      Previous value: -[
-  "matches",
-  "normalizedQuery",
-  "matchModeUsed",
-  "totalCount"
-]New value: +[
+  "matches",
+  "normalizedQuery",
+  "matchModeUsed",
+  "totalCount",
+  "totalAvailable",
+  "totalAvailableBasis",
+  "hasMore"
+]
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered; the description adds substantial behavioral context beyond this: match-mode mechanics (exact-normalized → all-tokens-present → Jaro-Winkler), the raw 0–1 score semantics and token-coverage ordering, paging behavior via totalAvailable/hasMore/nextOffset, and the critical caveat that results are candidates to confirm rather than authoritative. No contradiction with annotations.

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?

At roughly 120 words it is long, but every sentence earns its place for a 7-parameter tool with multiple matching modes and paging. The core purpose is front-loaded in the opening sentence, and the matching-mode detail, paging mechanics, and confirmation caveat each carry distinct information. Slightly dense, but justified by complexity.

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 complex, 7-param tool with an output schema, the description is remarkably complete: it covers purpose, both match modes plus the auto fallback, scoring semantics, paging, and the non-authoritative nature of results. Since an output schema exists, return-value documentation is already handled. The only minor absence is explicit guidance on when to prefer this over sanctions_screen_name, which does not meaningfully detract.

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 adds genuine value on top: it defines the 'auto' behavior not present as an enum value in the schema ('fuzzy mode (or auto when strict is empty)'), clarifies what minScore means ('Jaro-Winkler floor for fuzzy hits'), explains the matchMode semantics beyond the enum labels, and ties offset to the returned nextOffset/hasMore paging contract.

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 ('Resolve'), resource (company/organization name), and output (candidate GLEIF LEIs), plus an optional jurisdiction qualifier. It also positions itself relative to siblings by naming sanctions_get_entity and sanctions_trace_ownership as the consumers of its output, and its candidacy caveat ('name resolution is a candidate ranking, not an authoritative identification') clearly distinguishes it from look-up tools.

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?

Provides clear context: this is the resolution step that produces the stable identifiers get_entity and trace_ownership key off, and it warns results must be confirmed, not trusted. It explains strict vs fuzzy mode behavior including the 'auto when strict is empty' fallback. It does not, however, give explicit exclusions versus siblings like sanctions_screen_name, so an agent must infer when resolution rather than screening is appropriate.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool serves a distinct purpose: listing sources, screening names, fetching designation records, resolving LEIs, fetching entity details, and tracing ownership graphs. No two tools overlap in function, and the descriptions clearly differentiate them.

Naming Consistency5/5

All tool names follow the consistent pattern 'sanctions_' + verb + noun using snake_case: get_designation, get_entity, list_sources, resolve_entity, screen_name, trace_ownership. The verbs and objects are distinct and predictable.

Tool Count5/5

With 6 tools, the server is tightly scoped to the sanctions screening workflow: name screening, designation lookup, entity resolution, entity details, ownership tracing, and source provenance. Each tool earns its place, and the count is well within the ideal 3-15 range.

Completeness5/5

The tool set covers the full screening lifecycle: list sources for provenance, screen a name, drill into designation details, resolve companies to LEIs, fetch entity records, and trace ownership with optional screening. No obvious gaps exist for the stated purpose, and the server supports complete workflows.

Resources