What can you do with this server?

This server provides an AI-driven KYC/AML compliance system that uses Claude to orchestrate due diligence checks, backed by a host layer enforcing mandatory controls and generating tamper-evident audit logs. It produces clear outcomes (PASS, ESCALATE, or FAIL) with a 0–10 risk score. Core Compliance Tools: * Sanctions Screening (screen_sanctions): Screen individuals or entities against the live OFAC SDN list. A match is disqualifying and triggers a FAIL. * Identity Verification (verify_identity): Structurally validate SSN format/range, driver's license format by state, and address presence. Returns VALID_FORMAT, INVALID_FORMAT, SUSPICIOUS, or INSUFFICIENT_DATA — structural only, not identity confirmation. * Business Lookup (lookup_business): Verify whether a company is an SEC-registered filer via EDGAR. A no-match is not automatically disqualifying for private companies. * Industry Risk Assessment (assess_industry_risk): Classify industries into PROHIBITED (hard FAIL), STATE_CONDITIONAL (ESCALATE, e.g. cannabis), ELEVATED (enhanced due diligence), or STANDARD tiers. * Country Risk Assessment (assess_country_risk): Score countries 0–10 for AML/sanctions risk; scores ≥7 trigger ESCALATE for enhanced due diligence. * PEP Screening (screen_pep): Screen for Politically Exposed Person status. Currently a stub integration point — returns INTEGRATION_POINT, mandating manual enhanced due diligence and never treated as a clean result. System-Level Capabilities: * Mandatory Control Enforcement: The host layer ensures sanctions screening and industry checks always run regardless of AI discretion. * Decision Validation: Validates and can override the AI's proposed decisions; overrides can only make outcomes stricter. * Tamper-Evident Audit Logging: Hash-chained, append-only logs capture every step — requests, tool calls, results, model decisions, overrides, and final outcome — for regulatory defensibility. * Web UI: A React-based interface displays decisions, tool call sequences, and officer-gated detailed findings with audit traces. * MCP Integration: Designed for MCP clients like Claude Desktop; also includes an Inspector UI for developer testing of raw JSON-RPC traffic.

How do I use KYC Compliance MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@KYC Compliance MCP Server Screen Acme LLC, a Texas firearms retailer, for KYC." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

KYC Compliance MCP Server

by esskay2016

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

This server provides an AI-driven KYC/AML compliance system that uses Claude to orchestrate due diligence checks, backed by a host layer enforcing mandatory controls and generating tamper-evident audit logs. It produces clear outcomes (PASS, ESCALATE, or FAIL) with a 0–10 risk score.

Core Compliance Tools:

Sanctions Screening (screen_sanctions): Screen individuals or entities against the live OFAC SDN list. A match is disqualifying and triggers a FAIL.
Identity Verification (verify_identity): Structurally validate SSN format/range, driver's license format by state, and address presence. Returns VALID_FORMAT, INVALID_FORMAT, SUSPICIOUS, or INSUFFICIENT_DATA — structural only, not identity confirmation.
Business Lookup (lookup_business): Verify whether a company is an SEC-registered filer via EDGAR. A no-match is not automatically disqualifying for private companies.
Industry Risk Assessment (assess_industry_risk): Classify industries into PROHIBITED (hard FAIL), STATE_CONDITIONAL (ESCALATE, e.g. cannabis), ELEVATED (enhanced due diligence), or STANDARD tiers.
Country Risk Assessment (assess_country_risk): Score countries 0–10 for AML/sanctions risk; scores ≥7 trigger ESCALATE for enhanced due diligence.
PEP Screening (screen_pep): Screen for Politically Exposed Person status. Currently a stub integration point — returns INTEGRATION_POINT, mandating manual enhanced due diligence and never treated as a clean result.

System-Level Capabilities:

Mandatory Control Enforcement: The host layer ensures sanctions screening and industry checks always run regardless of AI discretion.
Decision Validation: Validates and can override the AI's proposed decisions; overrides can only make outcomes stricter.
Tamper-Evident Audit Logging: Hash-chained, append-only logs capture every step — requests, tool calls, results, model decisions, overrides, and final outcome — for regulatory defensibility.
Web UI: A React-based interface displays decisions, tool call sequences, and officer-gated detailed findings with audit traces.
MCP Integration: Designed for MCP clients like Claude Desktop; also includes an Inspector UI for developer testing of raw JSON-RPC traffic.

KYC Compliance MCP Server

An agentic KYC/AML compliance system built on the Model Context Protocol (MCP). An MCP server exposes compliance checks as tools, and an AI model (Claude) decides which tools to call and in what order to perform customer due diligence — wrapped in a host layer that enforces the legally non-negotiable checks, validates the model's decision, and writes a tamper-evident audit log.

The point: the model does the discretionary investigation; deterministic code enforces the mandatory controls and records everything. That hybrid — a reasoning core inside compliance rails — is the difference between a demo and something defensible in a regulated setting.

Note: this is a proof-of-concept for demonstrating MCP orchestration and compliance architecture, not a production compliance system. See Notes / limitations below — several data sources are deliberately stubbed as honest integration points because the real data is licensed or legally gated.

Architecture

applicant ─► HOST: enforce mandatory sanctions screen (always runs)
                │
                ▼
            CLAUDE orchestrates the rest — picks tools, reads results, decides:
            verify_identity · assess_industry_risk · lookup_business ·
            screen_pep · assess_country_risk
                │
                ▼
            HOST: validate the model's decision against the gathered facts
                  (overrides can only make the outcome STRICTER, never looser)
                │
                ▼
            FINAL DECISION  +  hash-chained AUDIT LOG (tamper-evident)

The decision is one of PASS / ESCALATE / FAIL, where ESCALATE routes the case to a human for enhanced due diligence — the honest posture for an AI first-pass triage tool.

Related MCP server: @deepidv/mcp-server

Risk score

Each result carries a risk score from 0 to 10 where HIGHER means MORE risky (this is the opposite direction of a credit score, so it can be counterintuitive):

0–3 low risk — e.g. a clean standard-industry business with domestic owners
4–6 moderate risk — elevated factors present, warrants attention
7–10 high risk — a hard gate hit (sanctions, prohibited industry), failed identity validation, or high country risk

A low score does not guarantee a PASS: an unresolved integration-point check (e.g. PEP) can still force an ESCALATE even at 2/10, because final clearance requires that check be completed manually.

Tools

Tool	What it does	Backed by
`screen_sanctions`	Screens names against the live OFAC SDN list	treasury.gov OFAC SDN (live)
`verify_identity`	Structural SSN / driver's-license / address validation	SSA rules + state DL formats (live, no key)
`assess_country_risk`	0–10 country risk score + band	World Bank indicators (+ proxy overrides)
`lookup_business`	Verifies a company is an SEC-registered filer	SEC EDGAR (live, no key)
`assess_industry_risk`	PROHIBITED / STATE_CONDITIONAL / ELEVATED / STANDARD	NAICS-keyed rules (built in)
`screen_pep`	Politically Exposed Person screening	Integration-point stub (see caveats)

The industry tool encodes real regulatory nuance: weapons are a hard gate; cannabis is state-conditional (legal-program states → escalate for enhanced due diligence; non-program states → decline); crypto, gambling, cash-intensive, etc. are elevated-risk inputs the model weighs.

Why this is an MCP showcase

The model orchestrates the calls. Given a business applicant it will typically call assess_industry_risk first (a PROHIBITED result can short-circuit to FAIL), then screen_sanctions on the company and each owner, lookup_business to verify the entity, and assess_country_risk on any non-US owner. For a personal applicant it calls and verify_identity. That orchestration is the model's, not the code's — which is what distinguishes MCP from a fixed serverless pipeline.

Web UI

A React UI (ui/) drives the agent over an Express backend. It shows the decision and the tool-call sequence ("how the agent investigated") to anyone, while detailed findings and the audit trace are officer-gated behind a passcode — demonstrating both the orchestration and an access-control boundary. See UI_SETUP.md to run it.

Run it

npm install
npm run build

Test with the MCP Inspector (recommended first step)

