Building permits by street address for 8 US cities, from city open data. Free, no key.
Scored across 4 tools
Each tool targets a distinct lookup path: permit number, city list, address, and recent permits. An agent can easily tell which tool to use for a given query without ambiguity.
All names use snake_case, which is consistent, but the pattern mixes verb_noun (get_permit, list_cities) with noun phrases (permits_at_address, recent_permits). The deviation is minor and still readable.
Four tools is well-scoped for a focused building-permit lookup service. Each tool covers a distinct access pattern and none feels redundant.
The surface covers core permit retrieval by number, address, and recency, plus supported cities. Some secondary operations like filtering by permit type, contractor, or date range are missing, but agents can work around these gaps for most tasks.
One building permit by its city permit number.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| permit_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses almost nothing: no note that this is a read-only lookup, no behavior when the permit number is unknown, and no permission requirements. The read-only nature is inferable from "One building permit" but never stated.
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-fragment with no wasted words. It is arguably too terse given what is left unsaid, but there is no padding or redundancy.
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?
The tool is simple (two required params, no nested objects, no output schema), so a short description is defensible. However, with zero annotation and zero schema-description coverage, the description leaves the lookup key semantics and failure behavior entirely undocumented.
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 0%, so the description must compensate. "By its city permit number" loosely maps to the two parameters (city and permit_id) but adds no format, naming convention, or expected value detail beyond what the bare schema fields already list.
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?
"One building permit by its city permit number" identifies the resource (a single building permit) and the lookup key, distinguishing it from the plural siblings (recent_permits, permits_at_address, list_cities). The verb is only implied by the sentence fragment, but the singular lookup is unambiguous.
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 use this versus permits_at_address or recent_permits. The lookup key implies the precondition (you must know city + permit number), but the agent gets no explicit routing guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the US cities with building permit data, with each city's slug for the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. 'List' conveys a non-mutating enumeration and it discloses the return shape (city names plus slugs), which is useful, but it says nothing about ordering, scope limits, or whether results are paginated.
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 tightly written sentence with no filler, and the core purpose is front-loaded before the return-value note.
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 no-parameter enumeration tool with no output schema, the description covers what is returned (cities and their slugs) and why those slugs matter, which is enough for correct invocation. Minor gaps around result ordering/limits remain but are not blocking.
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 zero parameters, so there is nothing to document; the baseline of 4 applies. The description correctly implies the tool takes no filters.
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 ('US cities with building permit data'), and the trailing clause clarifies the payload (slugs). It is clearly distinguishable from siblings get_permit/permits_at_address/recent_permits, which all operate on individual permits, though it does not name them 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?
The phrase 'each city's slug for the other tools' implies this is a discovery/prerequisite step feeding the sibling tools, but it never states when to call it or when it is unnecessary. Usage is implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All building permits on record at a street address in a supported city: what is being built, remodeled or demolished there, when, and reported cost. From city open data, refreshed several times a day.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug, e.g. los-angeles, new-york, chicago | |
| address | Yes | Street address with house number, e.g. '867 N Iliff St'. New York: include the borough, e.g. '180 West Street, Brooklyn'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses useful context an agent could not get elsewhere: the data provenance (city open data) and refresh cadence (several times a day), plus the fields returned. It does not say whether the operation is read-only, what happens when no permits exist, or whether any city/address combinations are unsupported beyond 'supported city'.
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, front-loaded with the operation and scope, with the provenance/freshness note compressed into a single short trailing sentence. No filler or repetition.
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 compensates by describing the returned content (project type, timing, reported cost). It leaves minor gaps around empty results and result volume/pagination, but covers what an agent needs to call it and interpret the payload.
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 both parameters carry format examples (city slug, address with house number, borough for New York), so the schema does the heavy lifting. The description adds only the 'supported city' framing, which slightly reinforces the city constraint but nothing the schema lacks.
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 pair (all building permits at a street address) with scope qualifiers (supported city) and enumerates the returned fields. It implicitly separates itself from recent_permits (time-scoped) and get_permit (single record), though it never names a sibling 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 scope phrase 'at a street address in a supported city'; there is no explicit when-to-use, when-not, or pointer to an alternative like recent_permits or get_permit. An agent can infer the lookup-by-address intent but must guess at the routing rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The newest building permits in a city, optionally within one ZIP code or district.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | ZIP code (most cities) or district number | |
| city | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It conveys ordering ('newest') but says nothing about the default result count, whether the limit caps results, pagination behavior, or backing data freshness, all of which matter for a list tool with a limit parameter.
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 resource, recency ordering, and optional narrowing all appear before any wasted words.
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 three parameters, 33% schema coverage, no annotations, and no output schema, the definition is minimal but workable. It leaves the limit/default behavior and the shape of returned permits unexplained, which an agent would want before calling.
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 33%, so the description must compensate. It successfully clarifies that 'area' is a ZIP code for most cities or a district number, but 'limit' is never mentioned and 'city' only appears indirectly as the scoping noun, leaving the result-cap semantics undocumented.
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 (building permits), a recency qualifier ('newest'), and a scope constraint (a city, optionally narrowed to a ZIP code or district). An agent can distinguish it from get_permit (singular) and permits_at_address by implication, though no sibling is named 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 implied by 'newest' and the optional area filter, but the description never says when to prefer this over permits_at_address or get_permit, nor any prerequisites or exclusions. The context is inferable rather than stated.
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.
get_permitlist_citiespermits_at_addressrecent_permitsBuilding-permit verdicts by address, with cited records. SF, Seattle, Austin, NYC. Pay per call.
Pull recent building permits from 9 US cities in a unified schema from official open-data portals.
Fresh US building permits with contacts from official city APIs. Construction lead generation.
Source-linked building-permit search across 34 US states and DC, with county-level coverage.
Add one secure layer between your agents and this server.