Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@US Business Verification MCP Server Verify Palantir Technologies in Colorado and screen it for sanctions"
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.
A zero-dependency Model Context Protocol server that verifies US businesses against official, keyless state registries and screens them against the live OFAC SDN sanctions list — the know-your-business (KYB) checks an agent needs before it trusts a counterparty, with the exact source URL and timestamp on every field.
No API key. No account. No paid proxy. Every record is built from public-domain official sources.
Give it a business name (and optionally a state) and it returns a single structured record:
Scored match — match_confidence (0–1) and match_tier, not a naive string compare, so an
agent can threshold its own risk.
Official identity — entity_name, entity_id, status + normalized status, entity_type,
formation_date, jurisdiction, registered_agent, principal_address.
UCC-lien profile (Colorado) — active liens, secured parties, filing dates — the debt-and- collateral picture an entity lookup alone never shows.
OFAC SDN sanctions screen — the business and its registered agent checked against the live Specially Designated Nationals list, downloaded per call (a delisted entity correctly clears).
Defensible no-match audit — a miss returns no_match_reason and ranked candidates, never a
bare false, so "not found" is explainable.
Provenance on everything — source_url + retrieved_at on every record.
State | Source | Depth |
NY | NY Dept. of State business entities | scored match + status |
CO | CO Secretary of State entities + UCC-lien family | match + full UCC profile |
CT | CT Secretary of the State Business Registry | explicit status + registered agent |
All three are keyless Socrata open-data endpoints published under a public-domain license. Coverage
is derived from the live source registry — list_states always reports the true current set.
Related MCP server: SOS Research MCP
Tool | What it does |
| Verify one or more businesses (names or |
| Screen names directly against the live OFAC SDN list. Per-name verdict ( |
| The states verifiable right now and how each is addressed. No network call. |
| Describes the hosted batch rail for high-volume, metered runs. No network call, no payment. |
Run it straight from the repository — no install, no key:
npx github:rezearcher/business-verification-mcp{
"mcpServers": {
"business-verification": {
"command": "npx",
"args": ["github:rezearcher/business-verification-mcp"]
}
}
}The server speaks MCP stdio (newline-delimited JSON-RPC 2.0). It boots instantly and pulls in no transitive dependencies.
// verify_business { "businesses": ["Palantir Technologies"], "state": "CO" }
{
"input_name": "Palantir Technologies",
"matched": true,
"match_confidence": 0.9,
"entity_name": "Palantir Technologies Inc.",
"entity_id": "20201707433",
"status": "Good Standing",
"status_normalized": "active",
"entity_type": "FPC",
"formation_date": "2020-08-18",
"jurisdiction": "DE",
"ucc": { "checked": true, "jurisdiction": "CO", "has_active_liens": false, "lien_count": 0 },
"source_url": "https://data.colorado.gov/resource/4ykn-tg5h.json?$where=entityid='20201707433'",
"retrieved_at": "2026-11-06T12:43:31.387Z"
}Each state source is a public-domain Socrata open-data dataset; the license is recorded per source before it is added, and a source whose terms prohibit this use is not included. The OFAC SDN list is a US-government work (17 U.S.C. §105, public domain).
These tools are free and keyless. For managed, high-volume batch verification with per-match metered billing (pay only on a confirmed match; no-matches are free), see the hosted rail. The hosted service runs the same core — it adds scale, run history, and metering, not different data.
A scheduled smoke test runs a real MCP client handshake plus a live verification and a live OFAC
load on every push and daily; if an official source changes shape, the roundtrip fails and an issue
is opened automatically. Run it yourself with npm test.
MIT — Grey Ridge Signals Group LLC.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to lean on, the description carries the full burden and does so: it discloses that no network call and no payment occur, that the rail is billed per verified match in USD, and exactly what the response contains (rail URL, price, what it adds). An agent knows the call is instantaneous, free, and side-effect free.
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 the core identity, then the return/behavioral facts. The pricing parenthetical ('pay-per-event, USD, billed only on a verified match') is slightly dense and marketing-flavored, but it is the substance the caller is asking for.
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?
No output schema exists, so the description must describe the return — and it does, enumerating rail URL, price, and added capabilities. For a zero-parameter, read-only info tool, nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema confirms an empty object with additionalProperties=false, so there is nothing to disambiguate; baseline 4 applies.
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?
States a specific verb ('Describe') and a precise resource ('the hosted batch verification rail ... beyond this free server'), and the framing immediately separates it from the sibling verification tools: this returns information about a rail rather than performing verification itself.
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?
Usage context is clear — call it when the user needs high-volume/batch verification beyond what this free server offers, or needs the rail URL and pricing. It stops short of explicitly naming verify_business as the alternative for actual on-server checks, so routing is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the US states currently verifiable through this server (keyless, public-domain official registries) and how each is addressed. No network call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does add real behavioral context: 'No network call' discloses a static, side-effect-free local read, and 'keyless, public-domain official registries' discloses the data provenance and auth model. It does not describe the return shape beyond 'how each is addressed', which is the one remaining gap.
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?
A single sentence with the resource scope front-loaded and the no-network guarantee appended as a supporting clause. Every phrase carries information and nothing is redundant.
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 zero-parameter, annotation-free, no-output-schema tool, the description covers what it lists, why the data is trustworthy, and that no network is involved. Only the shape of 'how each is addressed' is left implicit, which is a minor gap given the 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?
The tool takes zero parameters, so the baseline of 4 applies. Nothing in the description misrepresents the empty input contract, and additionalProperties=false in the schema confirms it takes no arguments.
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?
States a specific verb ('List') and a precisely scoped resource ('US states currently verifiable through this server'), which is clearly distinct from the action-oriented siblings verify_business and screen_sanctions. It stops short of explicitly naming a sibling or contrast, so it does not reach the top band.
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?
Usage is implied rather than stated: an agent can infer this is a discovery/introspection call to run before verify_business, but the description never says 'call this first' or 'use this instead of X'. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Names (person or business) to screen. At least one required. | |
| minConfidence | No | Minimum confidence (0-1) for a reported hit. Default 0.85. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that the list is downloaded live per call, that freshness means delisted entities return clear, that matching uses IDF-weighted contiguous-phrase containment rather than naive substring, and it enumerates the per-name return fields. It omits latency implications of a per-call download, error/failure behavior, and any auth or rate-limit considerations.
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, each front-loaded with the core fact (what it screens against, then what it returns, then how matching works). The parentheticals are dense but carry substantive information rather than filler.
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 two-parameter tool with no output schema, the description is complete: it enumerates the returned fields, the verdict vocabulary, and the matching approach. An agent has everything needed to call it and interpret results.
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 description coverage is 100%, so the schema already documents both parameters and the baseline is 3. The description reinforces the batch semantics of 'names' and mentions a confidence score in the results, but does not clarify how minConfidence affects the reported verdicts beyond the schema's default note.
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?
States a specific verb and resource (screen names against the live OFAC SDN list) and explicitly scopes it as 'no state lookup', which distinguishes it from the sibling verify_business. An agent can identify this as a sanctions-screening tool without opening the schema.
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 'no state lookup' clause implicitly contrasts with a state-registry path, giving clear context for when to pick this tool, and 'one or more names' indicates batch use. It does not explicitly name an alternative sibling or state a when-not condition, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional default 2-letter state to scope all lookups (NY, CO, CT). Omit to try all live states. | |
| maxItems | No | Cap the number of businesses verified in one call. Default 50, max 200. | |
| businesses | Yes | Business names (strings) or {name, state} objects. At least one required. | |
| includeUcc | No | Attach the CO UCC-lien profile on Colorado matches. Default true. | |
| minConfidence | No | Minimum match_confidence (0-1) for matched=true. Default 0.85. | |
| includeSanctions | No | Screen each match against the OFAC SDN sanctions list. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does most of it: default-on sanctions screening and UCC attachment, no-match behavior returning a defensible audit record with reasons and candidates rather than a bare false, provenance via source_url and retrieved_at, and keyless auth with no API key. It omits rate limits, error/timeout behavior, and how batch failures are reported, which keeps it short of a 5.
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?
Long but dense sentences, front-loaded with the core action and jurisdiction scope before the return contract and defaults. The return-field enumeration is verbose, though each clause conveys real information an agent needs.
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?
No output schema and no annotations exist, so the description must define the response — and it does, listing per-input records, match_confidence, entity attributes, provenance, and the UCC/no-match branches. Only failure modes and throughput limits are unaddressed for a batch tool.
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, and the description largely restates schema semantics (string-or-object businesses, per-item state, UCC and sanctions toggles). It does add modest meaning by explaining what includeUcc actually attaches (active liens, secured parties, dates) and ascribes a scored match_confidence against minConfidence, but says nothing about maxItems or minConfidence tuning beyond the defaults.
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?
A precise verb + resource (verify businesses against official state business-registry sources) with the exact live jurisdictions named and the accepted input shapes spelled out. An agent can distinguish it from screen_sanctions (sanctions-only) or list_states (enumeration) without opening any schema.
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?
Implicit usage is clear: batch-verify names, optionally scoped by state, with UCC and sanctions enrichment on by default. It never explicitly says when to call this versus screen_sanctions (the sanctions step is bundled by default) or list_states for discovering valid state codes, so routing is left to inference.
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.
v0.1.0get_hosted_accesslist_statesscreen_sanctionsverify_businessScored 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.
Screen a business for federal exclusions & sanctions: OFAC SDN, HHS-OIG LEIE, SAM.gov debarment.
Screen a US company against SEC EDGAR, OFAC sanctions, federal awards and federal court dockets.
Screen people & companies against 12 US sanctions & exclusion lists (OFAC, LEIE, SAM, Medicaid).
Company and domain due diligence for agents: registers, sanctions, VAT, domain. Pay per call.
