muni-dev-cost

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.18.1
Disambiguation5/5
Each 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).
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.3/5 across 14 of 14 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![muni-dev-cost MCP server](https://glama.ai/mcp/servers/Baneado98/muni-dev-cost/badges/card.svg)](https://glama.ai/mcp/servers/Baneado98/muni-dev-cost)

Score Badge

Copy to your README.md:

[![muni-dev-cost MCP server](https://glama.ai/mcp/servers/Baneado98/muni-dev-cost/badges/score.svg)](https://glama.ai/mcp/servers/Baneado98/muni-dev-cost)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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