Screen counterparties and enrich companies for AI agents — sanctions checks, cited sources.
Scored across 2 tools
enrich_company and screen_counterparty target entirely different operations—resolving company facts versus checking sanctions lists. There is no overlap or ambiguity between the two tools' purposes.
Both tools follow a consistent verb_noun snake_case pattern (enrich_company, screen_counterparty). The verbs are domain-specific, but the structural convention is uniform.
At two tools, the server sits at the thin end of the range; a sanctions screening server could reasonably include list metadata or screening history lookup. However, the two tools do cover the core enrich-and-screen workflow.
The main sanctions screening workflow is covered: counterparty screening plus company enrichment. Minor gaps exist—no list metadata, no screening history or retrieval endpoint, no batch screening—but they are workarounds rather than critical blockers.
Resolve a company domain or legal name to structured company facts via the free public GLEIF LEI registry.
Inputs: {domain? e.g. "apple.com", name? e.g. "Apple Inc.", request_id? (idempotency)}. At least one of domain/name is required.
v1 boundaries (returned honestly, never invented):
GLEIF has no domain index: domain-only lookups are best-effort (registrable-name candidates are tried). Provide the legal company name for reliable resolution.
GLEIF does not publish industry, industry_code, size_band, or employee_range: those come back null, each with a sources[] entry documenting the gap.
founded is the legal-entity creation date (GLEIF publishes no true founding date).
Unresolvable input -> tool error with code UNRESOLVABLE.
Output: {company_id, legal_name, domain, industry, industry_code, size_band, employee_range, hq: {country, city}, founded, sources: [{field, source, url}], confidence, generated_at}.
EXAMPLE 1: Input: {"domain": "apple.com", "request_id": "demo-e1"} Output: {"company_id": "cs_co_...", "legal_name": "Apple Inc.", "domain": "apple.com", "industry": null, "industry_code": null, "size_band": null, "employee_range": null, "hq": {"country": "US", "city": "Cupertino"}, "founded": "1980-12-12", "sources": [{"field": "legal_name", "source": "GLEIF LEI (api.gleif.org)", "url": "https://api.gleif.org/api/v1/lei-records/..."}, {"field": "industry", "source": "GLEIF LEI — field not published by GLEIF (null by design in v1)", "url": "https://api.gleif.org/api/v1/lei-records/..."}], "confidence": "high", "generated_at": "2026-09-26T...Z"}
EXAMPLE 2 — unresolvable: Input: {"name": "Nonexistent Widgets Pty Ltd ZZ"} Tool error: {"code": "UNRESOLVABLE", "message": "No GLEIF LEI record matched ..."}
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Legal company name, e.g. "Apple Inc.". Reliable path. | |
| domain | No | Company domain, e.g. "apple.com". Best-effort in v1 (GLEIF has no domain index). | |
| request_id | No | Client idempotency key; safe retries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses important behavior: GLEIF has no domain index, several fields are null by design with sources[] documenting gaps, 'founded' is the creation date, and unresolvable input returns an UNRESOLVABLE error. This is exemplary transparency about boundaries and failure modes.
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 well-structured with a front-loaded purpose, clear bulleted boundaries, an output field list, and two concrete examples. Every section earns its place, and the examples significantly help an agent predict behavior.
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?
With no output schema, the description fully documents the return shape, error behavior, field nullability, and source provenance. It covers everything an agent needs to invoke and interpret the tool correctly, including idempotency and best-effort semantics.
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%, and the description adds value by clarifying the anyOf requirement ('At least one of domain/name is required'), explaining request_id as an idempotency key, and giving concrete examples. It mostly reinforces the schema but adds example-level clarity.
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 a specific verb ('Resolve') and resource ('a company domain or legal name') to 'structured company facts' via the GLEIF LEI registry. It is unambiguous about what the tool does, but it does not explicitly differentiate itself from its sibling 'screen_counterparty'.
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 gives clear usage context: domain-only lookups are best-effort, and the legal name should be provided for reliable resolution. It does not explicitly state when to prefer this tool over alternatives or when not to use it, so it misses the full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a counterparty name against the indexed sanctions lists (OFAC SDN, UK FCDO consolidated).
What it does: normalizes the query (Unicode NFKD fold, punctuation strip, lowercase, Cyrillic/Greek transliteration; tolerant to token order e.g. "Putin Vladimir" vs "Vladimir Putin"), looks it up in the sanctions index, and returns EVERY match at low confidence or above with a per-match citation. Low-confidence matches are never hidden.
Inputs:
name (required, string): full name of the person or entity.
country (optional, ISO-3166 alpha-2, e.g. "RU"): corroborates nationality/citizenship identifiers.
dob (optional, "YYYY-MM-DD"): a dob match adds +15 to the score — the strongest corroborator.
identifiers (optional, [{type, value}]): extra identifiers to check against the record, e.g. [{"type":"passport","value":"719023441"}].
request_id (optional, string): idempotency key; safe to retry.
include_low_confidence (optional, boolean, default true): fuzzy matches (Jaro-Winkler >= 0.92) land in the low tier. Keep true — hiding low matches is a compliance liability.
Output: {screening_id, disposition, matches[], disclaimer, generated_at}.
disposition: "clear" (no matches) | "potential_match" (any medium/low match) | "review_advised" (any high-confidence match — human review required before any adverse action).
Each match: {list, list_date, record_uid, matched_name, name_kind (primary|alias_strong|alias_weak), confidence (high|medium|low), confidence_score (0-100), matched_fields, citation {source, url, accessed_at}}.
Confidence math: exact primary 80 / alias_strong 70 / alias_weak 55; dob match +15. Tiers: high >= 85, medium >= 60, low >= 30. Fuzzy (JW >= 0.92) -> low tier, score 30-55.
LANGUAGE RULE: report "potential match", never "sanctioned". Screening is informational only — not a legal verdict. Every response carries the fixed disclaimer.
EXAMPLE 1 — listed individual with corroborating dob: Input: {"name": "Vladimir Putin", "dob": "1952-10-07", "request_id": "demo-001"} Output: {"screening_id": "cs_scr_...", "disposition": "review_advised", "matches": [{"list": "OFAC_SDN", "list_date": "2026-09-23", "record_uid": "35096", "matched_name": "putin vladimir", "name_kind": "alias_strong", "confidence": "high", "confidence_score": 85, "matched_fields": ["name", "dob"], "citation": {"source": "U.S. Treasury OFAC SDN List", "url": "https://sanctionssearch.ofac.treas.gov/", "accessed_at": "2026-09-26T...Z"}}], "disclaimer": "Informational only — not a legal verdict. Not a substitute for due diligence. Human review required before any adverse action.", "generated_at": "2026-09-26T...Z"}
EXAMPLE 2 — same person, no dob (exact alias match, medium): Input: {"name": "Vladimir Putin"} Output: {"screening_id": "cs_scr_...", "disposition": "potential_match", "matches": [{"list": "OFAC_SDN", "list_date": "2026-09-23", "record_uid": "35096", "matched_name": "putin vladimir", "name_kind": "alias_strong", "confidence": "medium", "confidence_score": 70, "matched_fields": ["name"], "citation": {...}}], "disclaimer": "...", "generated_at": "..."}
EXAMPLE 3 — clear name: Input: {"name": "John Smith"} Output: {"screening_id": "cs_scr_...", "disposition": "clear", "matches": [], "disclaimer": "...", "generated_at": "..."}
| Name | Required | Description | Default |
|---|---|---|---|
| dob | No | Date of birth YYYY-MM-DD. Strongest corroborator (+15 score). | |
| name | Yes | Full name of the person or entity to screen. | |
| country | No | ISO-3166 alpha-2 country code, e.g. RU. | |
| request_id | No | Client idempotency key; safe retries. | |
| identifiers | No | Extra identifiers to check against the matched record. | |
| include_low_confidence | No | Return fuzzy low-tier matches (default true). Never hide them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description discloses detailed behavior: Unicode normalization and transliteration, token-order tolerance, never hiding low-confidence matches, exact confidence scoring math and tiers, disposition semantics, and a mandatory language rule. This is rich, behaviorally specific context an agent needs to interpret results correctly.
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 well organized with headings, an input list, output structure, confidence math, and three examples. There is some redundancy with the input schema's parameter descriptions, but the additional rationale and examples justify most of the length and make the tool easier to invoke correctly.
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?
With no output schema present, the description fully compensates by defining the output shape, disposition values, match object fields, confidence tiers, and the disclaimer behavior. It also includes worked examples that show clear, medium, and high-confidence outcomes, leaving little ambiguity about expected behavior.
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 schema already covers 100% of parameters, the description adds real meaning: dob is the strongest corroborator with a +15 score effect, include_low_confidence carries a compliance warning about hiding low matches, request_id is explained as an idempotency key safe for retries, and identifiers are tied to record corroboration. This goes well beyond the baseline of simply restating 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 and resource: 'Screen a counterparty name against the indexed sanctions lists (OFAC SDN, UK FCDO consolidated).' It clearly identifies the tool's domain and differentiates it from the sibling enrich_company by focusing on sanctions screening rather than company enrichment.
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 gives clear context: it is for sanctions-list screening, is informational only, and is not a legal verdict. However, it never explicitly contrasts itself with the sibling tool enrich_company or states when not to use screen_counterparty, so alternatives are somewhat implied rather than directly addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
enrich_companyscreen_counterpartySanctions screening, KYB, identifier validation, jurisdiction risk & secret scanning for AI agents
OFAC sanctions screening for AI agents: screen names, wallets, entities against the SDN list.
EU compliance checks for AI agents: sanctions, company, VAT ID, IBAN, email. Pay per call.
Verify companies, domains and counterparties before transacting. Sanctions, UBO, fraud scoring.
Add one secure layer between your agents and this server.
