Certificate of insurance tools: build subcontractor insurance requirements, check an ACORD 25.
Scored across 4 tools
Each tool targets a distinct action: building requirements, checking a certificate, searching guides, and listing presets. build_insurance_requirements and list_requirement_presets both concern requirements but are clearly separated as custom-generation vs. ready-made lookup.
All four tools follow a consistent verb_noun snake_case pattern (build_, check_, find_, list_). The noun portions vary naturally by domain (insurance_requirements, certificate, coi_guides, requirement_presets) without breaking the pattern.
Four tools is slightly lean but each earns its place by covering a step in the COI workflow. It is a focused, well-scoped set rather than an artificially thin one.
The core lifecycle is covered: generate requirements, list presets, check a certificate, and find explanatory guides. Minor gaps exist around persistence/tracking of certificates over time (referenced in the guides) but core agent workflows are workable.
Recommends the insurance a general contractor should require of a subcontractor, or a property manager or HOA of a vendor: general liability, auto, umbrella and workers' comp limits, additional insured, waiver of subrogation and primary/non-contributory wording, scaled to the trade's risk and the contract size. Returns the reasoning for each limit, contract-ready exhibit text, and a requirements object that check_certificate accepts.
| Name | Required | Description | Default |
|---|---|---|---|
| trade | Yes | The vendor's trade, and the contexts it is offered in: "general" = General / multi-trade (gc); "carpentry" = Carpentry / framing (gc); "concrete" = Concrete / masonry (gc); "drywall" = Drywall / plaster (gc); "painting" = Painting / finishes (gc/property); "electrical" = Electrical (gc/property); "mechanical" = Plumbing / HVAC (gc/property); "glazing" = Glazing / curtain wall (gc); "roofing" = Roofing (gc/property); "demolition" = Demolition (gc); "steel" = Structural steel / crane work (gc); "excavation" = Excavation / earthwork (gc); "scaffolding" = Scaffolding / shoring (gc); "abatement" = Asbestos / lead abatement (gc); "designbuild" = Design-build / engineering (gc); "landscaping" = Landscaping / grounds (property/gc); "janitorial" = Janitorial / cleaning (property); "pool" = Pool maintenance (property); "pest" = Pest control (property); "snow" = Snow & ice removal (property); "tree" = Tree removal / arborist (property); "elevator" = Elevator maintenance (property); "security" = Security services (property); "pm" = Property management services (property). | |
| context | Yes | "gc" = a contractor hiring a subcontractor; "property" = a property manager or HOA hiring a service vendor. | |
| overrides | No | Optional dollar limits that replace the recommended ones, for lines that are already required. | |
| contractSize | Yes | Contract value band. For "gc": under-50k, 50k-250k, 250k-1m, over-1m. For "property": under-10k, 10k-50k, 50k-250k, over-250k. A band from the other context is mapped to the smallest valid one. | |
| hasEmployees | No | false for a sole proprietor with no employees: workers' comp is replaced by a signed exemption declaration. | |
| usesVehicles | No | Drives to or around the site. false drops commercial auto. | |
| cancellationNoticeDays | No | Days of written notice before cancellation. 0 = as the policy provides. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds genuinely useful output context: it returns per-limit reasoning, contract-ready exhibit text, and a requirements object consumable by check_certificate, which matters since no output schema exists.
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 dense sentences with no filler, front-loaded with the core purpose and followed by the return contract. It is information-rich rather than bloated, though the long enumerated line of coverages is heavier than strictly necessary.
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 no output schema, the description carries the return-value burden and does so adequately by naming the three outputs. For a complex, nested, 7-parameter tool it could go further on how overrides and the boolean flags shape results, but nothing needed to invoke 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 100%, so baseline is 3, but the description adds the scaling relationship between trade risk and contract size that governs the outputs, which the schema documents only as raw enums. It still leaves overrides, hasEmployees, usesVehicles and cancellationNoticeDays to the schema, so it is a modest gain.
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 (recommends/builds) and resource (contract insurance requirements) with the exact lines covered (GL, auto, umbrella, WC, AI, waiver of subrogation, primary/non-contributory). It also distinguishes itself from the sibling check_certificate by naming that tool as the consumer of its output.
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?
Clearly scopes the two usage contexts (a GC hiring a subcontractor, or a PM/HOA hiring a vendor) and implies its role in a workflow by noting check_certificate accepts the output. It does not explicitly say when to prefer it over list_requirement_presets, but the context framing is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks a certificate of insurance (ACORD 25) against insurance requirements with CertifiKit's deterministic rules engine: coverage present, limits at or above the minimums, policies not expired or expiring too soon, and the required endorsements. Read the certificate yourself and pass what it shows; the verdict (pass, fail or needs_review) and a plain-English reason per requirement come from fixed rules, not a model. Anything unreported, unreadable or below 0.7 confidence is routed to needs_review, never silently passed. Use preset or the requirements object from build_insurance_requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| asOf | No | Date to check expiry against, yyyy-mm-dd. Defaults to today. | |
| preset | No | "standard-subcontractor" = Typical GC requirements for a trade sub: GL $1M/$2M, auto $1M, workers' comp $1M, additional insured + waiver of subrogation. "property-vendor" = Common requirements for service vendors at managed properties: GL $1M/$2M, workers' comp $500K, additional insured. | |
| certificate | Yes | What the certificate shows. Report only what is printed; do not infer. Leave out rows the certificate does not have. | |
| requirements | No | Custom requirements, e.g. the requirements object returned by build_insurance_requirements. Takes precedence over preset. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: deterministic fixed rules rather than a model, the three possible verdicts, per-requirement plain-English reasons, and the critical safety property that anything unreported, unreadable, or below 0.7 confidence goes to needs_review rather than silently passing.
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?
Four dense sentences, front-loaded with purpose, then self-read instruction, then verdict semantics, then the fail-safe routing rule. Every sentence carries information; the only mild redundancy is the enumeration of check categories, which partially overlaps the requirements schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must describe the return — and it does, naming the verdict values and the per-requirement reason string. Combined with the routing rule and the confidence threshold behavior, an agent has everything needed to call this 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 100%, so the baseline is 3; the description adds provenance semantics by tying the `requirements` object to build_insurance_requirements and presenting `preset` as the alternative source, plus the as-of framing. It does not restate the preset contents or confidence thresholds, but the schema already carries those.
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 (checks an ACORD 25 certificate of insurance) and enumerates exactly what is checked: coverage presence, limits, expiry, endorsements. It is clearly distinguishable from sibling build_insurance_requirements, which produces the requirements rather than evaluating against 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?
Explicitly directs the agent to read the certificate itself and pass what it shows, and names the two acceptable sources of requirements: 'preset or the requirements object from build_insurance_requirements.' This routes the agent to the sibling tool for the non-preset path rather than leaving it to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches CertifiKit's plain-English guides on certificates of insurance: reading an ACORD 25, additional insured endorsements (CG 20 10), waiver of subrogation, subcontractor and HOA vendor insurance requirements, COI tracking. Returns titles, summaries and links to cite. Leave query empty to list the newest.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Topic or question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description still adds real behavioral context beyond that: what the results contain ('titles, summaries and links to cite') and the empty-query default of returning the newest entries.
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, verb-first, with zero filler. The topic enumeration is long but functional, since it doubles as retrieval vocabulary, and the operational hint about an empty query is placed last where it is easy to find.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only tool with no output schema, the description covers what it searches, what it returns (titles, summaries, links) and the zero-arg behavior. The only meaningful gap is the absence of a when-to-use statement relative to its three 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 coverage is only 50% (the `limit` parameter has no description), but the description compensates richly for `query` by specifying the topic space it searches and telling the agent that an empty query lists the newest items. The bounds and default of `limit` remain documented only in the schema.
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 ('Searches CertifiKit's plain-English guides on certificates of insurance') and enumerates the covered topics, which makes it clearly distinct from a checker like check_certificate or a builder like build_insurance_requirements. It stops short of naming any sibling as an alternative, so it doesn't fully earn 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 only explicit usage instruction is 'Leave query empty to list the newest,' which addresses one invocation mode. There is no guidance on when to consult guides versus calling check_certificate or build_insurance_requirements, nor any stated prerequisites, so the routing signal is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The ready-made insurance requirement sets check_certificate accepts as preset: a standard construction subcontractor and a property / HOA vendor, with every limit and endorsement spelled out.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is fully covered. The description adds useful content context — that the presets are complete ('every limit and endorsement spelled out') — but says nothing about return format or how the presets are keyed, which would matter for feeding check_certificate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, and the resource is front-loaded. The colon list of presets makes it slightly run-on, 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 zero-parameter, read-only lookup with no output schema, the description is nearly sufficient: it identifies the resource, the consuming sibling, and the two presets. It could name the identifiers an agent must pass to check_certificate, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description correctly implies the call needs no input and simply enumerates what comes back, adding no misleading parameter language.
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 states the resource precisely (ready-made insurance requirement sets) and names the sibling that consumes them (check_certificate), and even enumerates the two available presets. It is clear what the tool returns, though the listing verb itself is only implied by the title rather than stated.
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: the presets exist to be passed to check_certificate, so an agent can infer this tool is for discovering preset identifiers before calling it. However, there is no explicit when-to-use guidance and no contrast with the alternative build_insurance_requirements, which is the obvious competing path for a custom requirement set.
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.
build_insurance_requirementscheck_certificatefind_coi_guideslist_requirement_presetsSubcontractor COI & paperwork tracking for general contractors — read-only demo tools.
Checks certificates of insurance (ACORD 25) against your requirements. Pay per call, x402 USDC.
Construction management for subcontractors: bids, projects, pay apps, change orders and CRM.
Verify, quote and track contractor insurance in your 1099Policy account.
Add one secure layer between your agents and this server.
