The license-verify-mcp server lets you verify contractor licenses and list supported jurisdictions.
Tools available:
verify_license — Verify a contractor's license status (active, expired, suspended, revoked, or unknown), bond, and insurance for a given jurisdiction. Requires at least a license number or business name.
Search by license number — exact, case-insensitive match (preferred for unambiguous results)
Search by business name — partial, case-insensitive match; returns up to 10 results if multiple contractors match
Bond details — surety/bonding company, bond number, amount, effective and expiration dates
Insurance details — carrier, policy number, coverage amount, agency, and policy dates
Full license metadata — license type, effective/expiration dates, and raw source record
list_supported_jurisdictions — Returns all supported states, their data sources, and availability status.
Supported jurisdictions:
Washington (WA) — production-ready, sourced from WA L&I open data (Socrata JSON); includes real bond and insurance data
California (CA) — beta, sourced from CSLB HTML pages (may intermittently return SESSION_ERROR)
Failures, source errors, and not-found results are never charged.
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., "@license-verify-mcp verify WA license ECOSTSC758NN"
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.
The only MCP-native license check that returns official SURETY BOND + INSURANCE from state data — not just active/inactive status. Pay-per-success: $0.03 full result, $0.01 status-only, FREE on a miss. WA live (official L&I), CA beta (CSLB).
Tools: verify_license, list_supported_jurisdictions.
// Call
{ "tool": "verify_license", "jurisdiction": "WA", "license_number": "ECOSTSC758NN" }// Response (abridged)
{
"found": true,
"result": {
"status": "active",
"bonded": { "is_bonded": true, "details": "Surety: NORTH RIVER INSURANCE COMPANY THE; Amount: $30,000" },
"insured": { "has_insurance": true, "details": "Carrier: State National Ins Co Inc; Coverage: $1,000,000" }
}
}Result | Price |
Full (status + bond + insurance) | $0.03 |
Status-only (no bond/insurance match, or | $0.01 |
Miss ( | FREE |
Related MCP server: HopGraph MCP
State | Status | Source | Bond + Insurance |
WA | ✅ Live | WA L&I open data (data.wa.gov) | ✅ Real data (bzff-4fmt + ciwg-agsx datasets) |
CA | ⚠️ Beta | CSLB HTML (cslb.ca.gov) | ✅ Parsed when CSLB is up |
Washington is the reliable, production-ready jurisdiction. Official WA L&I open data is served via Socrata JSON — no scraping, no rate limits, bond and insurance data included from dedicated datasets.
California is beta. CSLB does not publish an open API; the provider fetches the HTML detail page directly. CSLB rate-limits or 503s automated requests intermittently. When unavailable, verify_license returns a clean SESSION_ERROR — you are never charged on source failures. Do not rely on CA for production workflows until a stable server-side CSLB run is confirmed.
Agentic-payments eligible — pay-per-event pricing + limited permissions + no Standby mode.
Event | Price |
| $0.03 — full result (status + bond + insurance) |
| $0.01 — status found, no bond/insurance match (or |
Charged only on found: true. Validation errors, not-found results, and source failures are not charged.
{
"jurisdiction": "WA",
"license_number": "ECOSTSC758NN"
}Field | Type | Required | Notes |
|
| ✅ | WA = live; CA = beta |
| string | one of ↓ | WA: alphanumeric. CA: numeric, ≤8 digits |
| string | one of ↑ | WA only. Partial match, may return |
{
"found": true,
"jurisdiction": "WA",
"query": { "license_number": "ECOSTSC758NN" },
"result": {
"license_number": "ECOSTSC758NN",
"business_name": "!ECO STAR C G CONSTRUCTION LLC",
"status": "active",
"license_type": "CONSTRUCTION CONTRACTOR",
"bonded": {
"is_bonded": true,
"details": "Surety: NORTH RIVER INSURANCE COMPANY THE; Bond #: 46CF842686; Amount: $30,000; Effective: 2025-08-05; Expires: Until Canceled"
},
"insured": {
"has_insurance": true,
"details": "Carrier: State National Ins Co Inc; Policy: NXT9PTHTLT-01-GL; Coverage: $1,000,000; Agency: Next Insurance Inc; Effective: 2026-06-12; Expires: 2027-06-12"
},
"effective_date": "2025-08-15",
"expiration_date": "2027-08-15"
},
"source_url": "https://data.wa.gov/resource/m8qx-ubtq",
"retrieved_at": "2026-06-26T01:34:37.598Z",
"raw": { ... }
}status is always one of: active | expired | suspended | revoked | unknown.
On failure: { "found": false, "error": "SESSION_ERROR|NETWORK_ERROR|...", "message": "..." } — never a crash, never a charge.
npm install
npm run build
echo '{"jurisdiction":"WA","license_number":"ECOSTSC758NN"}' \
> storage/key_value_stores/default/INPUT.json
npx apify runFor use with Claude Desktop, Smithery, or any MCP-compatible agent.
verify_license — verify a contractor's license status.
jurisdiction (required): "WA" or "CA"
license_number and/or business_name (at least one required)
list_supported_jurisdictions — list all states with their status and data source.
{
"mcpServers": {
"license-verify": {
"command": "node",
"args": ["/absolute/path/to/license-verify-mcp/dist/index.js"]
}
}
}npm install && npm run build
npm run start:mcp # stdio MCP server
npm run smoke # hit real WA + CA endpoints, must be 8/8 PASSCreate src/providers/<CODE>.ts implementing the Provider interface ({ info, verify() })
Register it in src/providers/index.ts
No other changes needed in server or Actor.
MIT
List all US states (jurisdictions) supported by this contractor license verification server, with their data source and availability status.
Call this tool when:
You need to check whether a specific state is supported before calling verify_license
You want to display available options to the user
You need the authoritative data source URL for a jurisdiction
Returns an array of jurisdictions with code, full name, source, and status (live or coming_soon).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns an array with fields (code, full name, source, status) and mentions 'live or coming_soon' status, which gives clear behavioral insight. There is no contradiction.
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 concise, using a single line for purpose followed by three bullet points for usage guidelines and one sentence for return value. Every part is essential and front-loaded.
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 adequately describes the return structure. With no inputs, it fully covers behavioral expectations. The tool is simple, and the description is 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?
Input schema has zero parameters, and schema coverage is trivially 100%. The description does not need to add parameter semantics, and it correctly omits any. Baseline for 0 parameters is 4.
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 the tool lists supported US states with data source and availability. It uses a specific verb ('list') and resource ('supported jurisdictions'), and distinguishes from the sibling tool 'verify_license' by implying this tool is for checking support before calling the other.
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 clearly states when to call the tool: to check state support, display options, or get data source URL. It provides explicit context but does not include when-not-to-use or alternatives, though the use cases are well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a contractor's current license or registration status before awarding work, signing a contract, or performing due diligence.
Call this tool when you need to:
Confirm a contractor is currently licensed and in good standing
Check whether a license is active, expired, suspended, or revoked
Look up a contractor by license/registration number (preferred — exact match) or by business name (partial match, may return multiple)
Retrieve license type, effective and expiration dates from official government records
Currently supports: WA (Washington State) via WA L&I open data (includes real bond + insurance data); CA (California) via CSLB Check-A-License. Call list_supported_jurisdictions first if unsure whether a state is supported.
Returns structured JSON with found status, normalized status enum (active|expired|suspended|revoked|unknown), license type, dates, bond/insurance notes, and the raw source record. If business_name matches multiple contractors, a "matches" array (up to 10) is returned instead of a single result.
At least one of license_number or business_name must be provided.
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | Yes | Two-letter US state code. Supported: 'WA' (Washington, via WA L&I open data), 'CA' (California, via CSLB). Call list_supported_jurisdictions to see all options. | |
| business_name | No | Business name or partial business name to search for. Case-insensitive partial match. May return multiple results if ambiguous — check the 'matches' array in that case. | |
| license_number | No | Contractor license or registration number to look up (e.g. 'ECOSTSC758NN'). Case-insensitive exact match. Preferred over business_name for unambiguous results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It states the tool is read-only, returns structured JSON with status enum, details on bond/insurance, and explains the matches array for ambiguous business names. This is comprehensive.
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 well-structured with bullet points (hyphens in text), front-loaded with the main purpose, and every sentence adds unique value. It is concise but covers all necessary aspects 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 no output schema, the description adequately explains return values (structured JSON with status, dates, bond info, raw source, and matches array). It covers jurisdiction support and input requirements. Minor deduction for not detailing every possible field, but sufficient for agent use.
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 value beyond schema: it explains preference for license_number, case-insensitive partial matching for business_name, and mentions that business_name may return multiple results. This extra guidance justifies a 4.
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: verifying a contractor's license/registration status before awarding work. It specifies the verb 'verify', the resource 'license/registration', and includes context about when to use it. It also distinguishes from the sibling tool list_supported_jurisdictions.
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 explicit when-to-use scenarios (confirm licensing, check status, look up by number/name) and when-not-to (calling list_supported_jurisdictions first). It also clarifies behaviors like partial vs exact matching and multiple matches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: one lists supported jurisdictions, the other verifies a contractor's license. No overlap in functionality, making selection unambiguous.
Both tools follow a consistent verb_noun pattern: list_supported_jurisdictions and verify_license. The naming is clear and predictable.
With only 2 tools, the server feels minimal. While the scope is narrow, a typical license verification server might include additional tools like get_license_details or search_business_by_name.
The tool set covers the core workflow: listing available jurisdictions and verifying a license. Minor gaps exist, such as no tool to retrieve a specific jurisdiction's details or support for other license types.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Verify contractor licenses: 50 states + DC + 8 cities — status, expiration, disciplinary history.
Search licensed US contractors by trade or location, fetch profiles and reviews, and submit leads.
Free contractor-license checks from official state records; a no-match never proves unlicensed.
Real-time U.S. medical license verification across all 50 states + DC.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lmaniraruta/license-verify-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
