Skip to main content
Glama

HandledIQ: find and book home service

Check a license with the state

check_license
Read-onlyIdempotent

Asks whether a US contractor or trade license number is in force, with the state board that licenses that work: the board's status, the holder's name as the board lists it, the license kind, its end date, whether it covers the work asked about, and the day the board said so. Use it when the person wants to know whether a shop or a technician is licensed, given the number. Some states license the work only by city or county, or not at all; then it says so and gives the state's own page, or each city's and county's own page in local_lists. When a shop on HandledIQ holds the license, in force, its record and booking door come with the answer. It gives license status only, never a phone, an address or an email. Side effects: none.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "state": "<state>",
      "number": "<number>",
      "trade": "<trade>"
    },
    "name": "check_license"
  }
}

Input Schema

NameRequiredDescriptionDefault
stateYesThe state's two letters, like TX, AZ or DC.
tradeYesThe work the license is for: hvac (heating and cooling), plumbing, electrical, roofing, pest (pest control), contractor (general building) or demolition.
numberYesThe license number as it is printed, like M-39874 or ROC 123456.
signedNoOptional. true adds the shop's signed record, when a shop on HandledIQ holds the license, to check with verify_record. Leave it out unless the person asks for proof.

Output Schema

NameRequiredDescriptionDefault
noteNo
saysYes
stateYes
tradeYes
numberYes
look_upNo
licensesYes
checkableYesfalse when the state has no license to check for this work, or no list HandledIQ can read by number.
checked_onYes
local_listsNoWhere the state leaves the license to cities or counties: each one's own license page HandledIQ has, named by its place.
handlediq_shopNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly/idempotent/non-destructive, so "Side effects: none" is largely redundant, but the description adds real behavioral context: coverage gaps where the work is licensed only by city or county or not at all, the fallback of returning the state page or entries in local_lists, and an explicit negative scope (never a phone, address or email) that shapes how the agent should read the answer. It does not discuss rate limits or authentication, which keeps it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and the when-to-use clause are front-loaded and each sentence carries information about outcomes or scope. The paragraph is long and bundles several clauses, and "Side effects: none" duplicates the annotations, costing a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter, open-world lookup with an output schema, the description covers the important edge cases: states that do not license the work, city/county-level licensing, and the HandledIQ shop record plus booking door that can accompany a hit. Nothing needed to call or interpret it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the enum values, the two-letter state format, and the optional signed flag are already documented. The description reinforces the trade parameter's role ("whether it covers the work asked about") but adds no syntax or format detail beyond the schema, which is the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: asks whether a US contractor or trade license number is in force with the state board, and enumerates what comes back (status, holder name, license kind, end date, coverage, decision date). An agent can tell this apart from verify_record, which the description explicitly routes the proof request to.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use it when the person wants to know whether a shop or a technician is licensed, given the number" is a clear when-to-use condition, and the signed-parameter note tells the agent to leave it out unless proof is requested, pointing at verify_record. There is no explicit when-not-to-use against other siblings such as request_service or find_help, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources