Look up Texas electrician licenses, renewal rules, TDLR forms and IERhub continuing education.
Scored across 9 tools
Most tools target clearly distinct actions: lookup_license (single record), get_license_stats (aggregates), get_renewal_path (rules), subscribe_alert (signup). The three form tools (list_forms, get_form, check_form_changed) share a resource but are separable by action, and lookup_license vs get_renewal_path overlap slightly since both surface fee information.
All names are snake_case verb_noun (check_, get_, list_, lookup_, subscribe_), which reads predictably. The verb choices vary (get_ vs lookup_) in a way that is mostly meaningful but slightly inconsistent for what are both single-record retrievals.
Nine tools map cleanly onto the domain: lookup, stats, license types, renewal rules, forms (list/get/change-check), course offer, and alerts. Each earns its place with no filler.
The surface covers lookup, aggregates, renewal guidance, form inventory, CE course, and alert signup — a solid lifecycle. Minor gaps remain: no way to list or cancel existing alert subscriptions, and license search is limited to number or last-name+type with no broader browse.
Say whether TDLR changed one form since the IERhub mirror was made: the unchanged-since date and any logged change rows.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, open-world behavior, and the description adds useful context beyond that: it says the tool compares against the IERhub mirror and returns an unchanged-since date plus logged change rows. It does not cover error behavior or detailed response structure, so it is not 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 description is a single front-loaded sentence that states purpose and expected return content without filler. The colon cleanly separates the action from what is returned.
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 one-parameter, read-only check with no output schema, the description gives enough to understand the tool's role and the high-level return values. It does not explain the 'id' parameter or the shape of the logged change rows, leaving a small 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?
The schema has one required 'id' parameter with 0% description coverage, and the description only says 'one form' without clarifying whether the id is a form id, its format, or how it is obtained. The description therefore does not compensate for the schema's lack of parameter documentation.
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 a specific action ('Say whether TDLR changed one form') and the comparison basis ('since the IERhub mirror was made'), so the purpose is clear. It does not explicitly differentiate itself from siblings like get_form or list_forms, which keeps it below 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 phrase 'since the IERhub mirror was made' implies the scenario for using this tool, but there is no explicit when-to-use guidance or comparison to alternatives such as get_form. An agent can infer usage, but routing between siblings is left unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The IERhub 4-hour TDLR approved continuing education course for Texas electricians: name, hours, TDLR course number, prices and the page to buy it.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Answer language, en or es. Default en. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds the useful detail of what data comes back (including a purchase URL), but says nothing about caching, freshness, or whether the offer varies by locale beyond the lang param.
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?
One compact sentence with no filler and the identifying details front-loaded. It loses a point only because it is a sentence fragment that never states the operation explicitly.
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 does the right thing by enumerating the returned fields, which is enough to know what comes back. However, for a tool whose sibling set includes several license/renewal tools, it omits the routing context an agent needs to pick it 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?
With a single parameter at 100% schema description coverage, the schema already fully documents `lang` (enum en/es, default en). The description adds no parameter guidance, e.g. that the course name and prices are returned localized, so baseline 3 applies.
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 names the specific resource and enumerates its fields (course name, hours, TDLR course number, prices, purchase page), which clearly distinguishes it from siblings like get_renewal_path and lookup_license. It is written as a noun phrase fragment rather than a verb+resource statement, so the action is only implied by the tool name.
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?
There is no statement of when to call this tool versus get_renewal_path or lookup_license, no mention of prerequisites, and no exclusions. An agent must infer usage from the field list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one TDLR electrician form by id: purpose, pages, mailing address, SHA-256 and the date of the last check.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| lang | No | Answer language, en or es. Default en. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds only that the record includes a SHA-256 and a last-check date, hinting at a change-tracking relationship with check_form_changed, but says nothing about missing-id behavior or rate limits.
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 front-loaded sentence with no filler; the field list is dense but informative. The trailing 'date of the last check' is slightly vague phrasing that could be tighter.
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 usefully names the returned fields, which is the main thing an agent needs. Gaps remain around unknown-id handling and what the SHA-256 actually represents, but for a simple single-record read this is largely sufficient.
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 50%: the 'lang' enum is fully documented in the schema while 'id' has no schema description. The description only confirms the id is the lookup key, adding little beyond what the required array already conveys, so baseline 3 fits.
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 ('Get one TDLR electrician form by id') and enumerates the returned fields (purpose, pages, mailing address, SHA-256, last-check date). This implicitly separates it from the sibling list_forms, though no sibling is actually named.
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 only implied: you call this when you already have a form id and want the full record. There is no explicit statement of when to prefer this over list_forms or check_form_changed, and no prerequisites or error behavior mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Counts of active licenses and licenses that expire within 3 months, by license type, from the daily Texas Department of Licensing and Regulation (TDLR) file pull.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional license type name or page slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond that: the counts come from a daily TDLR file pull, which tells the agent how fresh the data is. It does not state the return shape or whether the 3-month window is fixed.
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 front-loaded sentence with no filler; the grouping dimension and time window are stated compactly.
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 read-only aggregate tool with one optional param and no output schema, the description conveys the metric, the grouping, and the time window, which is enough to predict the response shape. Minor gaps remain around the fixed 3-month threshold and whether all types are returned when 'type' is omitted.
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?
With one optional parameter and 100% schema description coverage, the schema already documents 'type' as an optional license type name or page slug. The description does not clarify the filtering behavior, such as whether omitting it returns counts for all types. Baseline 3 applies.
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 a specific verb and resource (counts of licenses) plus a precise scope: active vs. expiring within 3 months, grouped by license type. This clearly separates it from lookup_license and list_license_types, though it doesn't name those siblings explicitly.
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 only implied by the aggregate framing ('counts ... by license type'), which suggests reporting rather than individual lookup. There is no explicit when-to-use, when-not-to-use, or named alternative among the eight siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Say how a Texas electrician license renews, for a license type and the months since it expired. Returns the window, the fee, the method (online, mail or reapply), and the forms to send.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | License type name or page slug. | |
| expires | No | Optional expiration date, YYYY-MM-DD, to add the three fee step dates. | |
| expired_months | Yes | Months since expiration. 0 or less means not expired. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description goes beyond them by disclosing the shape of the response (renewal window, fee, method of online/mail/reapply, and required forms), which is meaningful added context given there is no output schema. It stops short of stating data freshness, source of truth, or that results may be unavailable for unknown license types.
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 tight clauses — what it determines and what it returns — front-loaded with the domain and no filler. Every phrase corresponds to a capability or a returned field.
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 read-only, three-parameter query with no output schema, the description covers purpose and return fields explicitly, which is most of what an agent needs. The one gap is the optional `expires` input and its documented downstream effect, which the agent must discover from the schema alone.
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 the schema already documents all three parameters including the optional `expires` date. The description restates the two required inputs conceptually but adds nothing about `expires` and its effect of adding three fee-step dates to the result; baseline 3 is appropriate when the schema carries the load.
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 ("Say how a Texas electrician license renews") and enumerates the returned fields (window, fee, method, forms), so the agent knows exactly what it gets. It never names or contrasts the nearest siblings (lookup_license, get_form, list_license_types), so differentiation is left to inference.
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 phrase "for a license type and the months since it expired," which tells the agent the precondition implicitly (you need a license type and an elapsed-months count). There is no explicit when-to-use / when-not-to-use guidance and no pointer to lookup_license for basic facts or list_license_types for resolving the type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Texas Department of Licensing and Regulation (TDLR) electrician forms: id, title, form number, when a person needs it, and the PDF address. Optional filter.
| Name | Required | Description | Default |
|---|---|---|---|
| need | No | Optional word to filter by, for example expired or journeyman. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, openWorld), so the description's real contribution is disclosing the shape of each returned record, which matters because there is no output schema. It adds no notes on ordering, pagination, or result size, which keeps 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?
One front-loaded sentence plus a two-word qualifier, with the field list earning its place given the absent output schema. The trailing 'Optional filter.' fragment is slightly clipped and could be folded into the main sentence without loss.
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 one-optional-param read-only list tool whose annotations carry the safety profile, the description covers purpose and return fields adequately. Gaps are minor: nothing about result volume/ordering or how to move from a listed form to get_form.
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% and the single need parameter already documents itself with examples (expired, journeyman). The description's 'Optional filter' restates the schema rather than clarifying matching behavior (substring vs. exact, which fields are searched).
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 (List) and resource (TDLR electrician forms) and even enumerates the fields returned (id, title, form number, need, PDF address). It doesn't explicitly contrast itself with the singular sibling get_form, so the agent must infer the list-vs-fetch distinction from the verb alone.
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?
'Optional filter' implies the two usage modes (list everything vs. narrow with need), but there is no explicit when-to-use statement and no mention of get_form or check_form_changed as alternatives. Usage is inferable but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The ten Texas electrician license types that IERhub holds renewal fees for: page slug, name, renewal fee and the lookup page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful content context, namely that the result is a finite set of ten types and what fields are included, but it discloses no additional behavioral traits like caching, pagination, or auth requirements.
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 front-loaded sentence with no filler. It immediately identifies the finite set of license types and names the fields returned.
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 list tool with no output schema, the description is complete enough: it specifies the scope, the finite count, and the returned fields. The annotations cover the safety behavior, and no additional parameter guidance is needed.
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 zero parameters, so parameter semantics are not a burden. Per the baseline for zero-parameter tools, a 4 is appropriate; the description adds the returned field names rather than parameter information.
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 a specific resource and scope: the ten Texas electrician license types IERhub holds renewal fees for, plus the returned fields. It is clearly distinguishable from siblings like lookup_license or get_license_stats, though it does not explicitly name an alternative.
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: an agent can infer this is the reference list to call when it needs license-type metadata. However, there is no explicit when-to-use guidance, no exclusion conditions, and no mention of alternatives such as lookup_license or get_license_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one Texas electrician license in the Texas Department of Licensing and Regulation (TDLR) file by license number, or by last name plus license type. Returns type, number, county, expiration date, the renewal state, and the fees for an expired license.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Answer language, en or es. Default en. | |
| type | No | License type name or page slug, for example journeyman-electrician. | |
| number | No | License number, letters, digits and hyphen, 20 characters at most. | |
| last_name | No | Last name, 2 letters or more. Use with type. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds useful behavioral context by listing returned fields and noting that fees are for an expired license, though it does not explain behavior for no matches or multiple matches.
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 two focused sentences. The lookup modes are front-loaded and the return fields follow efficiently, with no redundant or wasted language.
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 lookup tool with no output schema, the description compensates well by naming the returned fields. It remains slightly incomplete on edge-case behavior such as no match or multiple matches from a last-name-plus-type search.
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 the schema already documents the parameters, including the last_name-plus-type constraint and the lang enum. The description reinforces the lookup modes but adds little parameter detail beyond what the schema provides, making 3 the appropriate baseline.
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 a specific verb and resource: looking up one Texas electrician license in the TDLR file. It clearly distinguishes a single-license lookup from sibling tools like get_license_stats and list_license_types, though it does not explicitly name those alternatives.
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 gives clear invocation paths: by license number, or by last name plus license type. This provides enough context for an agent to know how to use the tool, but it does not explicitly state when to prefer this over sibling tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an email alert sign up for one license: 30 and 7 days before it expires, and at each fee step after. Writes a pending record and sends a confirm email. Ask the person first.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Answer language, en or es. Default en. | |
| type | No | Optional Worker license type, when the number belongs to more than one type. | |
| Yes | |||
| number | Yes | ||
| confirmed | No | true only after the person agreed to the sign up. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a write operation (readOnlyHint false), open-world (openWorldHint true), and non-destructive. The description adds important side-effect context: it writes a pending record and sends a confirm email, and it specifies the alert timing behavior. It stops short of explaining confirmation flow or idempotency, but adds meaningful value beyond the 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?
The description is three short sentences: purpose and schedule first, side effects second, consent requirement last. Every sentence adds information, and there is no wasted phrasing.
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 write tool with no output schema and five parameters, the description covers the key behavioral facts an agent needs: consent, pending record creation, confirmation email, and alert timing. Missing details like double opt-in mechanics or failure behavior are minor given the annotations and schema descriptions.
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 60%, leaving required parameters like 'number' and 'email' without schema descriptions. The description implies 'number' refers to a license and 'confirmed' relates to prior consent, but it does not define the parameters directly or clarify the optional 'type' disambiguation beyond what the schema already says. Baseline 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 states a specific action ('Start an email alert sign up'), resource ('for one license'), and concrete schedule (30 and 7 days before expiry, plus fee steps). It is clear enough to distinguish from the read-only license/form siblings, though it does not explicitly name or rule out any sibling tool.
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 instruction 'Ask the person first' gives a clear consent prerequisite, and 'confirmed' in the schema reinforces that the call should only be made after user agreement. It does not explain when not to use it or mention any alternative tool, but the context is clear.
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.
check_form_changedget_course_offerget_formget_license_statsget_renewal_pathlist_formslist_license_typeslookup_licensesubscribe_alertVerify a contractor, real estate or cosmetology license in 12 US states from the boards' own files.
Verify contractor licenses: 50 states + DC + 8 cities — status, expiration, disciplinary history.
Licensed master electrician in SE Wisconsin — estimates, scheduling, and code lookups via AI.
Search and verify fire protection contractor licenses (TX SFMO, CA CSLB C-16) from state records.
Add one secure layer between your agents and this server.