npm run inspect

This opens the Inspector UI (port 6274). You can fire each tool manually and watch the raw JSON-RPC traffic — the fastest way to confirm the tools work before wiring a host.

Wire into Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "kyc-compliance": {
      "command": "node",
      "args": ["/absolute/path/to/kyc-mcp-server/dist/index.js"]
    }
  }
}

Restart Claude Desktop, then ask it to "run KYC due diligence on Acme LLC, a firearms retailer in Texas with owners Jane Doe and John Roe" — it will discover and call the tools.

Compliance guardrails (the host layer)

"The model decides which tools to call" is great for capability but unacceptable on its own in a regulated setting — a missed sanctions check is a violation, not a bug. The src/host/ layer wraps the model so it reasons inside deterministic rails:

Mandatory-screening enforcement (orchestrator.ts) — sanctions screening (and, for businesses, industry classification) always run, executed by the host, regardless of whether the model would have chosen to call them. The model never gets to skip a required check.
Output validation (validation.ts) — the model's PASS/FAIL/ESCALATE is checked against the hard screening facts. A potential OFAC match or a PROHIBITED industry forces FAIL even if the model said PASS; a state-conditional industry or high country risk forces at least ESCALATE. Overrides only ever make the outcome stricter, never looser.
Hash-chained audit log (audit.ts) — every request, tool call, tool result, model decision, override, and final decision is written to an append-only, SHA-256 hash-chained log. Editing any past entry breaks the chain and is detectable — this is what you hand an examiner to reconstruct why any customer was approved or declined.

The division of labor: the model orchestrates the discretionary analysis; the code enforces the non-negotiable checks and records everything. That hybrid — reasoning core, deterministic guardrails — is the difference between a demo and a system you could defend in a compliance review.

Screenshots

Clean business applicant (PASS): All checks pass; decision is PASS at 3/10 risk. Escalation due to lack of PEP integration.

State-conditional industry (ESCALATE): Cannabis in California triggers state-conditional escalation for enhanced due diligence.

Prohibited industry (FAIL): Weapons dealer hard-gate; decision is FAIL at 10/10 risk.

Officer-gated findings: Detailed per-tool findings and audit trace are revealed only after entering the passcode.

Notes / limitations

Sanctions matching is simple (token match, not fuzzy/phonetic). Real screening adds secondary identifiers (DOB, nationality) to cut false positives. The architecture — live government data driving the decision — is the point. (You'll see common names like "Maria Garcia" produce false-positive potential matches; the system fails safe by escalating, which is the correct direction.)
Country risk uses a small override table plus a World Bank indicator fallback, as a public proxy for a licensed country-risk feed. The country-name→ISO lookup is thin; passing ISO-2 codes (e.g. "BR") is most reliable.
Business lookup covers SEC filers only. lookup_business uses SEC EDGAR (free, no key), which only contains public / SEC-registered companies. A no-match is EXPECTED for most small private LLCs and is NOT disqualifying — the tool says so in its note. Full private-entity coverage requires OpenCorporates (paid) or per-state Secretary-of-State integration (California has a key-gated API; Delaware is CAPTCHA-protected with paywalled status). Those are defined as production integration points, not built here.
Identity verification is structural only. verify_identity validates SSN format/range (SSA rules), driver's-license format per state, and address presence — it catches fabricated or malformed identifiers, but does NOT confirm they belong to the person. Authoritative match (SSN-to-name via SSA eCBSV, DL-to-record via AAMVA/DMV) is legally gated to permitted entities with consumer consent, so it's a documented production integration point.
PEP screening is an integration point, not live. screen_pep returns an INTEGRATION_POINT status, not a clean result. Credible PEP data is licensed — OpenSanctions has strong PEP coverage but its API requires a key/commercial license, and World-Check / Dow Jones / LexisNexis are commercial. PEP is a required KYC control, so the tool seam is built and the model is told to treat the result as "manual EDD required" rather than "no PEP found." Production supplies provider credentials.

Roadmap

Wire EU/UK consolidated lists into screen_sanctions (the parameter already exists)
Fuzzy name matching with secondary identifiers
A thin host backend + the existing React UI as the front end

Available Tools

6 tools

assess_country_riskA

Assess AML/sanctions country risk for a given country (name or ISO-2 code), returning a 0-10 risk score and band. Call for the applicant's country and for any beneficial owner whose country differs. Score >= 7 should drive ESCALATE.

ParametersJSON Schema

Name	Required	Description	Default
`country`	Yes	Country name or ISO-2 code, e.g. 'United States' or 'US'.

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided, so description must cover behavioral traits. It discloses return format and score interpretation but omits details like idempotency, authorization needs, or data sources. Adequate for a simple risk assessment tool.

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

Conciseness5/5

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

Two concise sentences: first states purpose and output, second provides usage guidance and threshold. No redundant information.

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 simple tool (one parameter, no output schema), the description fully explains input, output, and usage context. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and description adds minimal extra meaning beyond the schema (e.g., 'name or ISO-2 code'. Does not elaborate on validation or formatting beyond what schema provides.

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?

Description clearly states the verb 'assess', resource 'country risk', and output '0-10 risk score and band'. Distinguishes from siblings like assess_industry_risk by specifying country risk.

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?

Explicitly states when to call: for applicant's country and beneficial owner's country if different. Provides actionable threshold for escalation (score >= 7). Lacks explicit exclusions but contextually sufficient.

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

assess_industry_riskA

Classify a business industry for AML risk. Returns one of PROHIBITED (hard gate — decision must be FAIL), STATE_CONDITIONAL (e.g. cannabis — legality depends on state, drive ESCALATE), ELEVATED (allowed with enhanced due diligence), or STANDARD. Call for every business applicant. Pass the state so cannabis can be resolved correctly.

ParametersJSON Schema

Name	Required	Description
`industry`	Yes	Free-text industry description, e.g. 'firearms retailer'.
`naics`	No	Optional NAICS code if known.
`state`	No	US state of operation (2-letter), needed to resolve state-conditional industries.

TDQS

A4.7/5.0

Behavior5/5

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

No annotations provided; description fully discloses behavioral traits: return values (PROHIBITED, STATE_CONDITIONAL etc.) and their implications ('hard gate — decision must be FAIL', 'drive ESCALATE'). No contradictions.

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

Conciseness5/5

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

Three concise sentences, front-loaded with purpose, clear enumeration of return values, and actionable guidance. No redundant content.

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 no output schema and three parameters, description fully covers purpose, usage, return categories, and parameter roles. Complete for an agent to invoke correctly.

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 baseline 3. Description adds value by explaining the free-text nature of industry, optional NAICS, and why state is needed ('cannabis can be resolved correctly').

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 uses specific verbs ('Classify a business industry for AML risk') and lists all four return categories, clearly distinguishing this tool from siblings like assess_country_risk.

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?

Explicitly says 'Call for every business applicant' and instructs to pass state for correct resolution. Does not explicitly exclude scenarios or name alternatives, but context is clear.

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

lookup_businessA

Look up a business entity in the SEC EDGAR registry to verify it is a real, SEC-registered filer. Call for any business applicant. Note: only public/SEC-registered companies appear — a no-match is expected for small private LLCs and is NOT itself disqualifying, but an applicant claiming to be a public company with no EDGAR match is a red flag worth ESCALATE.

ParametersJSON Schema

Name	Required	Description	Default
`companyName`	Yes	Legal company name to search.
`jurisdiction`	No	Optional; not used for EDGAR (kept for interface compatibility).

TDQS

A4.1/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that the tool queries SEC EDGAR, explains match/no-match outcomes, and notes escalation condition. Does not explicitly state read-only nature or discuss rate limits/authentication.

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

Conciseness5/5

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

Two sentences plus a note, front-loaded with purpose. Every sentence earns its place with no wasted text. Compact and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no output schema, so description should explain return values. It implies a match result but does not explicitly describe the output format or fields. Missing this key detail for a simple lookup tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage with descriptions for both parameters. Description adds no new semantics beyond the schema; both params are adequately documented. Baseline 3 as schema already covers meaning.

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 it looks up a business in the SEC EDGAR registry to verify registration. It uses specific verb+resource (look up, SEC EDGAR registry) and distinguishes from sibling tools (risk assessment, screening, identity verification) by focusing on SEC registration.

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?

Explicitly says 'Call for any business applicant' and provides important interpretation guidance (no-match expected for LLCs, red flag for claimed public companies). Lacks explicit exclusions or alternative tool references for similar lookups.

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

screen_pepA

Screen names for Politically Exposed Person (PEP) status. NOTE: this is an integration point — credible PEP data is licensed (OpenSanctions key/license, World-Check, Dow Jones). It returns a defined-but-not-live status, NOT a clean result. A returned status of INTEGRATION_POINT means PEP screening must be completed manually as an enhanced-due-diligence step; do not treat it as 'no PEP found'.

ParametersJSON Schema

Name	Required	Description	Default
`names`	Yes	Names to screen for PEP status.

TDQS

A4.1/5.0

Behavior4/5

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

Discloses that output is not a live result but a 'defined-but-not-live status' with INTEGRATION_POINT value. Warns against misinterpreting it as clean. No annotations, so description carries burden.

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?

Well-structured with cautionary note. Slightly verbose but each sentence adds value. Efficient for explaining a nuanced behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, return value, and caveat. No output schema, so description compensates by explaining the result semantics. Could mention authentication or rate limits but sufficient for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single 'names' parameter. Description adds context about processing these names but no new format or constraints beyond schema.

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?

Clear verb 'Screen' and specific resource 'PEP status'. Distinguishes from sibling 'screen_sanctions' by focusing on PEP.

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?

Explicitly states when not to treat result as final (integration point), implying manual due diligence. Provides context but no direct 'when not to use' compared to alternatives.

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

screen_sanctionsA

Screen one or more individual or entity names against the live OFAC SDN sanctions list. Call this for every applicant, every beneficial owner, and every company name. A potential match must be treated as disqualifying (FAIL) pending human review.

ParametersJSON Schema

Name	Required	Description	Default
`names`	Yes	Full names to screen: applicant, each beneficial owner, and company.
`extraLists`	No	Optional additional lists requested, e.g. 'EU Consolidated', 'UK Sanctions'.

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description discloses the live screening behavior and the significance of matches. It does not cover rate limits or error handling but adequately sets expectations for a screening tool.

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

Conciseness5/5

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

Two concise sentences: first states purpose, second gives usage instruction and rule. No fluff, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and lack of output schema, the description covers purpose and usage but does not describe the return value or error states, which would help an agent interpret results fully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, just reiterating 'full names' and providing context for the disqualifying rule.

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 verb 'screen' and the resource 'live OFAC SDN sanctions list'. It distinguishes from sibling tools like screen_pep by specifying the exact list and usage for applicants, beneficial owners, and company names.

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 gives explicit instructions to call for every applicant, beneficial owner, and company name, and mandates that potential matches be treated as disqualifying pending human review. It lacks explicit when-not-to-use or alternatives but is very directive.

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

verify_identityA

Validate a personal applicant's identity documents structurally: SSN format/range (SSA rules), driver's-license format for the claimed state, and address presence. Returns VALID_FORMAT / INVALID_FORMAT / SUSPICIOUS / INSUFFICIENT_DATA. NOTE: this is structural validation only — it does NOT confirm the identifiers belong to the person (authoritative SSA/DMV match is a gated integration point). INVALID_FORMAT is a red flag.

ParametersJSON Schema

Name	Required	Description
`ssn`	No	SSN (any format; digits extracted).
`driversLicense`	No	Driver's license number.
`state`	No	US state (2-letter) for DL format rules.
`address`	No	Residential address.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses that validation is structural and not identity confirmation, preventing misuse. It also lists possible return values, adding behavioral context.

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

Conciseness5/5

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

Two sentences plus a crucial note; no filler. The most important information (purpose and limitation) is front-loaded, making it efficient for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately covers purpose, behavioral limitations, and return statuses. It omits error handling details but is sufficient for an agent to understand tool scope and use.

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%, but the description adds meaning by explaining what validations are performed (SSN rules, DL format, address presence). This goes beyond the schema's generic property 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 it validates identity documents structurally, specifying checks on SSN format/range per SSA rules, driver's license format by state, and address presence. It returns specific statuses like VALID_FORMAT, distinguishing it from risk assessment and screening siblings.

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 notes it is structural validation only, not authoritative match, and that INVALID_FORMAT is a red flag. While it doesn't explicitly state when to use versus alternatives, it sets expectations and distinguishes from authoritative verification.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv1.0.0Jun 24, 2026
- First observedassess_country_risk
- First observedassess_industry_risk
- First observedlookup_business
- First observedscreen_pep
- First observedscreen_sanctions
- First observedverify_identity

Deploy Server

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

TDQS

A4.4/5.0

Scored 2026-06-24 02:15 across 6 tools

Disambiguation5/5

Each tool targets a distinct aspect of KYC compliance: country risk, industry risk, business entity lookup, PEP screening, sanctions screening, and identity verification. There is no overlap; each has a clear, separate purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., assess_country_risk, screen_pep, verify_identity). The naming is uniform and predictable, aiding agent understanding.

Tool Count5/5

Six tools is an ideal number for a KYC compliance server. It covers essential risk assessment, entity verification, and screening functions without being excessive or insufficient.

Completeness4/5

The set covers core KYC operations, but lacks tools for automated PEP resolution (noted as integration point), document upload verification, or ongoing monitoring. Minor gaps exist but do not severely hinder basic workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Didit MCP ServerOAuth
me.didit
KYC, KYB, AML, wallet screening, transaction monitoring, and fraud workflows for AI agents.
Security Cryptocurrency Finance
2
sanctions-screening A
com.watchtower-api
Sanctions screening, KYB, identifier validation, jurisdiction risk & secret scanning for AI agents
Legal & Compliance Security
2
VerifaOAuth
io.github.Verifa-Solutions
Identity verification, document checks, sanctions/PEP screening and case review as agent tools.
Security Legal & Compliance
1
BlockchainAnalysis A
io.blockchainanalysis
Compliance MCP for AI agents: sanctions & KYT screening on 50+ chains, stablecoin-freeze, oracle.
Cryptocurrency Blockchain Security
113

Related MCP Servers

agentmail
Autonomous Agents Security
kindrat86
A
license
A
quality
A
maintenance
Provides AI agents with compliance screening (OFAC sanctions, risk scoring, Know-Your-Agent) plus disposable email and SMS verification for OTPs, accessible via MCP tools, HTTP API, and CLI.
Updated 2 hours ago (2026-09-17 17:14 UTC)
10
2
MIT
@deepidv/mcp-serverofficial
Security Legal & Compliance
Deep-Identity-Inc
A
license
Not graded
quality
C
maintenance
Enables AI agents to perform identity verification, KYC/KYB, PEP & sanctions screening, bank statement analysis, and workflow automation via the Model Context Protocol.
Updated 2 months ago (2026-07-13 13:48 UTC)
MIT
Concept-4 Compliance Engine
Legal & Compliance Security Blockchain
Lyrus-Sal
A
license
B
quality
B
maintenance
Autonomous M2M compliance and trust APIs for AI agents (KYB, OFAC, VAT, Sanctions checking).
Updated 2 months ago (2026-07-20 10:48 UTC)
5
MIT
eKYC Suite MCP Serverofficial
Security Finance
wefi-ai
A
license
A
quality
B
maintenance
Provides 8 financial-grade KYC identity verification tools for AI agents, including face comparison, liveness detection, document OCR, and risk media labeling.
Updated 2 months ago (2026-07-21 07:02 UTC)
8
67 npm
4
MIT

KYC Compliance MCP Server

Architecture

Risk score

Tools

Why this is an MCP showcase

Web UI

Run it

Test with the MCP Inspector (recommended first step)

Wire into Claude Desktop

Compliance guardrails (the host layer)

Screenshots

Notes / limitations

Roadmap

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

@deepidv/mcp-serverofficial

eKYC Suite MCP Serverofficial