Creates a Stripe checkout session to purchase additional credits for the BizVerify account.
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., "@BizVerify MCP Server verify 'Stripe Inc' in Delaware"
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.
KYB for AI agents — verify and search business entities across US state and international company registries, straight from any MCP client.
BizVerify confirms a company's legal existence, status, good standing, registered agent, officers, and filing history by reading official government business registries in real time.
The canonical BizVerify MCP server is hosted as a Streamable HTTP endpoint:
https://api.bizverify.co/mcpThis repository packages that server as a local stdio bridge (plus a Docker image) for MCP clients and sandboxes that expect a local process. The bridge is a thin transparent proxy — tool definitions and results come directly from the hosted server, so it never drifts out of sync.
Tool | Auth | What it does |
| – | Supported jurisdictions, credit pricing, packages, features |
| – | All jurisdictions with capabilities and active status |
| ✅ | Confirm a named business in one jurisdiction — existence, status, good standing (quick), plus entity type, formation date, registered agent, officers, principal address and filings (deep) |
| ✅ | Discover candidate businesses by name across one or all active jurisdictions |
| ✅ | Poll an async verification job (free) |
| ✅ | Retrieve cached entity data by ID (free) |
| ✅ | Historical verification snapshots for an entity |
| ✅ | Account details and credit balance |
| ✅ | Create a Stripe checkout session for more credits |
Tools marked ✅ require an API key (or OAuth token). get_config and list_jurisdictions are free and unauthenticated.
Related MCP server: ENTIA Entity Verification
If your client supports remote MCP servers, just point it at https://api.bizverify.co/mcp and send your key as an X-API-Key header (OAuth 2.1 Bearer tokens are also accepted).
For stdio-only clients, bridge the hosted endpoint with mcp-remote:
{
"mcpServers": {
"bizverify": {
"command": "npx",
"args": [
"-y", "mcp-remote", "https://api.bizverify.co/mcp",
"--header", "X-API-Key:${BIZVERIFY_API_KEY}"
],
"env": { "BIZVERIFY_API_KEY": "your-api-key" }
}
}
}git clone https://github.com/BizVerify/bizverify-mcp.git
cd bizverify-mcp
npm install
npm run buildThen register it with your client (Claude Desktop, Cursor, etc.):
{
"mcpServers": {
"bizverify": {
"command": "node",
"args": ["/absolute/path/to/bizverify-mcp/dist/index.js"],
"env": { "BIZVERIFY_API_KEY": "your-api-key" }
}
}
}docker build -t bizverify-mcp .
docker run -i --rm -e BIZVERIFY_API_KEY=your-api-key bizverify-mcp{
"mcpServers": {
"bizverify": {
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "BIZVERIFY_API_KEY", "bizverify-mcp"],
"env": { "BIZVERIFY_API_KEY": "your-api-key" }
}
}
}Env var | Required | Default | Description |
| For authenticated tools | – | Your BizVerify API key, sent as |
| No |
| Override the upstream MCP endpoint. |
Create one in seconds — new accounts get 50 free credits:
# 1. Request an access code (sent by email)
curl -X POST https://api.bizverify.co/v1/auth/request-access \
-H 'Content-Type: application/json' \
-d '{"email":"you@example.com","accept_terms":true}'
# 2. Exchange the 6-digit code for an API key
curl -X POST https://api.bizverify.co/v1/auth/verify-access \
-H 'Content-Type: application/json' \
-d '{"email":"you@example.com","code":"123456","label":"mcp"}'See the setup guide and docs for full details.
npm install
npm run build # compile to dist/
npm run typecheck # type-check only
npm start # run the stdio bridge
# Refresh the offline tool snapshot from the live endpoint
node scripts/gen-snapshot.mjsThe bundled src/tools-snapshot.ts is used only as an offline fallback for tools/list (e.g. during a sandboxed container check). Live calls always proxy to the hosted server.
🌐 Website: https://bizverify.co
🔌 MCP setup guide: https://bizverify.co/mcp/
📚 Docs: https://docs.bizverify.co
🧩 Glama connector: https://glama.ai/mcp/connectors/co.bizverify/mcp
MIT © BizVerify
Poll a long-running (async) verification job created by verify_business. Returns the full verification result once complete, a failure reason if it failed, or a "still processing" status to poll again. Free — no credits charged — but requires authentication. Pass the job_id from the verify_business async response.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job ID returned by verify_business when it runs asynchronously |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds valuable context: it discloses that the tool is free (no credits charged), requires authentication, and details the three possible return states (complete result, failure reason, or 'still processing'). This goes beyond annotations and provides essential operational information.
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 three sentences, each earning its place: first sentence states purpose and source, second details return states, third covers cost, authentication, and parameter origin. It is front-loaded, efficient, and without redundant wording.
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 a single well-documented parameter, strong annotations, and no output schema, the description covers all necessary context: purpose, behavior, return types, cost, auth, and how to obtain the required parameter. It is 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?
Schema coverage is 100% with job_id described as 'Job ID returned by verify_business when it runs asynchronously.' The description's instruction to 'Pass the job_id from the verify_business async response' essentially repeats the schema description, adding no new semantic meaning. Baseline 3 is appropriate given the high coverage.
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 uses a specific verb 'Poll' and identifies the resource as 'a long-running (async) verification job created by verify_business.' It clearly distinguishes this tool from siblings like verify_business (which creates the job) and get_account, get_config, etc. by focusing exclusively on polling job status.
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 explicitly states this tool is for polling jobs created by verify_business and instructs to pass the job_id from verify_business's async response, making the usage context clear. It does not explicitly address when-not-to-use or alternatives, but given the unique polling role among siblings, this is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns your BizVerify account summary: email and verification status, plan, current credit balance, member-since date, and your active and revoked API keys. Free and read-only; requires authentication. Use it to check your remaining credit balance before running paid verifications.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, lowering the burden on the description. The description adds 'requires authentication' and 'Free' which are behavioral traits not in the annotations, plus details about the return content (active and revoked API keys). This goes beyond the structured 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 two sentences, front-loaded with the primary purpose, and lists all returned fields efficiently. The second sentence adds a practical usage hint. Every sentence earns its place without redundancy or 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?
Although there is no output schema, the description explicitly lists all the return data (email, verification status, plan, credit balance, member-since, API keys). It also covers authentication and cost, making it fully self-contained for a read-only account summary. The sibling tools are different domains, so no confusion.
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 has zero parameters, so the schema provides full coverage (100%). The description doesn't need to explain parameters, and it doesn't—it focuses on what the tool returns. With no parameters, the baseline is 4, and the description doesn't detract from that.
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 'Returns your BizVerify account summary' and enumerates specific fields (email, verification status, plan, credit balance, member-since date, API keys). This is a specific verb+resource that distinguishes it from sibling tools like get_entity or get_config, which target other data.
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 for when to use the tool ('check your remaining credit balance before running paid verifications') and notes it is free and read-only. It doesn't explicitly mention alternatives or when not to use it, but the guidance is unambiguous for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns BizVerify's public configuration as readable text: active US and international jurisdictions, per-operation credit costs, the free-tier allowance, credit packages with pricing, feature flags, and documentation/legal links. Free and requires no authentication. Call this first to discover what jurisdictions are supported and what each operation costs before verifying.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds useful behavioral context: it returns 'readable text', lists the specific categories of information, and notes that it is free and unauthenticated. These details go beyond the annotations and set proper expectations without contradicting any structured data.
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 two sentences, each packed with specific, non-redundant information. It front-loads the core function and content list, then adds usage guidance. No filler or repetition; every word earns its place.
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 zero parameters, no output schema, and straightforward read-only behavior, the description fully covers what the agent needs: what the tool returns, that it is free, and when to call it. The explicit list of returned items substitutes for an output schema, making the tool's behavior predictable.
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 has zero parameters, so per the rubric the baseline is 4. The description adds no parameter details because none are needed. It sufficiently explains what the returned configuration includes, which is the relevant semantic info.
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's function with a specific verb ('Returns') and resource ('BizVerify's public configuration'). It enumerates the exact contents (jurisdictions, credit costs, free-tier allowance, packages, feature flags, links), making it distinct from siblings like list_jurisdictions. The 'Call this first' phrase anchors its role in the workflow.
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 explicitly says to call this first to discover supported jurisdictions and costs before verifying, which gives clear timing and context. It also notes it is free and requires no authentication. However, it does not explicitly contrast with alternatives like list_jurisdictions or mention when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a previously verified business entity from BizVerify's cache by its ID — returns name, jurisdiction, status, type, good-standing, formation date, registered agent, and the number of snapshots on record. Free and read-only; does NOT fetch a fresh live result (use verify_business with force_refresh for live data). Requires authentication. Pass an entity_id returned by a prior verify_business or search_entities call.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | Entity ID returned by a prior verify_business or search_entities result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable context: free, read-only, cache behavior, requires authentication, and enumerates the exact fields returned. No contradiction 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?
Three sentences, each earning its place: purpose and return fields, exclusion and alternative, then auth and input guidance. No wasted words and front-loaded with the core function.
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?
Despite the absence of an output schema, the description lists all returned fields, specifies prerequisites, limitations, authentication, and usage context. Complete for a simple read-only fetch 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?
The schema covers 100% of one parameter with a clear description. The description reinforces and adds context by explaining the source of the entity_id (prior verify_business or search_entities). This goes beyond the schema's basic definition.
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 begins with a specific verb and resource: 'Fetch a previously verified business entity from BizVerify's cache by its ID.' It clearly distinguishes from siblings by noting it returns cached data rather than live data, and lists the specific fields returned.
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 states when to use this tool vs. alternatives: 'does NOT fetch a fresh live result (use verify_business with force_refresh for live data).' Also provides input prerequisites by specifying that the entity_id must come from a prior verify_business or search_entities call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the chronological verification snapshots recorded for an entity — each with a timestamp, name, and status — newest first, with pagination. Costs 5 credits and requires authentication. Use it to see how a company's status or details have changed over time.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of history snapshots to return (1-100, default 10) | |
| offset | No | Number of snapshots to skip for pagination (default 0) | |
| entity_id | Yes | Entity ID to retrieve history for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, which covers the safety profile. The description adds valuable behavioral context beyond annotations: it costs 5 credits, requires authentication, returns results newest first, and supports pagination. This is exactly the kind of context (auth, cost, ordering) the rubric encourages.
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 two sentences, front-loaded with the primary purpose and key output details, followed by cost/auth and the intended use case. Every sentence contributes, and there is no redundant or filler content.
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?
Considering the absence of an output schema, the description discloses the return fields (timestamp, name, status), ordering, pagination, cost, auth, and intended use. It does not cover error cases or what happens if the entity does not exist, but for a read-only, annotated tool this is adequate and nearly complete.
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% (all three parameters have descriptions), so the baseline is 3. The description mentions pagination, which indirectly relates to limit/offset, but it does not add specific parameter-level detail beyond what the schema already provides. No need for compensation.
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 uses a specific verb ('Returns') and clearly identifies the resource ('chronological verification snapshots recorded for an entity'). It lists the fields (timestamp, name, status), ordering (newest first), and pagination, which distinguishes it from siblings like get_entity (current state) and search_entities.
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 explicitly states when to use the tool: 'Use it to see how a company's status or details have changed over time.' This provides clear context. It does not explicitly name alternatives or exclusions, but the sibling tool names imply that get_entity is for current state, giving implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every registered jurisdiction with its code, active/inactive status, and supported capabilities — search, entity lookup, quick verification, and deep verification. Free and requires no authentication. Use it to confirm a state or country is supported and which verification tiers it offers before calling verify_business or search_entities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds critical non-obvious behavior: it is free, requires no authentication, and returns a complete list without filtering. It also details the supported capabilities, providing context not available from annotations alone.
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 primary action, followed by a practical usage note. No wasted words; every clause delivers meaningful information.
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 simple list tool with no parameters and no output schema, the description is sufficiently complete. It specifies the exact content of the response (code, status, capabilities) and its purpose in the broader workflow, making the tool fully understandable.
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 has zero parameters, so the schema coverage is trivially 100%. The description reinforces the no-parameter nature by saying 'Lists every' and not mentioning any filters. Baseline for 0 params is 4, and the description adds no additional parameter meaning beyond that.
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 uses a specific verb ('Lists') and clearly identifies the resource ('every registered jurisdiction') while enumerating the exact attributes returned (code, status, capabilities). It also distinguishes itself from sibling tools by positioning this as the prerequisite for verify_business and search_entities.
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 states when to use the tool ('Use it to confirm a state or country is supported and which verification tiers it offers before calling...'), naming the two alternative tools it should precede. This gives clear context for when to invoke this tool vs. others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starts a credit purchase: creates a Stripe checkout session for the chosen package and returns a payment URL to present to the user. Does NOT charge immediately and does NOT add credits until the user completes payment — credits are then added automatically. Requires authentication. Packages: credits_100, credits_500, credits_2000, credits_10000 (see get_config for current prices).
| Name | Required | Description | Default |
|---|---|---|---|
| package_id | Yes | Credit package to purchase: credits_100, credits_500, credits_2000, or credits_10000 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explaining that the tool does NOT charge immediately, does NOT add credits until payment completion, and that credits are added automatically. It also notes the requirement for authentication. These details are critical for understanding the asynchronous, external behavior (Stripe) not fully conveyed by the openWorldHint.
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 two sentences, front-loaded with the core action and followed by important caveats and the package list. It is compact, well-ordered, and contains no filler, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, no output schema, and the absence of nested objects, the description covers the essential behavior: it creates a checkout session, returns a payment URL, explains the deferred charging/crediting, and states the authentication requirement. This is sufficiently complete for correct invocation.
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 input schema already fully documents package_id with an enum and a sentence listing the options (100% schema description coverage). The description adds the note to see get_config for current prices, which helps the agent select an appropriate package based on pricing, a useful semantic addition beyond the raw enum.
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 creates a Stripe checkout session for a credit package and returns a payment URL. It specifies the exact action ('creates'), the resource ('Stripe checkout session'), and the purpose ('start a credit purchase'), which distinguishes it from the sibling read/search 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?
The description indicates when to use it (to start a credit purchase) and directs the agent to see get_config for current prices, implying a prerequisite. It does not explicitly exclude non-purchase uses, but the sibling list contains no other purchasing tool, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover candidate businesses when the exact entity is UNKNOWN — a listing/discovery tool, NOT a verification tool. Use only when the user wants to browse or list multiple companies matching a partial or fuzzy name, or does not yet know which specific entity they mean. If the user can name one specific company they want to confirm or check, use verify_business instead (ask them for the name first if needed). Costs 2 credits per jurisdiction searched and requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (1-200, default 50) | |
| query | Yes | Business name search query | |
| offset | No | Number of results to skip for pagination (default 0) | |
| entity_type | No | Filter by entity type | |
| jurisdiction | No | Jurisdiction code or name (omit to search all active) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations exist (readOnlyHint=false, openWorldHint=true, etc.), so the bar is lower. The description adds valuable behavioral context beyond annotations by disclosing 'Costs 2 credits per jurisdiction searched and requires authentication.' This covers cost and auth needs. It does not contradict annotations, and while it doesn't detail other side effects, the provided annotations plus cost/auth disclosure are sufficient.
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 three sentences, front-loaded with purpose and differentiation, and every sentence adds value. It efficiently covers usage, alternative, and cost/auth without redundancy.
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 5 parameters and no output schema, the description covers the essential context: purpose, usage boundaries, cost, and authentication. It doesn't describe the return format in detail, but the phrase 'Discover candidate businesses' implies the output. It also doesn't mention pagination behavior, though limit/offset schema parameters cover that. Overall, it is sufficiently complete for the tool's complexity.
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 baseline is 3. The description adds meaningful context for parameters: it clarifies that query is 'partial or fuzzy name' and that jurisdiction affects cost ('per jurisdiction searched'), which goes beyond the schema's generic parameter descriptions. This enriches parameter understanding.
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 'discovers candidate businesses when the exact entity is UNKNOWN' and explicitly labels it as a 'listing/discovery tool, NOT a verification tool.' This provides a specific verb (discover/search), resource (businesses), and scope (when exact entity is unknown), distinguishing it from sibling tools like verify_business.
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 explicit when-to-use guidance: 'Use only when the user wants to browse or list multiple companies matching a partial or fuzzy name, or does not yet know which specific entity they mean.' It also names the alternative: 'If the user can name one specific company they want to confirm or check, use verify_business instead (ask them for the name first if needed).' This is a clear when/when-not and alternative specification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm a specific, named business in one jurisdiction — the PRIMARY tool whenever the user wants to verify, check, confirm, or look up a company's existence, status, good standing, or details (e.g. "verify Acme LLC in Delaware", "is Acme registered in FL?", "I need to verify a company in Delaware"). If the user has verification intent but has not given the exact company name, ASK them for the name and use THIS tool — do NOT fall back to search_entities. Two tiers: quick (1 credit) returns existence + status + good-standing. Deep (15 credits, or 25 with force_refresh) adds entity type, formation date, registered agent, officers, principal address, and filing history. Deep is available in a subset of jurisdictions; requesting deep where unavailable returns a quick result with a reason. Requires authentication. A completed verification deducts credits whether or not the business is found — a confirmed no-match is a result. Calls that cannot produce an answer (source unavailable or timed out) are refunded.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Verification tier: quick (1 credit, always available) or deep (15 credits, availability varies by jurisdiction) | quick |
| entity_name | Yes | Business entity name to verify | |
| entity_type | No | Optional entity type filter to narrow results | |
| webhook_url | No | URL to receive async results. Must be a publicly reachable http(s) URL. | |
| jurisdiction | Yes | Jurisdiction code or name (e.g., "us-fl", "Florida", "FL") | |
| force_refresh | No | Return the most current result instead of a previously stored one. Applies to the deep tier only (adds 10 credits); ignored on quick. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly discloses side effects and behaviors beyond annotations: credit deductions (1/15/25 credits), refund policy for unanswered calls, authentication requirement, and the deep-tier fallback to a quick result when unavailable. It also clarifies that a no-match still deducts credits. These are not conveyed by the annotations (readOnlyHint=false, openWorldHint=true, etc.) and add critical operational detail.
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. It opens with the core purpose, then moves through usage constraints, tier options, limitations, auth, and credit policy. There is no fluff; the paragraph flows logically and front-loads the most critical information. Given the complexity of the tool (credits, tiers, refunds), the length is appropriate.
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 fully covers the tool's ground: purpose, when to use, tier details, jurisdiction subset, auth, and credit/refund policies. It even describes return content for quick ('existence + status + good standing') and deep ('entity type, formation date...') despite the lack of an output schema. The guidance against search_entities positions it well among siblings.
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 meaningful semantics to key ones: it explains 'level' tiers with credit costs, mentions 'force_refresh' as adding 10 credits (deep only), and implies jurisdiction handling via 'subset of jurisdictions'. It also relates entity_name to the need to ask for a name. Some parameters (webhook_url, entity_type) rely solely on schema, but overall the description significantly augments parameter understanding.
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+resource: 'Confirm a specific, named business in one jurisdiction' and explicitly lists use cases ('verify, check, confirm, or look up a company's existence, status, good standing'). It clearly distinguishes this tool from search_entities, stating 'do NOT fall back to search_entities', and positions it as 'the PRIMARY tool' for verification intent.
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 explicit when-to-use guidance: 'the PRIMARY tool whenever the user wants to verify...' and instructs to ask for a company name if missing. It also names the alternative tool to avoid: 'do NOT fall back to search_entities'. It further specifies tier availability ('Deep is available in a subset of jurisdictions') and authentication requirements, leaving no ambiguity about usage context.
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.0check_job_statusget_accountget_configget_entityget_entity_historylist_jurisdictionspurchase_creditssearch_entitiesverify_businessScored across 9 tools
Each tool has a clearly distinct purpose: configuration, jurisdiction listing, account info, exact verification, fuzzy search, async job polling, cached entity retrieval, entity history, and credit purchasing. No overlapping functionality.
All tool names follow a consistent verb_noun pattern (get_config, list_jurisdictions, verify_business, etc.) using lowercase with underscores. Verbs are descriptive and uniform.
With 9 tools, the server is well-scoped for the business verification domain. Each tool serves a necessary function without bloat, covering configuration, discovery, verification, and account management.
The tool set provides full lifecycle coverage: discover jurisdictions, find entities, verify businesses (sync/async), cache retrieval, history, account info, and credit purchasing. No obvious gaps like missing update/delete operations, as the domain is query-focused.
US public-records intelligence for AI agents — companies, SEC, courts, spending, licenses.
European business verification for AI agents: registry, VAT, sanctions, IBAN. Pay-per-call x402.
CompanyLens is a remote MCP server giving AI agents instant access to official company registry data across 19 jurisdictions in Europe, the Americas, and Asia-Pacific. Eighteen read-only tools let you search companies and people, look up officers and beneficial owners, map corporate networks through shared directors, screen names against the UK disqualified directors register, find every company at a registered address, and pull filing history — all from a single connector. Visit our website: https://companylens.io
Confirm a US business is real and find who controls it. 32.6M official registry records.
