US Business Verification MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
US business verification against official state sources. Call list_states for coverage, verify_business to verify one or more businesses (scored match + status + formation + UCC + OFAC screen), and screen_sanctions to check names against the live OFAC SDN list. These are free and keyless. For managed high-volume batch runs with per-match billing, call get_hosted_access.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| verify_businessA | Verify one or more US businesses against official, keyless state business-registry sources (currently NY, CO, CT). Each business may be a bare name string ("Palantir Technologies") or an object {name, state}. Returns one record per input with a scored match_confidence, the official entity_name, entity_id, status (+ normalized status), entity_type, formation_date, jurisdiction, registered_agent and principal_address — plus the exact source_url and retrieved_at timestamp. On a Colorado match it attaches a UCC-lien profile (active liens, secured parties, dates). By default every match is also screened against the OFAC SDN sanctions list. No-matches return a defensible audit record (no_match_reason + candidates), never a bare false. Keyless, public-domain sources, no API key. |
| screen_sanctionsA | Screen one or more names directly against the live OFAC SDN (Specially Designated Nationals) sanctions list — no state lookup. Returns per-name verdict (clear | potential_match | match), matched program(s), the alias or primary name that matched, a confidence score, and the exact OFAC source URL. The list is downloaded live per call (freshness: delisted entities correctly return clear). Matching uses distinctiveness learned from the list itself (IDF-weighted contiguous-phrase containment), not a naive substring, to suppress false positives. |
| list_statesA | List the US states currently verifiable through this server (keyless, public-domain official registries) and how each is addressed. No network call. |
| get_hosted_accessA | Describe the hosted batch verification rail available beyond this free server: the same core run managed at high volume with per-match metered billing (pay-per-event, USD, billed only on a verified match). Returns the rail URL, price, and what it adds. No network call, no payment. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
verify_business, screen_sanctions, list_states and get_hosted_access each target a clearly different action/resource, so an agent can pick between them. The only soft overlap is that verify_business already screens against OFAC by default, leaving slight ambiguity about when to call screen_sanctions standalone (the description does clarify it is for names without a state lookup).
All four tools follow a strict verb_noun snake_case pattern: verify_business, screen_sanctions, list_states, get_hosted_access. Consistent verbs (verify/screen/list/get) with no camelCase or stylistic drift.
Four tools is lean but defensible for a focused verification server: one core lookup, one screening primitive, one discovery helper, one access-info helper. Slightly under-scoped because get_hosted_access is an upsell/informational tool rather than a functional capability, so the operational surface is effectively three tools.
Core lifecycle is covered: batch verification with structured audit records and no-match handling, direct sanctions screening, and state coverage discovery. Minor gaps exist — no standalone lookup by entity_id, no UCC-lien tool outside the Colorado attachment, and no way to enumerate or filter entities within a state.