Daily Tampa Bay, Southwest and Central Florida permits with job value and contractor. Pay via x402.
Scored across 6 tools
Each tool targets a distinct access pattern: by contractor, by property, by search filters, by single permit ID, plus metadata and a sample. contractor_history and property_history are clearly differentiated by the entity (contractor vs. address). No two tools appear to overlap in purpose.
All names use snake_case, which is consistent. However, the set mixes verb_noun patterns (get_permit, search_permits, sample_permits) with noun phrases (contractor_history, property_history, coverage), a minor deviation from a single convention.
Six tools are well-scoped for a read-only permit data API. Each serves a clear, non-redundant purpose, and the count is neither thin nor bloated.
The surface covers the main query patterns: search by various criteria, retrieve by ID, history by contractor and property, plus coverage metadata and a sample. Minor gaps exist, such as no explicit pagination for search results (limited to 25 per call) and no tool for bulk retrieval by multiple IDs, but these are workable.
Every permit a contractor has pulled, with total job value and counts by trade. Price: $0.10 per call (x402, USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| contractor_key | Yes | contractor_key from a permit record, usually the license number in lower case |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the cost ($0.10 per call) and the payment mechanism (x402, USDC on Base), which an agent must know before invoking. It stops short of describing pagination or result limits, so 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?
Two short sentences, zero filler. The functional scope is front-loaded and the pricing constraint follows, so the most decision-relevant information comes first.
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-param read tool with no output schema, the description covers what is returned (permits plus aggregates) and the cost of calling. The main omission is result size/pagination behavior, but nothing critical to correct invocation 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?
Only one parameter and schema description coverage is 100%, so the schema already explains that contractor_key is a lower-cased license number from a permit record. The description adds nothing further about the parameter, which is the expected baseline when the schema does the work.
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 resource (every permit a contractor has pulled) and the exact payload (total job value, counts by trade). This is clearly distinguishable from the entity-scoped siblings property_history and get_permit, and an agent can tell what it retrieves without opening the schema.
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 guidance on when to use this versus property_history, get_permit, or search_permits, and no stated prerequisites beyond the price. The agent must infer that this is the contractor-scoped aggregation from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Cities covered today, permit counts, date range and last update time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output 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 structurally. The description adds the cost trait ('Free') and the freshness indicator (last update time), which are genuinely beyond the annotations, but says nothing about how the 'today' coverage snapshot is scoped or refreshed.
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 short sentence with the most decision-relevant token ('Free') front-loaded, followed by the payload contents. No filler, no repetition of the tool name or title.
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, closed-world informational tool with a full output schema and complete annotations, the definition is essentially sufficient; return values needn't be explained in prose since the output schema carries them. The only minor gap is the absence of any hint about cache/refresh cadence behind 'last update time'.
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 per the rubric. There is nothing for the schema to document and nothing for the description to compensate for; no parameter claims are made or needed.
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 resource (coverage) and enumerates the concrete payload — covered cities, permit counts, date range, last update time — which distinguishes it from the data-returning siblings like search_permits and get_permit. The verb is only implicit ('reports'), but the scope is unambiguous enough for an agent to distinguish an informational metadata 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 leading 'Free.' is a mild usage signal (call this at no cost, unlike possibly metered siblings), but there is no explicit when-to-use statement, no mention of checking coverage before running searches, and no named alternative. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One permit and every change recorded to its status, value or issue date. Price: $0.01 per call (x402, USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source key, e.g. tampa (the part before ':' in permit_key) | |
| permit_number | Yes | Permit number, e.g. BTR-27-0633248 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds two things the annotations cannot: the response includes the complete change history (audit trail), and the call is metered at $0.01 via x402/USDC on Base — a payment/auth requirement an agent must know before invoking.
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 sentences with zero filler; the return-content claim is front-loaded and the pricing constraint follows. Every clause carries information an agent needs.
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?
There is no output schema, and the description compensates by stating what comes back (the permit plus every recorded change to status, value, or issue date). Combined with the payment disclosure, this covers the essentials for a two-parameter read tool.
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% (source key and permit number examples are fully documented in the schema), so the baseline is 3. The description adds no parameter-level syntax or format detail beyond what the schema already provides.
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 a specific resource and scope: a single permit plus its full status/value/issue-date change log. The singular 'One permit' implicitly distinguishes it from the plural siblings search_permits and sample_permits, though it never names them outright.
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: 'one permit' suggests a singular lookup, contrasted with the search-oriented siblings. There is no explicit statement of when to use this versus search_permits, no prerequisites, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every permit recorded at one street address, newest first. Price: $0.05 per call (x402, USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | 5-digit zip code, to narrow the match | |
| address | Yes | Street address as shown in results, e.g. 4202 W CLEVELAND ST |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the payment requirement: $0.05 per call settled via x402 with USDC on Base, plus the newest-first ordering. That is genuinely useful operational context an agent must have before invoking, though pagination/volume behavior for a potentially large permit list is not disclosed.
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 short sentences, zero filler, and the result scope is front-loaded ahead of the cost note. Nothing here is redundant.
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 lookup with full schema coverage and no output schema, the description covers what is returned, ordering, and the unusual pay-per-call model. It leaves unaddressed how large the result set can be and what happens when no permits match the address.
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%, with both `address` and `zip` documented in the schema itself, so the baseline is 3. The description adds only the implicit notion that address is the primary key and zip is a narrowing hint, which the schema already conveys.
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+resource: returns every permit recorded at a single street address, with ordering ('newest first'). It contrasts implicitly with contractor_history by being address-keyed, but never names or distinguishes itself from siblings like search_permits or get_permit.
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: the phrase 'one street address' suggests using this when you already have a specific address rather than a search term. There is no explicit when-to-use, when-not-to-use, or named alternative, even though search_permits is an obvious competing choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Three recent permits, to see the record format before paying.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds two things the annotations cannot: the call is free and it returns exactly three recent records, which sets result-size expectations.
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 short fragments with zero filler, and the most decision-relevant fact (free) is front-loaded in the first word.
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?
A no-param preview tool with an output schema needs only to say what it returns and why, and it does both. The only unstated detail is whether the sample set changes over time, which is minor given the output schema covers the shape.
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?
Zero parameters, so there is nothing for the description to disambiguate; baseline applies. The implicit 'recent' scoping is the only selection behavior and it is stated in prose.
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 resource and scope: returns three recent permits as a sample. The 'free / before paying' framing implicitly separates it from the paid permit tools, though it never names a sibling such as search_permits or get_permit.
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?
Gives a clear use case — preview the record format before committing to a paid lookup. It does not state when-not-to-use it or name the alternative tools an agent should reach for once past the preview stage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search new building permits by trade, job value, date, zip or city. Newest first, up to 25 per call. Price: $0.02 per call (x402, USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Words in the work description, e.g. heat pump | |
| zip | No | 5-digit zip code | |
| city | No | City name, e.g. TAMPA | |
| limit | No | Results per call, 1 to 25 | |
| since | No | Filed on or after, YYYY-MM-DD | |
| trade | No | One of: roofing, hvac, solar, pool, electrical, plumbing, windows_doors, new_construction, remodel, demolition | |
| until | No | Filed on or before, YYYY-MM-DD | |
| offset | No | Start position for paging | |
| min_value | No | Minimum job value in US dollars | |
| jurisdiction | No | Source key from coverage, e.g. tampa |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely non-structured context: results are newest-first, capped at 25 per call, and each call costs $0.02 via x402/USDC on Base — a paid-call disclosure an agent must know before invoking.
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 sentences with no filler; the search scope is front-loaded and the operational constraints (ordering, page size, price) follow. Every clause earns its place.
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 covers result ordering and page size, and it discloses the payment model. It does not mention paging mechanics despite an offset param, but for a 10-param, all-optional search this is close to 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?
Schema description coverage is 100%, with each of the 10 params documented including the trade enum values and date format, so the baseline is 3. The description restates filter categories (trade, job value, date, zip, city) but adds no syntax, defaults, or interaction rules beyond 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 ('Search new building permits') plus the filterable dimensions (trade, job value, date, zip, city). It is clearly distinguishable from a single-record fetch like get_permit, but it never names or contrasts with the actual siblings (sample_permits, coverage, contractor_history).
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?
No guidance on when to use this instead of sample_permits (free preview?) or get_permit (single record) or coverage. The description implies a filtered list search but never states prerequisites, exclusions, or the alternative that should be chosen in other cases.
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.
contractor_historycoverageget_permitproperty_historysample_permitssearch_permitsNew building permits from 7 US cities scored as leads by trade, job value and contractor
Daily US building permits for 30 cities and counties. Free counts; records paid per call via x402.
Fresh US building permits with contacts from official city APIs. Construction lead generation.
U.S. building permits, permit histories by address and contractors from city and county records.
Add one secure layer between your agents and this server.