Deterministic contractor license verification, surety bond & workers' comp insurance auditing, OSHA safety citations, and SAM.gov debarment checks for AI agents across CA, FL, TX, NY, MA, IL, AZ + Federal databases.
Scored across 6 tools
Most tools have clearly distinct purposes: verify_license targets license verification, audit_osha_safety targets OSHA history, check_federal_debarment targets federal sanctions, search_contractors targets discovery, and get_registry_status targets system health. However, check_compliance_risk overlaps with verify_license because it returns the full underlying verification result and shares similar arguments, which could confuse an agent about when to use the composite risk assessment versus the atomic license check.
All tool names follow a consistent snake_case verb_noun pattern: audit_osha_safety, check_compliance_risk, check_federal_debarment, get_registry_status, search_contractors, verify_license. The verbs are clear and the structure is predictable throughout.
Six tools is well-scoped for a contractor licensing and compliance server. Each tool covers a distinct capability (search, license verification, compliance risk, OSHA audit, federal debarment, system health) without redundancy or trivial padding.
The surface covers the core domain well: discovery, license verification, compliance risk assessment, OSHA safety, federal debarment, and system health. Minor gaps exist, such as no standalone workers' comp or surety bond verification tool and no batch operations, but these can be partially addressed through check_compliance_risk parameters.
Audit contractor worksite safety history against the OSHA inspection and enforcement database.
Evaluates willful safety violations, repeat fall protection citations, and cumulative penalties.
Args:
entity_name: Official business or entity name to evaluate.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only lookup of a public enforcement database, but does not state permissions, data recency, rate limits, or whether the audit is a point-in-time snapshot. It gives the evaluated criteria but little operational behavior.
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 purpose sentences front-load the core function and the evaluation criteria, followed by a minimal Args block that earns its place given 0% schema coverage. No wasted filler, though the Args formatting is boilerplate.
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 single-parameter lookup tool with an output schema (so return values need not be described) and no annotations, the description covers purpose and the sole parameter adequately. Minor gaps remain around data source recency and matching semantics.
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 0%, so the description must compensate, and it does: the Args block clarifies entity_name is the 'Official business or entity name to evaluate,' disambiguating from a person's name or DBA. It stops short of specifying exact-match requirements or alias handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Audit) and resource (contractor worksite safety history against the OSHA inspection and enforcement database), and enumerates the signals it evaluates (willful violations, repeat fall protection citations, cumulative penalties). It is clearly distinct from siblings like check_federal_debarment or verify_license, though it never names them explicitly, so it stops short of a 5.
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 implies when the tool applies (auditing a contractor's OSHA safety record) but gives no explicit when-to-use/when-not guidance and never points to alternatives such as check_compliance_risk. Usage must be inferred from the stated purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform an automated compliance and liability risk assessment for autonomous onboarding, hiring, or payments.
Args:
state: Two-letter US state code ('CA', 'FL', or 'TX'). Required.
entity_name: Company name or DBA to assess.
license_number: State license number to assess.
trade: Trade category: 'roofing', 'hvac', 'electrical', 'plumbing', 'general_contractor', or 'any'.
require_workers_comp: If true, fails compliance if no verified workers' comp policy is active on file.
require_surety_bond: If true, fails compliance if contractor bond is inactive or missing.
max_disciplinary_actions: Maximum allowed board citations or disciplinary orders (default 0).
min_confidence_score: Minimum entity name match confidence threshold (0.0 to 1.0, default 0.85).
Returns:
JSON with 'can_hire' boolean, 'risk_level' ('LOW', 'MEDIUM', 'HIGH', 'CRITICAL'),
'risk_score' (0.0 to 100.0), specific 'flags', and the full underlying verification result.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| trade | No | any | |
| entity_name | No | ||
| license_number | No | ||
| require_surety_bond | No | ||
| min_confidence_score | No | ||
| require_workers_comp | No | ||
| max_disciplinary_actions | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does well: it discloses the exact failure conditions ('fails compliance if no verified workers' comp policy is active on file', 'fails compliance if contractor bond is inactive or missing'), the default thresholds, and what the output enumeration looks like. It omits permission/auth or rate-limit behavior, keeping it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose sentence is front-loaded, then Args and Returns are cleanly delineated with one line per parameter. No sentence is filler; each parameter line adds a distinct constraint or default.
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 an 8-parameter tool with no annotations, zero schema coverage, and a rich return payload, the description supplies all needed calling context: what each flag does, required vs default, and the shape of the risk verdict. Nothing essential for a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate entirely, and it does: it enumerates the state values ('CA', 'FL', or 'TX'), the six trade categories, and the precise effect of each boolean/numeric flag (what fails, and the default). This is far more meaning than the bare schema titles provide.
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: 'automated compliance and liability risk assessment for autonomous onboarding, hiring, or payments.' This is a composite risk-check distinct from the sibling single-purpose tools (verify_license, check_federal_debarment, audit_osha_safety), so an agent can tell what niche it fills.
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?
It states the use context ('autonomous onboarding, hiring, or payments'), which tells the agent when this tool applies. However, it never says when NOT to use it or points to the sibling checks (verify_license, check_federal_debarment) as alternatives, so routing guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a contractor is actively debarred or suspended on the federal SAM.gov Excluded Parties List System (EPLS).
Crucial for public contracts, infrastructure, and enterprise B2B compliance.
Args:
entity_name: Official business or entity name to evaluate against federal sanctions.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the data source (federal EPLS), which is useful, but says nothing about authentication requirements, rate limits, name-matching behavior, or what a hit/miss means for the caller.
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?
Front-loads the core action and source in the first sentence, then adds a brief value statement and one arg line. No filler, though the value statement is somewhat promotional rather than operational.
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?
An output schema exists so return values need not be explained, and the single parameter is adequately described. However, for a name-based sanctions lookup, the description omits disambiguation caveats (legal-name matching, false positives) that an agent needs to interpret results 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 coverage is 0% and the only parameter is documented solely as "Entity Name" in the schema. The description compensates by specifying it should be the "official business or entity name" evaluated against federal sanctions, which adds real meaning over the bare schema title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (check) and resource (federal debarment/suspension status) and names the authoritative source, SAM.gov EPLS. It is clearly distinguishable from siblings like verify_license or audit_osha_safety, though it does not explicitly contrast itself with them.
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?
"Crucial for public contracts, infrastructure, and enterprise B2B compliance" implies the usage context but gives no explicit when-to-use/when-not guidance and names no alternative sibling tool for related compliance checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the system health, cache performance statistics, and multi-state registry connectivity.
Returns:
JSON object with cache hit/miss counts, total records cached, and connector status for CA, FL, TX, NY, MA, IL, AZ.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the return contents (cache hit/miss counts, total records cached, per-state connector status), which implies a read-only diagnostic. However, it does not state whether it requires authentication, whether it is side-effect-free, or what the connector statuses mean (healthy/degraded), leaving behavioral gaps.
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 purpose is front-loaded in the first sentence, followed by a clearly delimited 'Returns' block. No filler or redundancy; the two-part structure (what it does / what it returns) is efficient. Slightly over-specified given an output schema exists, but not wasteful.
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 no-argument diagnostic with an output schema, the description supplies enough to call it correctly and understand the result. The absence of usage guidance (when to run it) and permission expectations are the only material gaps, and both are minor for a status probe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to clarify. Baseline for a parameterless tool is 4, and there is no schema content the description duplicates or contradicts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Check') with concrete resources: system health, cache performance statistics, and multi-state registry connectivity. The purpose is unambiguous and clearly distinct from the sibling tools, all of which are contractor/compliance lookups rather than diagnostics. It stops short of explicitly naming siblings as alternatives, but there is no overlap to disambiguate.
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 says what the tool checks and returns but gives no when-to-use guidance, no prerequisites, and no alternatives. An agent can infer it is a diagnostic/health probe from the name, but nothing explicitly routes it against the other compliance tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover active, verified trade contractors in California, Florida, or Texas by trade classification and location.
Args:
state: Two-letter US state code ('CA', 'FL', or 'TX'). Required.
trade: Trade category ('roofing', 'hvac', 'electrical', 'plumbing', 'general_contractor'). Required.
city: Optional city to filter contractors by location.
limit: Maximum number of contractors to return (1 to 50, default 10).
Returns:
JSON list of verified contractors with active licenses, phone numbers, and addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| limit | No | ||
| state | Yes | ||
| trade | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses useful behavior: results are limited to CA/FL/TX, only active/verified licensed contractors are returned, and each record includes phone and address. However, it says nothing about authentication needs, rate limits, pagination beyond 'limit', sort order, or what happens when no results match.
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?
Front-loads the one-line purpose before the Args/Returns blocks, and every listed item carries information an agent needs. The Args/Returns formatting is slightly verbose against a schema that already carries the structure, but nothing is wasted.
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 4-parameter search tool with an output schema, the description covers the domain restrictions, required vs optional params, and value constraints. Return-value detail is partly redundant given the output schema, and edge cases (empty result set, pagination) are unaddressed, but nothing critical to calling it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it largely does: it marks state and trade as required, enumerates the valid state codes and trade categories, documents city as an optional filter, and gives the limit range (1-50) and default (10). Minor gaps remain, e.g. case sensitivity or matching semantics for city, so not a full 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Discover/search) plus resource (active, verified trade contractors), scoped to three named states and a non-empty domain of trades. This cleanly separates it from verification-oriented siblings like verify_license and check_federal_debarment, which check a single entity rather than discover a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the framing ('Discover active, verified trade contractors'), but there is no explicit when-to-use or when-not-to-use guidance and no routing to alternatives such as verify_license for confirming a single contractor's status. Adequate but leaves the agent to infer the boundary with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an entity's trade contractor license against the official state licensing board (CSLB, DBPR, or TDLR).
Args:
state: Two-letter US state code ('CA', 'FL', or 'TX'). Required.
entity_name: The company name, DBA, or contractor name to verify (e.g. 'Apex Roofing LLC').
license_number: The official state license or certificate ID (e.g. '1058291', 'CCC1330999', 'TACLA29188C').
trade: Trade category: 'roofing', 'hvac', 'electrical', 'plumbing', 'general_contractor', or 'any'. Default is 'any'.
city: Optional city to filter geographic disambiguation.
Returns:
Deterministic, machine-actionable JSON containing verification status, canonical name,
active standing, disciplinary action count, workers' compensation status, bond status, and confidence score.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| state | Yes | ||
| trade | No | any | |
| entity_name | No | ||
| license_number | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that only CA/FL/TX are supported and that results are 'deterministic, machine-actionable JSON' with a confidence score, but omits auth requirements, failure/not-found behavior, rate limits, and what happens when entity_name and license_number are both absent.
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?
Front-loaded purpose followed by clearly labeled Args and Returns blocks with zero fluff, so it is easy to scan. The Returns block is modestly redundant given an output schema exists, costing a point.
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 formal output schema present, the description needn't explain return values, and it fully covers the parameter space for a 5-param tool. The remaining gap is the absence of any routing guidance against its five 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?
Schema description coverage is 0%, so the description must compensate, and it does: it documents all five parameters, enumerates valid states and trade categories, supplies concrete example IDs and company names, and marks city as optional for disambiguation. This adds real meaning beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Verify an entity's trade contractor license') and names the authoritative sources (CSLB, DBPR, TDLR). It is clear what the tool does but never distinguishes itself from siblings like search_contractors, which an agent could plausibly confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: requiring 'state' and supporting 'city' for geographic disambiguation hints at the lookup flow, but there is no explicit when-to-use versus search_contractors or check_compliance_risk, and no exclusions. The only supported states (CA, FL, TX) are buried in the parameter doc.
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.
audit_osha_safetycheck_compliance_riskcheck_federal_debarmentget_registry_statussearch_contractorsverify_license
Add one secure layer between your agents and this server.