Skip to main content
Glama

sanctions-screening-mcp-server

sanctions-screening-mcp-server: trace ownership

sanctions_trace_ownership
Read-onlyIdempotent

Trace the GLEIF Level 2 corporate-ownership graph for an LEI: direct and ultimate parents and/or children, traversed breadth-first to a bounded depth, with relationship type for each edge. Set screenNodes to also screen every entity in the graph against all loaded watchlists — beneficial-ownership screening that resolves "is anyone in this ownership chain sanctioned." Each per-node screen is a screening AID: hits are candidates to verify, and an empty result for a node is not a clearance of that node. The response says what it could not do: complete/truncated/missingEntityLeis report whether the graph is the full known picture, screeningStatus reports whether the cross-reference actually ran, and each screened node reports whether its own hit list was capped. Requires a valid 20-character LEI (use sanctions_resolve_entity to obtain one).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
leiYesThe 20-character GLEIF LEI at the root of the ownership graph.
depthNoMaximum traversal depth from the root entity (1–5).
directionNoWalk parents (who owns it), children (what it owns), or both (default).both
screenNodesNoWhen true, screen every node's legal name against all watchlists for beneficial-ownership screening.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
edgesNoDirected ownership edges between the nodes.
errorNoPresent when the call failed. Absent on success.
nodesNoAll entities reached in the traversal, including the root.
caveatNoDecision-support caveat — node screening is an aid, not a determination.
rootLeiNoThe LEI the traversal started from.
completeNoTrue only when this is the full known ownership picture: nothing was cut off by the requested depth AND every node resolved to a GLEIF Level 1 record. False means the graph below is a partial view — read truncated and missingEntityLeis for which.
truncatedNoTrue when further ownership relationships exist beyond the requested depth — re-run with a higher depth to see them. False means the traversal reached the edge of the loaded relationship corpus.
screeningStatusNoWhether the per-node cross-reference ran: screened = every node was screened; not_requested = screenNodes was false; not_ready = screening was requested but the sanctions mirror has never synced, so NO node was screened and the absence of hits says nothing about any node.
flaggedNodeCountNoHow many screened nodes had at least one potential watchlist match.
missingEntityLeisNoLEIs published in the relationship corpus but absent from the GLEIF Level 1 entity mirror. Their nodes carry the LEI in place of a legal name and no jurisdiction/status — never read that LEI as a legal name, and note any per-node screen for them ran against the LEI string.
screenedNodeCountNoHow many nodes were screened (0 when screenNodes is false).

TDQS

A4.6/5.0
Behavior5/5

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

The description goes well beyond the annotations (readOnlyHint, idempotentHint, openWorldHint) by explaining the incomplete-data semantics: it warns that 'complete/truncated/missingEntityLeis' report whether the graph is the full known picture, and 'screeningStatus' indicates whether the cross-reference actually ran. It also clarifies that an empty result for a node is not a clearance. These are critical behavioral caveats not present in the 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?

The description is fairly long but each sentence carries significant meaning, covering the core purpose, screening behavior, response caveats, and LEI requirement. It is front-loaded with the primary action and then layers additional context. While not as terse as some descriptions, it avoids fluff and justifies its length with essential details.

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?

Given the tool's complexity (graph traversal, depth/direction, optional screening) and the existence of an output schema (which covers return values), the description is remarkably complete. It covers traversal semantics, screening semantics, incomplete-graph reporting, and the prerequisite for a valid LEI. It also names the sibling tool for LEI resolution. Nothing critical for an agent to call it correctly is missing.

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?

The schema already provides 100% coverage of all four parameters with descriptions. The description adds semantic depth beyond the schema, particularly for screenNodes: it explains that each node screen is a screening AID, hits are candidates to verify, and empty results are not clearances. It also clarifies the meaning of depth and direction in the context of the ownership graph. This adds value beyond the schema's basic parameter descriptions.

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?

The description clearly states the tool's function: tracing the GLEIF Level 2 ownership graph for an LEI, including parents/children, depth, and relationship types. It distinguishes itself from siblings like sanctions_resolve_entity (which resolves LEIs) and sanctions_screen_name (which screens a single name) by focusing on graph traversal and optional beneficial-ownership screening. The verb 'trace' plus a specific resource makes the purpose unambiguous.

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?

The description provides clear context on when to use the screening feature (screenNodes=true) and explicitly mentions using sanctions_resolve_entity to obtain a valid LEI, giving a dependency. However, it does not explicitly state when NOT to use this tool versus alternatives (e.g., using sanctions_screen_name for single-entity screening). The guidance is strong but not fully prescriptive about exclusions.

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.

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.