Screen names against OFAC, EU, UK, UN sanctions lists; resolve entities via GLEIF. Screening aid.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: list sources, screen names, get designation details, resolve entity names to LEIs, get entity records, and trace ownership. No two tools overlap in functionality.
All tools follow the consistent 'sanctions_verb_noun' pattern (e.g., sanctions_get_designation, sanctions_screen_name). Verbs and nouns are descriptive and uniform.
With 6 tools, the set is appropriately scoped for the domain of sanctions screening and entity resolution. Each tool serves a necessary step in the workflow without being excessive or insufficient.
The tool surface covers the core screening and entity resolution workflow: listing sources, screening names, resolving entities, retrieving details, and tracing ownership. A minor gap is the lack of a tool to manually trigger data refresh, but the set is otherwise well-rounded for its purpose.
sanctions_get_designationsanctions-screening-mcp-server: get designationAFetch the full record for one sanctions designation by source list + entry ID — the drill-in after sanctions_screen_name surfaces a candidate. Returns all published aliases, identifiers (passport/national-ID/tax), addresses, dates and places of birth, nationalities, sanctioning program, legal basis, and designation date. The record reflects exactly what the source published; missing fields mean the source omitted them. This is a screening aid — the designation record supports a compliance review, it is not itself a determination.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Which source list the entry belongs to. | |
| entryId | Yes | The source list's own entry ID (the sourceEntryId from sanctions_screen_name). |
| Name | Required | Description |
|---|---|---|
| caveat | Yes | Decision-support caveat — this is a screening aid, not a compliance determination. |
| source | Yes | Source list the entry belongs to. |
| aliases | Yes | All published aliases / name variants. |
| program | No | Sanctioning program / regime, when published. |
| remarks | No | Free-form remarks published by the source, when present. |
| addresses | Yes | Published addresses. |
| entityType | Yes | Entity classification as published. |
| legalBasis | No | Statutory / regulatory basis, when published. |
| identifiers | Yes | Published identifiers (passport, national ID, tax, registration, …). |
| primaryName | Yes | Primary published name. |
| sourceLabel | Yes | Human-readable name of the source list. |
| datesOfBirth | Yes | Published dates and places of birth (persons). |
| nationalities | Yes | Published nationalities / citizenships. |
| sourceEntryId | Yes | The source list's own entry ID. |
| designationDate | No | Designation date, when published. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds that the record reflects published data exactly and missing fields mean omitted by source. No contradictions; useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose. Every sentence adds value: purpose, return content, caveat about missing fields, and limitation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers scope, caveats, and tool relationship. No gaps for a drill-in lookup tool with annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description mentions the parameters (source list and entry ID) but adds no new semantic details beyond reinforcing the relationship to screen_name output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's purpose: fetch full record for a sanctions designation by source list and entry ID. Identifies it as the drill-in after sanctions_screen_name, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (after screening has surfaced a candidate) and notes it is a screening aid not a determination. Lacks explicit when-not-to-use or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sanctions_get_entitysanctions-screening-mcp-server: get entityAFetch the full GLEIF Level 1 record for one LEI: legal name, other/trading names, legal and headquarters addresses, registration status, jurisdiction, registration authority and ID, and last-update date — plus any sanctions hits screened against the same legal name across all loaded watchlists. The screening cross-reference is a screening AID: a hit is a candidate to verify against the official source, and no hit is not a clearance. screeningStatus says whether that cross-reference actually ran — an empty sanctionsHits under not_ready means the sanctions mirror was unavailable, not that nothing matched. sanctionsScreen says whether the hit list is the whole set: it reports how many potential matches existed before the cap, so a capped cross-reference is distinguishable from a complete one. LEI must be a 20-character GLEIF identifier (18 alphanumerics + 2 check digits).
| Name | Required | Description | Default |
|---|---|---|---|
| lei | Yes | The 20-character GLEIF Legal Entity Identifier to look up. |
| Name | Required | Description |
|---|---|---|
| lei | Yes | The 20-character GLEIF Legal Entity Identifier. |
| caveat | Yes | Decision-support caveat — the screening cross-reference is an aid, not a determination. |
| status | No | Registration status (e.g. ISSUED, LAPSED). |
| legalName | Yes | Registered legal name. |
| lastUpdate | No | ISO 8601 last-update timestamp from the LEI record. |
| otherNames | Yes | Other / trading names published in the LEI record. |
| jurisdiction | No | Legal jurisdiction (ISO code), when published. |
| legalAddress | No | Single-line legal address, when published. |
| sanctionsHits | Yes | Sanctions screening cross-reference on the entity's legal name. |
| sanctionsScreen | No | Disclosure for the cross-reference screen: how many potential matches existed before the cap, and whether sanctionsHits is the complete set. Present only when screeningStatus is 'screened'. |
| screeningStatus | Yes | Whether the cross-reference ran: screened = the legal name was screened against every loaded watchlist; not_ready = the sanctions mirror has never synced, so no screening ran and the empty sanctionsHits says nothing about this entity. Read sanctionsHits only when this is 'screened'. |
| headquartersAddress | No | Single-line headquarters address, when published. |
| registrationAuthorityId | No | Registration authority (RA) code, when published. |
| registrationAuthorityEntityId | No | The entity's ID at its registration authority, when published. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint and idempotentHint annotations by explaining the nuance of the screening cross-reference: screeningStatus indicates whether the cross-reference ran, empty sanctionsHits under not_ready means the mirror was unavailable, and sanctionsScreen reveals whether the hit list was capped. This is critical behavioral context not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries meaning. It front-loads the primary purpose, then explains the screening caveats in a structured way. The length is justified by the subtle semantics of screeningStatus and sanctionsScreen, and no redundant filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, rich annotations, and the presence of an output schema to document return values, the description fully covers the behavioral nuances that would trip up an agent: the distinction between 'no hit' and 'not_ready', and between a capped and complete cross-reference. This is complete for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the lei parameter with a pattern and full coverage, so the baseline is 3. The description adds a human-readable restatement of the LEI format (18 alphanumerics + 2 check digits), reinforcing the pattern and providing validation detail beyond the schema's regex.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Fetch the full GLEIF Level 1 record for one LEI' and enumerates the returned fields, making the tool's purpose precise and action-oriented. It clearly differentiates from siblings like sanctions_screen_name (screening a name) and sanctions_trace_ownership by focusing on LEI-based entity retrieval with a screening cross-reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for fetching an entity by LEI, including sanctions screening. It does not explicitly state when to avoid using it or name alternatives, but the first sentence establishes the primary use case. The sibling list helps disambiguate, though no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sanctions_list_sourcessanctions-screening-mcp-server: list sourcesAList the sanctions watchlists (OFAC SDN + Consolidated, EU, UK, UN) and GLEIF datasets currently loaded in the local mirror, each with its record count, source URL, license, and the mirror's readiness and as-of timestamp. Use this for provenance and freshness on any result — results are only as current as the last mirror refresh, and a not-ready mirror means screening cannot run yet. Attribution: UK data is under the Open Government Licence v3.0; all sources are cited here.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| leiAsOf | No | ISO 8601 timestamp of the last completed GLEIF sync, when available. |
| sources | Yes | All loaded sources, sanctions lists then the GLEIF dataset. |
| leiReady | Yes | True once the GLEIF (LEI) mirror has completed at least one full sync. |
| sanctionsAsOf | No | ISO 8601 timestamp of the last completed sanctions sync, when available. |
| sanctionsReady | Yes | True once the sanctions mirror has completed at least one full sync. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. Description adds critical behavioral info: mirror readiness affects screening capability, and provides attribution for data sources. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key data, followed by usage advice and attribution. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, rich annotations, and output schema, the description fully covers purpose, usage, behavioral readiness, and attribution. Complete for this tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. Description adds no param info (unnecessary) but effectively covers the tool's zero-input nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists sanctions watchlists and GLEIF datasets with specific details (record count, source URL, license, readiness, as-of timestamp). It distinguishes from sibling tools which focus on entities and screening.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use for provenance and freshness checking, and notes that a not-ready mirror blocks screening. Could be more explicit about when not to use (e.g., for actual screening) but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sanctions_resolve_entitysanctions-screening-mcp-server: resolve entityAResolve 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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The company / organization name to resolve to an LEI. | |
| limit | No | Maximum LEI candidates to return in one page. | |
| offset | No | 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. | |
| status | No | Registration status filter: issued (default), lapsed, or any. | issued |
| minScore | No | Jaro-Winkler floor for fuzzy hits (0–1); defaults to the server's configured floor. | |
| matchMode | No | strict (default): exact then all-tokens-present. fuzzy: also scored Jaro-Winkler. | strict |
| jurisdiction | No | Optional ISO 3166-1 alpha-2 jurisdiction filter (e.g. "US", "GB"). Empty string disables it. |
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no LEI matched and how to broaden, or when the requested offset sits past the end of the result set. |
| hasMore | Yes | True when LEI candidates remain beyond this page — re-call with nextOffset. |
| matches | Yes | LEI candidates, ranked by match type, then score, then how much of the query each matched name explains. |
| nextOffset | No | The offset to request next. Present only when hasMore is true. |
| totalCount | Yes | Number of LEI candidates returned in this page. |
| matchModeUsed | Yes | The match mode actually applied (strict may upgrade to fuzzy). |
| totalAvailable | Yes | LEI candidates available across all pages, before limit and offset were applied. |
| normalizedQuery | Yes | The name as the server folded it for matching. |
| totalAvailableBasis | Yes | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnlyHint/idempotentHint annotations by explaining matching modes (strict/fuzzy), Jaro-Winkler scoring, the 'approximate' label, raw score and token coverage, tie-ordering, pagination (totalAvailable, hasMore, nextOffset), and the non-authoritative nature of results. It also clarifies offset behavior (empty page, not error). This is rich behavioral disclosure that significantly aids an agent in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place, front-loading the core purpose and then layering behavioral details, pagination, and the caution about confirmation. It is well-structured and avoids redundancy with the schema or annotations. Despite its length, there is no fluff, and it remains scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, matching algorithms, pagination, and ranking semantics), the description is remarkably complete. It covers purpose, usage, behavioral traits, parameter interplay, pagination flow, and result interpretation. With an output schema present, it does not need to detail return fields, and the caveat about candidate ranking vs. authoritative identification addresses the main confusion risk. No major gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema already describes all 7 parameters with 100% coverage, the description adds critical semantic context beyond field names: it explains how matchMode interacts with strict/fuzzy behavior, what minScore controls (Jaro-Winkler floor), what jurisdiction filters, and the meaning of nextOffset for pagination. This allows an agent to reason about parameter combinations and edge cases (e.g., auto mode when strict is empty) not fully captured in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Resolve a company or organization name... to candidate GLEIF Legal Entity Identifiers (LEIs), ranked.' It uses a specific verb ('Resolve') and resource ('name' → 'LEIs'), and distinguishes itself from siblings by explicitly noting the downstream tools that key off its output (sanctions_get_entity, sanctions_trace_ownership) and framing it as a resolution step, not a screening or entity retrieval step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 it: when a free-text counterparty name needs to be turned into a stable global identifier, and explicitly warns that results are candidate rankings to confirm, not authoritative identification. It does not explicitly contrast with sibling tools like sanctions_screen_name, but the 'key off' phrasing implies this is for entity resolution, not screening. Lacks explicit when-not recommendations, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sanctions_screen_namesanctions-screening-mcp-server: screen nameAScreen a name (person, company, vessel, aircraft) against all loaded sanctions watchlists at once — OFAC SDN + Consolidated, EU, UK, and UN — alias- and fuzzy-aware. Returns scored potential matches with the source list, sanctioning program, designation date, and the matched alias. Strict mode (default) matches exact-normalized then all-tokens-present; fuzzy mode (or auto when strict is empty) adds Jaro-Winkler and phonetic matching and labels hits approximate with a raw 0–1 similarity score plus the count of query tokens the candidate covers, which orders candidates that tie on score. Results are paged: totalAvailable and hasMore report matches beyond the returned page, and nextOffset retrieves them. 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."
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name to screen (person, organization, vessel, or aircraft). | |
| limit | No | Maximum number of potential matches to return in one page. | |
| offset | No | Zero-based index of the first potential match to return. Re-call with the returned nextOffset to page through every match when hasMore is true; an offset past the end returns an empty page, not an error. | |
| sources | No | Restrict to specific source lists. Omit to screen all loaded lists. | |
| minScore | No | Score floor for fuzzy hits (0–1), applied uniformly to every fuzzy candidate regardless of how it was matched (Jaro-Winkler, token, or phonetic). No hit below this score is returned. Applies to fuzzy mode only; defaults to the server's configured floor. | |
| matchMode | No | strict (default): exact-normalized then all-tokens-present. fuzzy: also scored Jaro-Winkler + phonetic. Strict auto-falls-back to fuzzy when it finds nothing. | strict |
| entityType | No | Restrict to one entity class, or "any" (default) to screen across all. | any |
| Name | Required | Description |
|---|---|---|
| hits | Yes | Potential matches, ranked by match type, then score, then how much of the query each candidate explains. |
| caveat | Yes | Decision-support caveat — this is a screening aid, not a compliance determination. |
| notice | No | Guidance when no candidate matched — how to broaden, and what an empty result does NOT mean — or when the requested offset sits past the end of the result set. |
| hasMore | Yes | True when potential matches remain beyond this page — re-call with nextOffset. |
| nextOffset | No | The offset to request next. Present only when hasMore is true. |
| totalCount | Yes | Number of potential matches returned in this page. |
| matchModeUsed | Yes | The match mode actually applied (strict may auto-upgrade to fuzzy on empty). |
| totalAvailable | Yes | Potential matches available across all pages, before limit and offset were applied. |
| normalizedQuery | Yes | The name as the server folded it for matching. |
| totalAvailableBasis | Yes | How to read totalAvailable: exact = the complete strict match 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint=false. The description goes far beyond these by explaining strict-to-fuzzy auto-fallback, approximate hit labeling with Jaro-Winkler/phonetic scores, token coverage ordering, pagination via totalAvailable/hasMore/nextOffset, and the safety caveat that a hit requires human review. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence adds critical detail—matching modes, scoring, pagination, and compliance disclaimer. It is front-loaded with the core purpose and then details behavior, though it is a dense single block without paragraph breaks. Slightly hard to scan, but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex screening tool with 7 parameters and an output schema, the description is complete: it covers the result fields, matching strategies, paging, source coverage, and the crucial compliance limitation. The existence of an output schema means return values need not be repeated, and the description still mentions key return fields naturally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 substantial parameter semantics: it explains matchMode behavior in detail (strict defaults, fuzzy additions, auto-fallback), offset pagination semantics (nextOffset, empty page behavior), minScore uniform application, and source/entity type restriction. This is meaningful added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Screen a name (person, company, vessel, aircraft) against all loaded sanctions watchlists at once'), names the exact source lists (OFAC, EU, UK, UN), and notes alias/fuzzy awareness. This clearly distinguishes it from siblings like sanctions_get_designation or sanctions_resolve_entity, which are retrieval/resolution tools rather than a broad screening tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong usage context: it is for screening against all loaded lists, with a clear warning that it is 'a screening AID for a human/compliance review, NOT a compliance determination' and that an empty result never means 'cleared.' It does not explicitly name alternative tools or say 'use this instead of X,' but the scope is clear enough to distinguish from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sanctions_trace_ownershipsanctions-screening-mcp-server: trace ownershipATrace 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).
| Name | Required | Description | Default |
|---|---|---|---|
| lei | Yes | The 20-character GLEIF LEI at the root of the ownership graph. | |
| depth | No | Maximum traversal depth from the root entity (1–5). | |
| direction | No | Walk parents (who owns it), children (what it owns), or both (default). | both |
| screenNodes | No | When true, screen every node's legal name against all watchlists for beneficial-ownership screening. |
| Name | Required | Description |
|---|---|---|
| edges | Yes | Directed ownership edges between the nodes. |
| nodes | Yes | All entities reached in the traversal, including the root. |
| caveat | Yes | Decision-support caveat — node screening is an aid, not a determination. |
| rootLei | Yes | The LEI the traversal started from. |
| complete | Yes | True 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. |
| truncated | Yes | True 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. |
| screeningStatus | Yes | Whether 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. |
| flaggedNodeCount | Yes | How many screened nodes had at least one potential watchlist match. |
| missingEntityLeis | Yes | LEIs 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. |
| screenedNodeCount | Yes | How many nodes were screened (0 when screenNodes is false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There is a direct contradiction with annotations: the description states 'an empty result for a node is not a clearance of that node,' which implies open-world semantics, while the annotation openWorldHint=false indicates closed-world behavior. This is a serious inconsistency. Although the description adds useful context about truncation and screeningStatus, the contradiction invalidates its transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but each sentence contributes meaningful information: algorithm, screening behavior, response status fields, and prerequisite. It is front-loaded with the primary purpose and avoids redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the traversal algorithm, screening semantics, response limitations (complete/truncated/missingEntityLeis, screeningStatus, capped hits), and the LEI prerequisite. However, the contradiction regarding empty results undermines its completeness in describing the tool's actual behavior, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter descriptions, but the description adds valuable semantic nuance: it explains that screenNodes enables beneficial-ownership screening that resolves whether anyone in the ownership chain is sanctioned, and clarifies that traversal includes 'direct and ultimate' parents/children. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action: 'Trace the GLEIF Level 2 corporate-ownership graph for an LEI' with details on direction and depth. It distinguishes from sibling tools by focusing on graph traversal and optional beneficial-ownership screening, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite ('Requires a valid 20-character LEI') and directs users to a specific sibling tool for obtaining an LEI ('use sanctions_resolve_entity to obtain one'). It implies use when ownership graph information is needed, though it does not explicitly exclude alternative tools for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.