Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@muni-dev-cost Get development costs for Austin, TX"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
What will the city and utility charge me to build here?
muni-dev-cost is an MCP server (and a pay-per-call x402 API) that gives an AI
agent the municipal development cost for a US jurisdiction — the
impact/development fees, water & sewer tap (connection) fees and
capital-recovery charges a real-estate developer must pay before breaking
ground — aggregated and normalized from public, government-published fee
schedules into one comparable number.
For a real-estate development-feasibility / pro-forma agent, this number is load-bearing and, today, costs weeks of manual digging across municipal ordinances, utility fee schedules and county portals. We do the aggregation so your agent doesn't have to.
// add to your MCP client config
{ "mcpServers": { "muni-dev-cost": { "command": "npx", "args": ["-y", "muni-dev-cost-mcp"] } } }Tool | Tier | What you get |
| Free | The aggregated municipal development cost for a jurisdiction (single-family home), split into water+sewer vs other impact, with a per-fee summary and an honest coverage label. |
| Premium | Every fee line by line, grouped (Water / Sewer / Transportation / Parks / Drainage), with the per-meter-size schedule and each source + effective date. |
| Premium | Rank 2–12 markets side by side for site selection — total, water+sewer split, the dollar/% spread and what it costs on a 100-unit project. |
| Premium | Water & sewer connection cost by meter size (5/8" → 12") — the single biggest swing in a utility connection budget. |
| Premium | Whole-project fees (fees × units) with per-unit and extended line items, dev-type aware, explicit about exclusions. |
| Premium | The full coverage map — every jurisdiction, its depth and data freshness, which publish a per-meter schedule, plus the benchmark states. |
| Premium | The published source document + per-fee provenance (published vs estimated) behind a jurisdiction's number — defensible trazabilidad for a pro-forma. |
| Premium | The real dated revision history of a jurisdiction's headline fee (prior years + adopted future steps) with YoY delta and CAGR — never a projection. |
| Premium | One jurisdiction's water/sewer cost across every published meter size, ratioed to the 5/8" residential base. |
| Premium | Multifamily/mixed fee estimate by LUE (units × LUE-per-unit) — the way cities actually bill MF, so it doesn't overstate fees. |
| Premium | The grand total across every fee category (water/sewer, transportation, parks, drainage, public-safety, other), bucketed — with honest $0 buckets where a city simply doesn't charge that category. |
| Premium | Every line item within one category (e.g. all of a city's parks fees) with per-meter detail — errors honestly if the city doesn't levy that category. |
| Premium | Rank the entire covered KB cheapest→priciest by water+sewer or total, with cheapest/median/priciest, the spread, and a site-selection insight — filterable by state/coverage. |
| Premium | A state-level roll-up over the whole KB: per state, the city count, min/median/max cost, cheapest/priciest city, and which fee categories are assessed — the map for "which states are cheap/expensive to build in." |
1 free + 13 premium tools. The free
get_dev_costsis the hook; the 13 premium tools are the depth a feasibility agent can't assemble itself.
POST https://muni-dev-cost-mcp.vercel.app/dev-costs
{ "jurisdiction": "Phoenix, AZ" }🏗️ Phoenix, AZ · coverage 🟢 deep
Municipal development cost, single-family home: $29,322
• Water + sewer (impact + tap): $29,322
Fees included (one line each):
• Wastewater Collection impact fee: $5,127 (per dwelling)
• Wastewater Treatment impact fee: $3,753 (per dwelling)
• Water Transmission impact fee: $14,046 (per dwelling)
• Water Treatment impact fee: $4,387 (per dwelling)
• Water Resource Acquisition fee: $2,009 (per dwelling)Related MCP server: LandlordLaw MCP Server
We never pass off an estimate as a city's published number.
🟢 deep — the city's own water/sewer fee schedule was ingested, including
the per-meter table. Figures are published.
🟡 partial — headline impact figures from public schedules; some categories estimated.
🟠 estimated — the exact city isn't in our deep KB yet, so figures are a regional benchmark, clearly marked. Use as order-of-magnitude only.
Coverage today: 130 jurisdictions across 38 states — 109 deep (own per-meter/per-LUE schedule ingested) + 21 partial. Dense in the high-growth markets a feasibility agent actually screens: TX (18), CO (18), FL (18), NC (16), CA (11), plus AZ, GA, WA, OR and more. From the cheapest covered market (Mobile, AL ~$1,000) to the priciest (Erie, CO ~$78,350), ranked and queryable. Any US city not yet ingested returns an honest state benchmark estimate — and the deep KB grows every iteration.
All fee data is sourced from public, government-published fee schedules (works of US municipal government → public domain). Each jurisdiction carries its source URL and effective date. Indicative — verify the exact amount with the jurisdiction. Not legal or fee-certification advice.
💳 Card (Stripe) — buy a prepaid API key at /pro/checkout, then set
"env": { "MUNI_DEV_COST_KEY": "<key>" }.
🪙 x402 (USDC on Base) — AI agents pay per call automatically; no signup.
The free get_dev_costs works with no key.
The aggregation engine, the normalized fee knowledge base and the accumulating
per-jurisdiction cache run server-side. The npm package is a thin client:
it forwards your call to the hosted server and renders the response. The fee data
and the premium logic never ship in the tarball — a moat verified on every build
by npm run test:moat.
MIT. Source: https://github.com/Baneado98/muni-dev-cost
Get every fee line within ONE named category for a US jurisdiction — e.g. just the parks impact fees, just the transportation/street fees, just the water impact, or fire/police/drainage/library — with the per-meter-size schedule where the city publishes one. Lets your agent pull exactly the cost component it needs (e.g. 'what are Fresno's parks fees?') without parsing the whole breakdown. Pass 'jurisdiction' or 'address' and a 'category' (water / water_tap / sewer / transportation / parks / drainage / fire / police / library / school / general). PREMIUM: pay per call with x402 (USDC on Base) or set a prepaid key (MUNI_DEV_COST_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | No | 'City, ST' or city name. Provide this OR address. | |
| address | No | US street address. Provide this OR jurisdiction. | |
| category | Yes | Fee category: water, water_tap, sewer, transportation, parks, drainage, fire, police, library, school, general. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the optional per-meter-size schedule and billing requirements (PREMIUM), but does not detail the response format, any rate limits, or authentication beyond billing. This provides basic but not comprehensive behavioral insight.
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 concise (4 sentences), front-loads the main purpose, and uses clear structure with examples and a list of allowed categories. Every sentence adds value with no 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?
With no output schema, the description hints at return values (fee lines and schedule) and covers billing. It explains the parameter alternatives and category options well. However, it does not specify the data structure of 'fee line', but given the sibling tools, this is acceptable.
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 100%, so the schema already documents each parameter. The description adds value by clarifying the relationship between 'jurisdiction' and 'address' (alternatives) and by indicating that the output includes a per-meter-size schedule when available, which is not in 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?
The description clearly states the tool's action ('Get every fee line within ONE named category for a US jurisdiction'), its resource (fee lines), and its scope (single category per call). It distinguishes from siblings like 'get_fee_breakdown' by emphasizing it extracts one component without parsing the whole breakdown.
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 includes explicit examples of when to use (e.g., 'what are Fresno's parks fees?') and contrasts with the alternative of 'parsing the whole breakdown'. However, it does not provide explicit when-not-to-use scenarios or directly compare to all 14 sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one jurisdiction's water/sewer development cost across EVERY meter size it publishes (5/8" → 12"), each with its ratio to the 5/8" residential base. A larger meter (a 2" meter is often 8–12× the residential fee) is the single biggest swing in a utility-connection budget — this lays out the whole curve so you size the right meter cost up front. Pass 'jurisdiction' or 'address' and optionally 'category' ('water' / 'sewer' / 'water+sewer', default 'water+sewer'). Only works for jurisdictions that publish a per-meter schedule. PREMIUM: pay per call with x402 (USDC on Base) or set a prepaid key (MUNI_DEV_COST_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | No | 'City, ST' or city name. Provide this OR address. | |
| address | No | US street address. Provide this OR jurisdiction. | |
| category | No | 'water', 'sewer', or 'water+sewer' (default). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the premium pricing model (pay per call or prepaid key) which is a behavioral trait. However, it does not explicitly state that the operation is read-only, nor does it mention rate limits or authentication requirements beyond the premium note.
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 paragraph that is front-loaded with the core action. Every sentence adds value, from the main purpose to the motivational context, parameter usage, constraint, and premium info. It is efficient without being sparse.
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?
Given no output schema, the description explains the output concept (costs and ratios for each meter size) but does not detail the exact structure of the return value. It is mostly complete for a simple query tool with 3 parameters, but adding explicit output fields would improve completeness.
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 baseline is 3. The description adds the default value for 'category' ('water+sewer') and clarifies the mutual exclusivity of 'jurisdiction' and 'address'. This adds some value but does not significantly expand beyond the schema's own descriptions.
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 states the tool's purpose: 'Get one jurisdiction's water/sewer development cost across EVERY meter size it publishes (5/8" → 12"), each with its ratio to the 5/8" residential base.' It uses specific verbs and resources and distinguishes itself from sibling tools like 'compare_jurisdictions' by focusing on a per-jurisdiction meter size analysis.
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 provides explicit usage context: it explains when to use the tool ('size the right meter cost up front') and includes a constraint ('Only works for jurisdictions that publish a per-meter schedule'). However, it does not explicitly mention when not to use it or compare it directly to alternative tools from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare the municipal development cost of TWO OR MORE US jurisdictions side by side, ranked cheapest-to-priciest per unit — the site-selection question a developer asks before buying land. Returns each market's total with its water+sewer vs other-impact split, the dollar spread and % gap between the cheapest and priciest, and what that spread costs on a 100-unit project. Pass 'jurisdictions' as an array (e.g. ['Phoenix, AZ', 'Raleigh, NC', 'Austin, TX']) and optionally 'dev_type'. PREMIUM: pay per call with x402 (USDC on Base) or set a prepaid key (MUNI_DEV_COST_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdictions | Yes | 2–12 jurisdictions as 'City, ST' strings. | |
| dev_type | No | Development type (default single_family). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses return values (total, split, spread, gap, cost on 100-unit project) and payment requirements (x402 or prepaid key). It lacks mention of rate limits or idempotency, but the read-only nature is implied.
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 concise with four sentences, each serving a clear purpose: stating the main action, describing output, explaining parameters, and noting premium access. No superfluous information.
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?
Given no output schema and only two parameters, the description adequately explains outputs and usage. It covers key details but omits default behavior for dev_type and error scenarios, which are minor gaps.
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 100%, and the description adds examples ('['Phoenix, AZ', 'Raleigh, NC', 'Austin, TX']') and clarifies the default for dev_type, enhancing understanding beyond the schema alone.
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 uses specific verbs ('Compare', 'ranked') and identifies the resource ('US jurisdictions', 'municipal development cost'). It clearly distinguishes from siblings like 'rank_jurisdictions_by_cost' by emphasizing side-by-side comparison and specific return details.
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 when to use this tool ('site-selection question a developer asks before buying land') and explains parameter format with examples. It does not explicitly contrast with alternatives but provides sufficient context for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the total MUNICIPAL FEES for a MULTIFAMILY / mixed-use project by LUE (Living Unit Equivalent) — units × LUE-per-unit — the way cities actually bill multifamily. Captures that a small apartment unit is a FRACTION of a single-family LUE (≈0.6), so it doesn't overstate MF fees the way a flat per-unit estimate does. Returns per-unit and extended line items; override the LUE factor with the jurisdiction's adopted one. Explicit about exclusions (land, construction, financing). Pass 'jurisdiction' or 'address', 'units', optionally 'dev_type' (default multifamily), 'lue_per_unit' and 'meter_size'. PREMIUM: pay per call with x402 (USDC on Base) or set a prepaid key (MUNI_DEV_COST_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | No | 'City, ST' or city name. Provide this OR address. | |
| address | No | US street address. Provide this OR jurisdiction. | |
| units | Yes | Number of units in the project (REQUIRED). | |
| dev_type | No | Development type (default multifamily). | |
| lue_per_unit | No | LUE per unit override (default by dev_type, e.g. multifamily ≈ 0.6). | |
| meter_size | No | Water meter size per unit (default 5/8"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides significant behavioral context: it explains the LUE method, exclusions, return of line items, override capability, and premium pricing. Lacks error handling or state mutation details.
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 information-dense paragraph, front-loaded with the core purpose. Every sentence adds value, covering method, exclusions, parameters, and pricing. Could be slightly better structured for readability.
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?
Given 6 parameters and no output schema, the description is quite complete: it explains the key concept (LUE), parameter overrides, exclusions, and pricing. Could be improved by noting the output format or sample results.
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 100%, and the description adds valuable context on LUE (fraction of single-family), default values, and the relationship between parameters. It enhances understanding beyond the schema's basic descriptions.
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 states the tool estimates municipal fees for multifamily projects using LUE, contrasting with flat per-unit estimates. It specifies the resource (fees by LUE) and distinguishes from siblings like 'estimate_dev_cost'.
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 explains when to use it (multifamily/mixed-use projects) and how it differs from flat estimates. It lists parameters but does not explicitly state when not to use it or refer to sibling tools for other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the total MUNICIPAL FEES for a whole development project — fees × number of units — with per-unit and extended line items. The number a developer needs to size the fee line of a pro-forma before breaking ground. Dev-type aware and explicit about what's EXCLUDED (land, hard construction, soft costs, financing, profit) so it isn't mistaken for total project cost. Pass 'jurisdiction' or 'address', 'dev_type', 'units' (the unit count), and optionally 'meter_size'. PREMIUM: pay per call with x402 (USDC on Base) or set a prepaid key (MUNI_DEV_COST_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | No | 'City, ST' or city name. Provide this OR address. | |
| address | No | US street address. Provide this OR jurisdiction. | |
| dev_type | No | Development type: single_family / multifamily / commercial / retail / office / industrial (default single_family). | |
| units | Yes | Number of units in the project (REQUIRED). | |
| meter_size | No | Water meter size per unit (default 5/8"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions premium payment requirements (pay per call with USDC or prepaid key), but does not discuss auth needs, rate limits, data modification, or side effects. The description adds context beyond the schema but is incomplete for a mutation-free tool.
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 front-loaded with the core purpose and subsequent sentences add value: usage context, exclusions, parameter list, and payment details. It is efficient, albeit slightly lengthy, with no 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?
Given the lack of output schema and annotations, the description partially covers return format ('per-unit and extended line items') but does not explain the exact output structure or error handling. With five parameters and no output schema, more detail on return values and edge cases would improve completeness.
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 baseline is 3. The description repeats parameter names and notes that jurisdiction/address are alternatives, which adds minor clarification, but does not provide additional semantic details beyond what 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?
The description clearly states that the tool estimates 'total MUNICIPAL FEES for a whole development project' and distinguishes it from total project cost by explicitly listing exclusions (land, hard construction, soft costs, financing, profit). It also specifies the calculation method (fees × number of units) and includes context about developer pro-forma needs.
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 provides context that this tool is for sizing the fee line of a pro-forma before breaking ground and mentions it is dev-type aware with exclusions. However, it does not explicitly state when not to use this tool or compare it against sibling tools like get_total_dev_cost or get_fee_breakdown, leaving the agent to infer usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the REAL dated revision history of a jurisdiction's headline development fee — prior years' adopted/charged figures plus officially adopted FUTURE steps (e.g. a council-adopted Oct-1 increase) — with the year-over-year delta and the compound annual growth rate across the published span. NOT a forward projection: only the jurisdiction's own dated/adopted schedules. The signal a developer needs to budget the fee line at the rate in effect when they'll actually pull permits, not today's. Only returns where the city publishes multiple dated schedules. Pass 'jurisdiction' or 'address'. PREMIUM: pay per call with x402 (USDC on Base) or set a prepaid key (MUNI_DEV_COST_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | No | 'City, ST' or city name. Provide this OR address. | |
| address | No | US street address. Provide this OR jurisdiction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool is paid (PREMIUM), returns real schedules (not projections), and only works for jurisdictions with multiple dated schedules. It does not mention idempotency or rate limits, but the paid nature and data constraints are well-covered.
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 longer but each sentence adds value: purpose, constraints, usage guidance, and payment info. It front-loads the core action. Could be slightly tightened, but overall effective.
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?
Given no output schema and moderate complexity, the description adequately explains what the tool returns (history, delta, CAGR) and its limitations (only where multiple schedules exist). It covers the paid nature and parameter options, making it complete for an agent to decide whether to use it.
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 100%, so baseline is 3. The description adds 'Pass jurisdiction or address' which reinforces mutual exclusivity, but the schema already says 'Provide this OR address.' No additional parameter semantics beyond the schema are provided.
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 states the tool retrieves the real dated revision history of a jurisdiction's headline development fee, including prior years' figures and future adopted steps, with delta and CAGR. This distinguishes it from sibling tools that estimate costs or compare jurisdictions.
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 explains when to use (to budget fee based on future permit pull date), explicitly says 'NOT a forward projection', and notes that it only returns data where the city publishes multiple schedules. It also mentions payment via x402 or prepaid key. However, it does not directly contrast with all sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the total MUNICIPAL DEVELOPMENT COST to build in a US jurisdiction — the impact/development fees, water & sewer tap (connection) fees and capital-recovery charges a real-estate developer must pay the city/utility before breaking ground — for a standard single-family home. Returns ONE aggregated USD figure, the water+sewer vs other-impact split, and a one-line summary of each fee included. This is the number a development-feasibility / pro-forma analysis needs and that today costs weeks of manual digging across municipal ordinances, utility fee schedules and county portals. We AGGREGATE and NORMALIZE it from public, government-published fee schedules so your agent doesn't have to. Pass a 'jurisdiction' ('Phoenix, AZ', 'Raleigh, NC') or a US 'address'. Coverage is honest: 'deep' = the city's own water/sewer schedule was ingested (per-meter detail); 'partial' = headline figures from public schedules; 'estimated' = a regional benchmark when the exact city isn't in our deep KB yet (clearly marked, never passed off as the city's published number). FREE. For the fee-by-fee breakdown, per-meter water/sewer schedule, multi-jurisdiction comparison or a whole-project estimate, use the premium tools. Indicative — verify with the jurisdiction.
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | No | Jurisdiction as 'City, ST' ('Phoenix, AZ') or a city name ('Raleigh'). Provide this OR address. | |
| address | No | A US street address ('123 Main St, Raleigh, NC 27601'); the city+state are extracted from it. Provide this OR jurisdiction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool aggregates and normalizes data from public fee schedules, is free, and is indicative. It honestly marks coverage levels and never passes off estimated data as exact. However, it does not explicitly state that the tool is read-only or non-destructive, which would be helpful. Still, the behavioral traits are well communicated.
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 fairly long but well-structured: it starts with the core purpose, then explains inputs, coverage levels, and caveats. Every sentence adds value, but some redundancy exists (e.g., explaining what the fee is). It is front-loaded with the main action. Could be slightly more concise, but overall efficient.
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?
Given the complexity of the tool (multiple fee types, coverage levels, need for jurisdictional data) and the absence of an output schema, the description is remarkably complete. It explains what the tool does, how to use it, what the output looks like, coverage honesty, and limitations (indicative, verify with jurisdiction). It covers all essential aspects for effective use.
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 100%, so baseline is 3. The description adds significant meaning beyond the schema: it explains the difference between 'jurisdiction' and 'address' inputs, provides examples, and clarifies that the tool extracts the city+state from the address. It also describes the output (aggregated USD, split, summary), which compensates for the lack of an output 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?
The description clearly states the tool gets the total municipal development cost for building a standard single-family home in a US jurisdiction, listing specific fees included (impact, water/sewer, capital-recovery). It distinguishes from sibling tools by mentioning that breakdown, comparison, and premium tools are separate, making the purpose very specific and unique.
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 explicitly tells when to use (development feasibility, pro-forma analysis), what inputs to provide (jurisdiction or address with examples), and how the output is used (the number needed for analysis). It also provides guidance on coverage levels (deep, partial, estimated) and directs to premium tools for more detailed breakdowns, effectively differentiating from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the FEE-BY-FEE breakdown behind a jurisdiction's development cost — every impact/development fee and water/sewer tap charge listed separately, each tagged with its calculation basis (per-dwelling / per-LUE / per-meter / per-trip) and whether it's a published schedule figure or a regional estimate, plus the full per-meter-size schedule where the city publishes one (5/8" → 12"). Fees are grouped (Water / Sewer / Transportation / Parks / Drainage) with the % each is of the total, and each jurisdiction carries its source URL + effective date so the figure is defensible in a pro-forma. Pass 'jurisdiction' or 'address', and optionally 'dev_type' (single_family / multifamily / commercial / retail / office / industrial; defaults to single_family). PREMIUM: pay per call with x402 (USDC on Base) or set a prepaid key (MUNI_DEV_COST_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | No | 'City, ST' or city name. Provide this OR address. | |
| address | No | US street address. Provide this OR jurisdiction. | |
| dev_type | No | Development type: single_family / multifamily / commercial / retail / office / industrial. Optional; defaults to single_family. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully discloses the tool's behavior: it returns a detailed fee breakdown grouped by category, with calculation basis, schedule vs. estimate indication, per-meter-size schedule, source URL, and effective date. It also mentions the premium payment method.
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 somewhat verbose but packed with necessary details. It lacks headings or bullet points but is still readable and front-loaded with the core purpose. Every sentence adds value.
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 has no output schema, yet the description comprehensively explains what is returned. Given the complexity of the data and the existence of siblings, the description is complete enough for an agent to understand the tool's capabilities and output.
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%, but the description adds significant value beyond the schema by clarifying that jurisdiction or address are mutually exclusive, explaining the dev_type default, and detailing the rich output structure. This goes beyond a simple rephrasing.
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 states the tool's purpose: 'Get the FEE-BY-FEE breakdown behind a jurisdiction's development cost.' It specifies the exact output components (each fee, calculation basis, grouped categories, source URL, effective date) and distinguishes itself from siblings by emphasizing the per-fee detail and defensibility.
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 explains when to use the tool: by providing a jurisdiction or address, and optionally a dev_type. It defaults to single_family. It does not explicitly contrast with sibling tools or state when not to use it, but the detailed output naturally guides appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the PUBLISHED fee-schedule SOURCE and per-fee provenance behind a jurisdiction's development cost — the exact document name + URL + effective date the figures were lifted from, which fee lines are published (from the city's own schedule) vs estimated (regional benchmark), with the basis of each, and the published-vs-estimated share. This is the trazabilidad that makes a number defensible in a real pro-forma / underwriting model. Pass 'jurisdiction' or 'address'. PREMIUM: pay per call with x402 (USDC on Base) or set a prepaid key (MUNI_DEV_COST_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | No | 'City, ST' or city name. Provide this OR address. | |
| address | No | US street address. Provide this OR jurisdiction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses return content: document name, URL, effective date, fee line status (published vs estimated), basis, and share. It also notes the premium cost model, providing complete behavioral insight.
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 detailed but each sentence contributes meaningful information, from core purpose to return details and payment. It could be slightly shorter, but it is well-structured and front-loaded.
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?
Given no output schema, the description fully explains the return value. Complexity is moderate, and the description covers purpose, input options, output details, and cost model, making it complete for an agent.
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 100% with clear descriptions for both parameters. The description adds value by clarifying mutual exclusivity ('Provide this OR address') and emphasizing that at least one must be provided, which is not explicit in 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?
The description clearly states the tool retrieves the published fee-schedule source, per-fee provenance, document details, and published vs. estimated shares. It distinguishes itself from sibling tools like 'get_dev_costs' or 'get_fee_breakdown' by focusing on traceability and defensibility.
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 specifies to pass 'jurisdiction' or 'address' and mentions premium payment methods. It implies usage when traceable source data is needed but does not explicitly state when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the GRAND TOTAL municipal development cost for a US jurisdiction across EVERY fee category we hold — not just water+sewer, but also transportation/street, parks, drainage/stormwater, fire, police and library impact fees where the city levies them. Returns one grand-total USD figure plus a roll-up by bucket (Water+Sewer / Transportation / Parks / Drainage / Public Safety / Other Public) and each category's share. This is the number a developer actually underwrites: in cities like Phoenix or Fresno the non-utility impact fees rival the water+sewer bill, so water-only numbers badly understate the cost to build. Honest about $0 buckets (a city that doesn't assess a parks/transport impact fee shows $0, meaning 'not assessed', not 'missing'). Pass 'jurisdiction' or 'address', optionally 'dev_type' and 'meter_size'. PREMIUM: pay per call with x402 (USDC on Base) or set a prepaid key (MUNI_DEV_COST_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | No | 'City, ST' or city name. Provide this OR address. | |
| address | No | US street address. Provide this OR jurisdiction. | |
| dev_type | No | Development type (default single_family). | |
| meter_size | No | Water meter size (default 5/8"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that $0 buckets mean 'not assessed', not missing. Mentions payment requirements. Does not cover all behavioral aspects but sufficient for a read-only query tool.
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?
Description is relatively long but every sentence provides useful information. Front-loaded with main purpose. Could be slightly more concise but overall efficient.
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, so description explains return value in detail: grand-total USD figure, roll-up by bucket, category shares. Covers parameters, usage context, and edge cases (zero buckets). Complete for a query 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 coverage is 100%, but description adds value by explaining jurisdiction/address are alternatives, dev_type and meter_size have defaults, and provides real-world examples. This clarifies parameter usage beyond 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?
Description clearly states it gets the grand total municipal development cost across all fee categories, with roll-up by bucket. Distinguishes from related tools like get_water_sewer_detail that only cover water/sewer fees.
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?
Indicates when to use (get total cost across all categories) and warns that water-only numbers understate cost. Mentions premium payment model. No explicit 'when not to use' but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the WATER & SEWER development cost for a jurisdiction broken down by meter size — impact/capacity fee vs physical tap/connection, with the full per-meter-size table (5/8", 3/4", 1", 1.5", 2"… up to 12") where the city publishes one. The right number for the ACTUAL meter a project needs: a 2" meter can be 8–12× the residential 5/8" fee, the single biggest swing in a utility connection budget. Pass 'jurisdiction' or 'address' and optionally 'meter_size' (default 5/8"). PREMIUM: pay per call with x402 (USDC on Base) or set a prepaid key (MUNI_DEV_COST_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | No | 'City, ST' or city name. Provide this OR address. | |
| address | No | US street address. Provide this OR jurisdiction. | |
| meter_size | No | Water meter size: '5/8"', '3/4"', '1"', '1.5"', '2"', '3"', '4"', '6"'. Optional; defaults to 5/8". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully compensates by disclosing it's a premium pay-per-call tool, payment methods, and the importance of meter size. It also mentions that it returns a full table where available. No contradictions.
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 concise but packed with useful information. It front-loads the main purpose and then adds details. Could be broken into shorter sentences for easier reading, but no waste.
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?
Given no output schema, the description adequately explains what is returned (full per-meter-size table broken down by fee type). It covers the key aspects, though the exact format is not specified.
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 100% with descriptions for all three parameters. The description adds value by explaining the significance of meter size and the default behavior, going beyond the schema's basic field descriptions.
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 states it gets water & sewer development cost broken down by meter size with specific fee types (impact/capacity vs physical tap/connection). It distinguishes from siblings by focusing on detailed per-meter-size tables and actual meter cost.
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 explains when to use (to get actual meter cost for a project) and provides context on default meter size and premium payment. It does not explicitly mention alternatives or when not to use, but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the FULL coverage map of muni-dev-cost — every US jurisdiction we cover, its depth (deep = the city's own per-meter schedule was ingested; partial = published headline figures) and the data freshness (source effective date) per jurisdiction, which jurisdictions publish a per-meter schedule, plus the benchmark states where any city returns an honest state estimate. The directory an agent needs to know WHAT it can ask for and HOW current the answer is — something it cannot assemble itself. Optionally filter by 'coverage' (deep / partial) or 'state' (2-letter). PREMIUM: pay per call with x402 (USDC on Base) or set a prepaid key (MUNI_DEV_COST_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| coverage | No | Filter: 'deep' or 'partial'. Optional. | |
| state | No | Filter by 2-letter state code (e.g. 'TX'). Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description covers pricing model (x402/prepaid key) and confirms it returns a read-only coverage map, though it could mention idempotency.
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 verbose, including pricing details that could be annotations, but front-loads the main purpose.
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?
Despite no output schema, the description fully explains return values: per-jurisdiction depth, data freshness, schedule availability, benchmark states.
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 100% and descriptions are clear; description adds plain-language explanation of optional filters (coverage, state) but no additional semantics beyond 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?
The description clearly states the tool lists the full coverage map of muni-dev-cost, including depth and freshness, distinguishing it from sibling tools like compare_jurisdictions or summarize_by_state.
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 describes the tool as a directory needed before asking for specific data, implying when to use, but does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank EVERY covered US jurisdiction cheapest-to-priciest on municipal development cost — the national site-selection leaderboard a developer wants when the question is 'where in the country is it cheapest (or most expensive) to build?'. Rank on water+sewer only or on the GRAND TOTAL across every fee category (water, sewer, transportation, parks, drainage, fire, police, library). Returns the full ranked list with each market's water+sewer vs other split, plus the cheapest / median / priciest, the dollar spread and what that spread costs on a 100-unit project. Filter by 'state' or 'coverage'. Only jurisdictions with the city's OWN published figures are ranked (state-benchmark estimates are excluded). This is computable only over the full normalized cross-jurisdiction dataset — exactly what an agent can't assemble itself. Optionally pass 'basis' ('total' default, or 'water_sewer'), 'dev_type', 'meter_size', 'state', 'coverage', 'limit'. PREMIUM: pay per call with x402 (USDC on Base) or set a prepaid key (MUNI_DEV_COST_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| basis | No | 'total' (grand total across all fee categories, default) or 'water_sewer' (water+sewer only). | |
| dev_type | No | Development type (default single_family). | |
| meter_size | No | Water meter size for per-meter-table jurisdictions (default 5/8"). | |
| state | No | Filter to a 2-letter state code (e.g. 'TX'). Optional. | |
| coverage | No | Filter: 'deep' or 'partial'. Optional. | |
| limit | No | Return only the top N rows. Optional (default: all). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that only jurisdictions with the city's own published figures are ranked (excluding state-benchmark estimates), and that it is computable only over the normalized dataset. It also mentions the premium payment model. No contradictions with annotations exist.
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 lengthy but front-loaded with the main purpose. Every sentence adds necessary detail, though some restructuring could improve readability. It efficiently conveys complex behavior without excess.
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, but the description covers what is returned: the full ranked list, cheapest/median/priciest, dollar spread, and cost on a 100-unit project. With 6 optional parameters fully described, the description is complete for practical use.
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 100% and each parameter has a description. The description adds value by explaining the 'basis' parameter ('total' vs 'water_sewer') and providing default values ('single_family', '5/8"', 'all'). It also clarifies filtering by 'state' and 'coverage' beyond what the schema says.
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 uses specific verbs ('rank... cheapest-to-priciest') and identifies the unique resource ('national site-selection leaderboard'). It clearly distinguishes this tool from siblings by focusing on the cross-jurisdiction ranking use case, which no other sibling tool addresses.
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 explicitly states when to use this tool: when the question is 'where in the country is it cheapest to build?' It also notes that it is only for jurisdictions with published figures and mentions premium payment. While it does not explicitly state when not to use or name alternative tools, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Roll the entire covered dataset up to the STATE tier: for every US state we hold real city schedules in, get the number of cities covered, the min / median / max municipal development cost across them, the cheapest and priciest city, and which fee categories the state's cities assess. Plus a national roll-up (cheapest / priciest city anywhere, national median). This is the state-level site-selection map a developer scans before drilling into cities — 'which states are cheap or expensive to build in, and how many of my candidate markets do you actually cover?'. Rank on water+sewer only or on the GRAND TOTAL across every fee category. Computable only over the full normalized cross-jurisdiction dataset, and it sharpens as coverage grows. Optionally pass 'basis' ('total' default, or 'water_sewer'), 'dev_type', 'meter_size'. PREMIUM: pay per call with x402 (USDC on Base) or set a prepaid key (MUNI_DEV_COST_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| basis | No | 'total' (grand total across all fee categories, default) or 'water_sewer' (water+sewer only). | |
| dev_type | No | Development type (default single_family). | |
| meter_size | No | Water meter size for per-meter-table jurisdictions (default 5/8"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the premium payment model and that results sharpen as coverage grows. Could explicitly state it's read-only, but overall transparent.
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 one long paragraph that front-loads the purpose but includes premium payment details which could be separate. It's adequately sized but slightly wordy for the information conveyed.
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?
Comprehensive in explaining outputs (number of cities, costs, fee categories) and use case. No output schema, but description fully covers what user gets. Good given many sibling tools.
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 100%, baseline 3. Description adds meaning by defining default values for basis, dev_type, meter_size and explaining options like 'total' vs 'water_sewer'. This goes beyond 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?
The description clearly states it rolls up the dataset to the STATE tier and lists specific outputs (cities covered, costs, fee categories). It distinguishes from siblings like rank_jurisdictions_by_cost which operate at jurisdiction level.
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 explains this is for high-level state site-selection before drilling into cities, and that it works on the full dataset. It doesn't explicitly list when not to use but provides clear context.
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. Dates show when Glama detected each change.
v0.18.1breakdown_by_fee_categorycompare_by_meter_sizecompare_jurisdictionsestimate_by_unitsestimate_dev_costget_cost_trendget_dev_costsget_fee_breakdownget_fee_schedule_sourceget_total_dev_costget_water_sewer_detaillist_jurisdictionsrank_jurisdictions_by_costsummarize_by_stateEach tool targets a distinct aspect of municipal development cost data: basic cost, fee breakdown, water/sewer detail, comparisons, rankings, estimates, trends, and coverage listing. No two tools have overlapping purposes; even similar tools like get_dev_costs and get_total_dev_cost are clearly differentiated by scope (single-family vs grand total across categories).
All tool names follow a consistent verb_noun pattern in snake_case, e.g., get_dev_costs, compare_jurisdictions, list_jurisdictions, rank_jurisdictions_by_cost. Variants like breakdown_by_fee_category and estimate_by_units maintain the pattern with 'by_' prepositions. No mixing of styles or vague verbs.
With 14 tools, the set is well-scoped for a municipal development cost data service. It covers basic queries, detailed breakdowns, comparisons, rankings, estimates, trends, and coverage metadata—each tool earns its place without being overwhelming or too sparse.
The tool surface comprehensively covers the domain: basic single-family cost (get_dev_costs), total cost across all fee categories (get_total_dev_cost), fee-by-fee breakdown (get_fee_breakdown), water/sewer detail per meter size (get_water_sewer_detail), category-specific breakdown (breakdown_by_fee_category), multi-jurisdiction comparison (compare_jurisdictions), national ranking (rank_jurisdictions_by_cost), state-level summary (summarize_by_state), cost trends (get_cost_trend), fee schedule provenance (get_fee_schedule_source), project estimates (estimate_dev_cost, estimate_by_units), and coverage listing (list_jurisdictions). No obvious gaps exist for a read-only query service.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real estate data for AI agents: US parcel boundaries (tiles), owners, sale history, permits, hail.
Zoning, ADU eligibility, flood zone, setbacks, and buildability intelligence for U.S. parcels.
Current US rental market data for AI agents: 1,500+ submarkets, monthly rent + vacancy + trends.
US municipal zoning intelligence — corridor analysis, place dossiers, named-pattern detection.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Baneado98/muni-dev-cost'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
