Daily US building permits for 30 cities and counties. Free counts; records paid per call via x402.
Scored across 7 tools
The core split between free counting (count_permits), aggregate analytics (permit_stats, permit_trends), and paid record retrieval (search_permits, permit_history_for_address) is understandable, but count_permits vs permit_stats both answer 'how many permits' and differ only by filter shape. weekly_permit_report substantially overlaps with search_permits restricted to the last 7 days plus permit_trends, so an agent could reasonably pick the wrong paid endpoint.
All names are lowercase snake_case, which is good, but the convention mixes verb-first (count_permits, list_coverage, search_permits) with noun-first (permit_history_for_address, permit_stats, permit_trends, weekly_permit_report). Readable, but there is no single predictable pattern to guess a name from.
Seven tools is well within a healthy range and each covers a distinct facet of the permit-data domain (coverage, counts, records, history, stats, trends, weekly digest). Nothing feels padded or missing at the surface level.
The lifecycle from coverage discovery through free pre-checks to paid record retrieval and reporting is covered, with no obvious dead ends. Minor gaps: search_permits caps at 100 records with no pagination/cursor tool, and there is no way to look up a specific permit by id or filter by contractor.
How many permits match a search (area, category, city, zip, dates, minimum value) before paying for the records. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ||
| city | No | City name, case-insensitive | |
| since | No | Issued on or after (YYYY-MM-DD) | |
| until | No | Issued on or before (YYYY-MM-DD) | |
| category | No | Permit category, e.g. roof, pool, solar, hvac, new_residential | |
| minValue | No | Minimum job valuation in USD | |
| jurisdiction | Yes | Area id, e.g. new-york-ny, miami-dade-fl. Use list_coverage for names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is clear. The description adds valuable behavioral context by noting the call is 'Free' and that it is a preview before paying for records, which is not captured in the structured 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 a single front-loaded sentence that immediately states the count behavior and the free/paid context. Every phrase adds useful information with no filler.
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 count tool with high schema coverage and annotations, the description is nearly complete: it implies a numeric result and explains the free preview behavior. It could be slightly stronger by mentioning the required jurisdiction or using the exact parameter name 'jurisdiction' instead of 'area', but the gaps are minor.
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 86%, so the schema already documents nearly all parameters. The description lists the same search facets (area, category, city, zip, dates, minimum value) without adding syntax, defaults, or constraints beyond what the schema provides; 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 verb and resource ('How many permits match a search') and lists the search facets, so the agent can tell this is a counting tool. It does not explicitly name or contrast with sibling tools like search_permits or permit_stats, leaving some differentiation implicit.
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 'before paying for the records' gives a clear use context: check the count before purchasing records. However, it never explicitly names search_permits or states when to use count_permits versus permit_stats or permit_trends, so guidance is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List covered US cities and counties (ids, names, permit counts, newest permit date), permit categories and prices. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context by naming returned fields and stating the operation is free.
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 enumerates the key resources and fields without filler. 'Free.' is short and adds useful cost context.
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 metadata listing with no output schema, the description sufficiently explains the returned entities and fields. It does not specify ordering or formatting, but those omissions are minor for this kind of coverage lookup.
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 there are no parameter semantics to explain. The baseline score of 4 applies because no additional parameter guidance is 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 states a specific verb and resource: list covered US cities and counties, plus permit categories and prices. It is clear what the tool returns, though it does not explicitly contrast itself with permit-focused siblings such as search_permits or permit_stats.
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 explicit guidance on when to use this tool versus alternatives. 'Free' hints at cost but not workflow; an agent must infer that this should be used to discover coverage before searching permits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every known building permit at a street address in any covered area. Costs $0.10 in USDC (x402; Base, Solana, Polygon or Arbitrum).
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ||
| address | Yes | Street address, e.g. 1712 Bluebonnet Ln |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While the annotations state it is a read-only operation, the description crucially adds the behavioral context of cost ($0.10 USDC) and allowed networks. This is essential transactional data not found in the schema or hints.
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 tool is concisely described in a single, impactful sentence. It front-loads the core value proposition (the permits) and the critical transactional qualifier (the cost) efficiently.
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?
It is highly complete regarding its scope, stating 'Every known building permit' and defining the required input (address in a covered area). The absence of an output schema means the description must define the return content, which it does well.
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 50% schema coverage, the description adds semantic value by specifying that the inputs must represent a 'street address' located in a 'covered area,' giving conceptual context to the required parameters.
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 clearly and specifically targets 'building permit history' at a 'street address,' providing a precise scope of the tool's function and making it functionally distinct from sibling tools like 'permit_stats' or 'search_permits'.
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 states what the tool does and its cost, but offers no guidance on when to use it relative to its alternatives (e.g., when to use this over 'count_permits') or any prerequisites for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count building permits issued in the last N days (1-90) by category, for one area or all. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| jurisdiction | No | Area id, e.g. new-york-ny, miami-dade-fl. Use list_coverage for names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful context beyond that: the 1–90 day window bound and the word "Free," which signals no paid tier or quota barrier. It says nothing about the shape of the result (e.g. whether zero-count categories are returned), and there is no output schema to cover that gap.
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 compact sentence with the counted resource, grouping, window, and scope all front-loaded. Every clause carries information; nothing is padded or restated from the 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 two-parameter read-only counting tool this covers the essentials, but with no output schema the description should indicate what a result row looks like (category label plus count) or whether an all-areas query returns per-area breakdowns. The unresolved overlap with count_permits also leaves a decision 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?
Schema coverage is 50%: jurisdiction has a description pointing to list_coverage, while days has only structural bounds. The description clarifies "last N days (1-90)" as a lookback window and that area is optional, adding modest meaning, but it does not explain default behavior or how categories are defined.
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?
Specific verb and resource ("count building permits"), with grouping ("by category") and scope ("for one area or all") stated up front. It does not name or distinguish itself from the near-identical sibling count_permits, nor from permit_trends, so an agent cannot fully disambiguate from the text 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?
No statement of when to use this versus count_permits, permit_trends, or search_permits, all of which sound applicable to permit counts. The only routing clue ("Use list_coverage for names") lives in the schema, not the description, and "for one area or all" merely implies the jurisdiction parameter is optional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily permit counts and the busiest cities and zip codes for one category over the last N days. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| category | Yes | Permit category, e.g. roof, pool, solar, hvac, new_residential | |
| jurisdiction | No | Area id, e.g. new-york-ny, miami-dade-fl. Use list_coverage for names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value by disclosing the shape of the result (daily counts plus top cities/zips) and a 'Free' pricing tier, but says nothing about result limits, how many cities/zips are returned, or behavior when days exceeds the 90-day cap.
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 covering outputs, scope, and window, with no padding. The trailing 'Free.' fragment is terse but does convey a genuine constraint, so it 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?
This is a simple 3-parameter read tool with no output schema, so the description should fully describe what comes back and how jurisdiction interacts with the result. It covers the return shape adequately but leaves the jurisdiction filter and result-size behavior undocumented, which is a clear gap for a geo-breakdown 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 67%, so the baseline is 3. The description reinforces 'one category' and 'last N days', but omits the jurisdiction parameter entirely, which is a 30-value enum and the main narrowing knob; the schema alone has to carry that ('Use list_coverage for names').
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 concrete outputs (daily permit counts, busiest cities and zip codes) and the scoping dimensions (one category, last N days), which is clearer than a bare 'get trends'. It does not, however, contrast itself with siblings like permit_stats, count_permits, or weekly_permit_report, so an agent still has to infer the boundary.
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 explicit when-to-use or when-not-to-use guidance and no named alternative among the six siblings. The phrase 'over the last N days' only weakly implies time-series/trend use versus point-in-time counts, leaving the choice between this and permit_stats largely to guesswork.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Newly issued building permits with address, permit type, description, contractor, job value and issue date, filtered by area, category, city, zip, dates and minimum value. Up to 100 per call. Costs $0.05 in USDC (x402; Base, Solana, Polygon or Arbitrum).
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ||
| city | No | City name, case-insensitive | |
| limit | No | ||
| since | No | Issued on or after (YYYY-MM-DD) | |
| until | No | Issued on or before (YYYY-MM-DD) | |
| category | No | Permit category, e.g. roof, pool, solar, hvac, new_residential | |
| minValue | No | Minimum job valuation in USD | |
| jurisdiction | Yes | Area id, e.g. new-york-ny, miami-dade-fl. Use list_coverage for names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the per-call cap (up to 100) and, critically, the paid access model: $0.05 USDC via x402 on Base, Solana, Polygon or Arbitrum. That commercial precondition is exactly the kind of trait an agent cannot infer from structured fields. Missing is whether limits/pagination exist beyond the 100 record cap or what an empty result looks like.
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 compact sentences: the first front-loads what is returned and the filter axes, the second covers the cap and payment. No filler, no restatement of the tool name.
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, single-shot search with no output schema, the description supplies returned fields, filter scope, result cap and the payment requirement, which is enough to call it correctly. The one gap is pagination behavior beyond the 100-record limit, which matters for an agent that may need complete coverage.
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 75%, and the description compensates by naming every filter family present in the schema: area (jurisdiction), category, city, zip, date range and minimum value, plus the 100-record limit. It adds no format syntax or defaults beyond the schema, but it does confirm the semantic grouping rather than just restating.
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 the resource (newly issued building permits) and enumerates the returned fields plus the filter dimensions, which lets an agent form a concrete picture of the results. It does not explicitly contrast itself with siblings like count_permits, permit_stats or permit_history_for_address, so differentiation is left to inference from field/parameter lists.
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 filter list implies 'use this to find permits matching criteria,' but there is no explicit when-to-use guidance, no exclusions, and no named alternative (e.g., count_permits for totals, permit_history_for_address for address lookups). The only routing hint, 'Use list_coverage for names,' lives in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All building permits issued in the last 7 days for one area, with counts by category. Costs $0.50 in USDC (x402; Base, Solana, Polygon or Arbitrum).
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Permit category, e.g. roof, pool, solar, hvac, new_residential | |
| jurisdiction | Yes | Area id, e.g. new-york-ny, miami-dade-fl. Use list_coverage for names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context absent from structured fields: the call costs $0.50 in USDC via x402 and settles on Base, Solana, Polygon or Arbitrum — critical for an agent to know before invoking. It stops short of describing rate limits, retry behavior on payment failure, or pagination.
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, zero waste: purpose and scope first, then the payment prerequisite. Every clause earns its place and nothing is buried.
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 partially explain the return: permit records plus counts by category. For a simple two-parameter paid report, this covers what an agent needs to decide to call it, though it omits output field detail, pagination, and payment-failure behavior.
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 enums for both jurisdiction and category, so the schema carries the documentation load. The description adds only the 'one area' constraint, implying jurisdiction is a single value, but gives no guidance on how category interacts with the category-level counts in the output. Baseline 3 is appropriate when the schema is this rich.
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: 'All building permits issued in the last 7 days for one area, with counts by category.' This distinguishes it from broader siblings like search_permits or permit_history_for_address by its fixed 7-day window and per-area aggregation, but it never names those alternatives explicitly, so sibling differentiation is only implied.
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 constraints ('last 7 days', 'one area'), which signal it is not for custom date ranges or multi-area queries, but the description never states when to prefer permit_stats, permit_trends, or count_permits instead. No exclusions or prerequisites are given beyond the payment notice.
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.
count_permitslist_coveragepermit_history_for_addresspermit_statspermit_trendssearch_permitsweekly_permit_reportUS parcels and building permits from public sources. No owner data. Pay per record or monthly plan.
Fresh US building permits with contacts from official city APIs. Construction lead generation.
Building permits by address for a growing list of US cities and counties, from city open data.
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.