Creates a Stripe checkout session to purchase additional credits for the BizVerify account.
Click on "Install 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 indicate safe, idempotent, open-world. Description adds that it's free, requires auth, and explains return states, adding value beyond 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?
Two sentences, no waste. Purpose first, then details. Every sentence 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?
Single parameter fully covered, annotations present, description explains return behavior. No gaps for agent to infer.
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%. Description adds context by specifying job_id comes from verify_business async response, enhancing meaning.
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?
Specific verb 'poll' with resource 'long-running verification job' and clear differentiator from siblings like verify_business. States it returns result, failure, or 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?
Explicitly states when to use (after verify_business returns job_id) and how to poll. No explicit when-not, but context is sufficient.
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 declare readOnlyHint=true and idempotentHint=true. The description adds that the tool is 'Free and read-only' and 'requires authentication,' which provides some additional context beyond the annotations. However, it does not elaborate on other behavioral aspects like rate limits or data freshness.
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 long, efficient, and front-loaded. It lists return fields first, then adds context about cost and authentication, and ends with a practical usage tip. No wasted words.
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 lacking an output schema, the description comprehensively lists all return fields (email, verification status, plan, credit balance, member-since date, API keys). It also covers usage context and auth requirements, making it fully informative for an agent.
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 no parameters, so the description cannot add parameter-specific details. According to the rubric, zero parameters yields a baseline of 4. The description does not need to explain parameter semantics.
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 explicitly states that the tool returns 'BizVerify account summary' and enumerates the specific fields (email, verification status, plan, credit balance, member-since date, API keys). This distinguishes it from sibling tools like verify_business or get_config, which serve different purposes.
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 advises using the tool to 'check your remaining credit balance before running paid verifications,' providing clear context for when to invoke it. It also notes that it is 'Free and read-only,' implicitly guiding against using it for paid or write operations.
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 indicate idempotent and readOnly hints. The description adds that the operation is free and requires no authentication, providing useful context beyond annotations. No behavioral contradictions.
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 efficiently convey purpose, contents, prerequisites, and usage advice. No redundant information; every part adds value.
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 no output schema, the description comprehensively explains what the tool returns, including specific items like jurisdictions, costs, credits, and links. It also covers ordering (call first), prerequisites (none), and integrates well with the sibling tool context.
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?
No parameters exist, and schema coverage is 100%. The description does not need to elaborate on inputs; it correctly focuses on the output contents and usage context.
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?
Clearly states the tool returns BizVerify's public configuration as readable text, listing specific contents (jurisdictions, costs, credits, etc.). Distinguishes from siblings like list_jurisdictions (which returns only jurisdictions) and verify_business (which performs verification).
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 advises to call this tool first to discover supported jurisdictions and operation costs before verifying, and notes it is free and requires no authentication. This provides clear when-to-use guidance and sets expectations for subsequent operations.
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. Description adds context: free, no live fetch, requires auth, and lists returned fields. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences: first covers purpose and returns, second covers usage constraints and alternatives. No wasted words.
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 tool with one param and no output schema, the description covers input source, cache behavior, required fields, and authentication. Differentiates from 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?
Only one parameter, 100% schema coverage. Description adds value by explaining the source of entity_id (prior verify_business or search_entities call), beyond the schema description.
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 it fetches a cached entity by ID, distinguishing it from verify_business (live) and search_entities (ID retrieval).
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 (with prior entity_id) and when not to (for live data, use verify_business with force_refresh). Also mentions it's free and read-only.
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. Description adds valuable behavioral info: costs 5 credits, requires authentication, and returns newest first. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states return value and ordering, second adds cost, auth, and usage advice. Extremely concise and front-loaded with key 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?
No output schema, but description specifies snapshot fields (timestamp, name, status). Could be slightly more explicit about structure, but is sufficient for agent understanding.
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 descriptions. Description adds meaning by stating 'newest first' ordering, which is not in schema. Does not detail each parameter but provides useful context.
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?
Clearly states the tool returns chronological verification snapshots with timestamp, name, status, newest first, with pagination. Explicitly differentiates from siblings by focusing on history vs. current state.
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?
Tells when to use it: 'to see how a company's status or details have changed over time.' Does not explicitly mention when not to use, but the sibling tools provide context for alternatives.
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?
Annotations already declare readOnlyHint and idempotentHint, so safety is clear. Description adds valuable context: 'Free and requires no authentication', which annotations don't cover. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First sentence front-loads the action and output details. Second sentence gives usage guidance. No fluff.
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 no output schema, the description fully explains what is returned (code, status, capabilities). This is sufficient for a simple listing 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?
No parameters exist, so the description correctly omits parameter details. Schema coverage is 100% (trivial). Baseline 4 is appropriate for a zero-parameter tool.
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 lists jurisdictions with specific attributes (code, status, capabilities). It distinguishes itself from sibling tools like verify_business and search_entities by describing what it offers.
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 tells when to use: before calling verify_business or search_entities, to confirm support and verification tiers. This provides clear context and alternatives.
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?
Description adds significant behavioral context beyond annotations: the async nature (not immediate charge/credit), the Stripe checkout session creation, automatic credit addition after payment, and authentication requirement. 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?
Two sentences with no filler. Front-loaded with the core purpose, then clarifies key behaviors. Every sentence is necessary and informative.
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 tool with one parameter and no output schema, the description covers authentication, workflow stages, and price reference. Annotations provide safety profile. Complete for selection and 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?
Schema coverage is 100% with a well-documented enum parameter. The description lists the package options and references get_config for prices, which adds minor value. Baseline 3 is appropriate as the schema already fully describes the parameter.
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 action: 'Starts a credit purchase: creates a Stripe checkout session and returns a payment URL.' It specifies the verb (starts), the resource (credit purchase), and the output (payment URL). It distinguishes from siblings by being the only purchase tool among retrieval/verification 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 explains the workflow: does not charge immediately, credits added after payment, requires authentication. It does not explicitly contrast with alternative tools, but the context of purchasing credits vs. other retrieval tools 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?
Beyond annotations (readOnlyHint=false, openWorldHint=true), description adds credit cost per jurisdiction and authentication needs. It clarifies the tool is discovery-oriented, which aligns with openWorldHint but doesn't contradict readOnlyHint (cost is a side effect).
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 serving a distinct purpose: purpose/sibling differentiation, usage condition, cost/auth. No fluff.
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?
While usage context is strong, the absence of output schema means description should ideally hint at return value structure (e.g., list of entities with key fields). It doesn't, leaving a completeness gap.
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?
Input schema already describes all 5 parameters (100% coverage). Description does not add parameter-specific meaning beyond what schema provides. Baseline score of 3 is appropriate.
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, framing it as a listing/discovery tool, not a verification tool. It distinguishes from sibling verify_business by explicitly naming it.
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?
Provides explicit when-to-use (browse/list, partial name) and when-not-to-use (specific company verification) with alternative sibling tool. Also mentions cost and authentication requirements.
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?
Discloses important behavioral traits beyond annotations: requires authentication, credit deduction even if business not found (no-match is a result), refunds for failed calls, and available tiers. No contradiction with annotations (readOnlyHint=false, etc.).
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 front-loaded with the primary purpose and usage guidance. It is thorough but slightly verbose; some details like deep availability and credits could be condensed. Still well-structured and each sentence adds value.
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 tool complexity (6 parameters, no output schema), the description covers all essential aspects: behavior, tiers, credits, refunds, authentication, and return information for quick vs deep. This provides sufficient context for an AI agent to use the tool correctly.
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 baseline 3. The description adds context about the 'level' parameter's credit costs and suboptions (force_refresh with deep), but doesn't significantly expand on what the schema already provides for other parameters.
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 purpose: '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.' It also distinguishes from the sibling tool search_entities by explicitly stating not to fall back to it.
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?
Provides explicit guidance: '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.' Also explains the two tiers (quick vs deep) and when deep is available, giving clear context for tool selection.
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. Dates show when Glama detected each change.
v0.1.0check_job_statusget_accountget_configget_entityget_entity_historylist_jurisdictionspurchase_creditssearch_entitiesverify_businessEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BizVerify/bizverify-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
