muni-dev-cost

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral transparency burden. It explains that the tool returns fee lines including a per-meter-size schedule if available, and it discloses the premium payment model (pay per call with x402 or prepaid key). It does not explicitly state read-only status or error handling, but for a data retrieval tool, the core behavior is adequately conveyed.

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—three sentences that front-load the purpose and examples. Every sentence adds essential information: what it retrieves, why you'd use it, how to call it, and payment details. There is no redundancy or fluff.

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 tool has no output schema, the description covers the main return structure (fee lines per category with optional per-meter schedule). It addresses the primary use case. It lacks details on edge cases (e.g., missing category, no data) but is sufficient for a simple query tool within a well-understood domain.

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 value by explaining the mutual exclusivity of 'jurisdiction' and 'address' ('Provide this OR jurisdiction'), and by listing all allowed categories. This clarifies parameter relationships beyond the schema's individual descriptions, earning a 4.

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: retrieving fee lines for a single named category within a US jurisdiction. It provides concrete examples (parks, transportation, etc.) and distinguishes itself from the sibling get_fee_breakdown by emphasizing one-category granularity. The verb 'get' plus specific resource ('fee line'), scope ('ONE named category'), and context ('US jurisdiction') make it highly precise.

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 the tool: 'Lets your agent pull exactly the cost component it needs ... without parsing the whole breakdown.' It instructs to pass 'jurisdiction' or 'address' and a 'category'. While it implicitly contrasts with the full breakdown tool, it does not name alternatives or provide explicit when-not-to-use scenarios. This is a minor gap, but the guidance is otherwise clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description bears full responsibility. It discloses premium payment requirements (USDC or prepaid key) and data source constraints (only works for jurisdictions with per-meter schedules). It does not describe response format or limits but provides useful behavioral context.

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 moderately lengthy but every sentence adds value: purpose, use case, parameter guidance, limitation, and payment info. It is front-loaded with the primary action and could be slightly more streamlined, but no unnecessary content.

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 or annotations, the description adequately covers purpose, usage, parameters, source limitations, and monetization. It provides enough context for an AI agent to invoke correctly, including the output structure implicitly.

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 value by explaining the output includes all meter sizes with ratios, the default category, and that either address or jurisdiction is required. This enhances the schema's meaning.

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 development costs for all meter sizes for a jurisdiction, including ratios to the 5/8" base. This verb+resource is specific and distinguishes it from siblings like 'breakdown_by_fee_category' 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 provides explicit context on when to use: to see the cost curve for meter sizing. It explains parameters (jurisdiction or address, optional category) and notes the limitation to jurisdictions with per-meter schedules. While it does not explicitly mention when not to use, the use case is clearly conveyed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses return structure (total per market with water/sewer split, spread, percentage gap, cost on 100-unit project) and notes premium payment (x402 or prepaid key). No destructive actions implied. Lacks details on authentication or idempotency but sufficient.

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?

Very concise: two main sentences plus a brief premium note. Every sentence adds unique value (purpose, return details, usage hint). No redundant phrases. Well-structured for quick understanding.

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 the return data components. It mentions the number of jurisdictions (implicitly multiple) but does not explicitly repeat the 2-12 limit from schema. The premium note is relevant. Could include a note about which jurisdictions are supported (US only) but overall complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds value by providing an example array format for jurisdictions and mentions the dev_type default (single_family) which is also in schema. The example helps clarify the parameter usage, though it does not go beyond schema significantly.

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 verb (compare, ranked), resource (municipal development cost of US jurisdictions), and context (site-selection for developers). It distinguishes itself from siblings like rank_jurisdictions_by_cost or compare_by_meter_size by specifying side-by-side comparison with ranking and detailed split metrics.

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?

Provides context: the tool answers the site-selection question before buying land. It mentions premium pricing and payment method but does not explicitly state when to use versus alternatives like ranking or single jurisdiction tools. A small addition about when not to use would clarify.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 returns per-unit and extended line items, allows LUE factor override, and mentions payment method (x402 or prepaid key) and exclusions (land, construction, financing). This is sufficient behavioral context.

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 moderately lengthy but front-loaded with the core purpose. Every sentence adds value. It could be slightly tighter, but overall it's well-structured and informative.

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 return (line items) and covers exclusions, payment, and parameter combinations. It is fairly complete for a tool with 6 parameters and a specific methodology, though it could include more return format details.

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?

Although schema coverage is 100%, the description adds significant meaning: it explains the LUE factor's role, clarifies that jurisdiction or address are alternatives, and specifies defaults for dev_type and lue_per_unit. This goes 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 total municipal fees for multifamily/mixed-use projects using LUE. It distinguishes itself from a flat per-unit estimate and from sibling tools like estimate_dev_cost by specifying the LUE methodology and project type.

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 tells the user to pass 'jurisdiction' or 'address', 'units', and optional parameters like 'dev_type' and 'lue_per_unit'. It explains the default dev_type and that the tool uses LUE, implying when to use it. However, it does not explicitly contrast with sibling tools or provide 'when not to use' guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, but the description implies a read-only, non-destructive operation ('estimate'), and mentions payment requirements (premium). It does not disclose rate limits, error handling, or authentication details beyond payment.

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 and front-loaded with purpose and exclusions. The inclusion of payment details is slightly tangential but not overly lengthy. Every sentence serves a distinct 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?

Given no output schema, the description hints at the return format ('per-unit and extended line items'). It covers required and optional parameters, exclusions, and the overall logic. Missing details like return type or error cases, but sufficient for basic usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning beyond schema by explaining the formula (fees × units), the purpose (pro-forma sizing), and the relationship between parameters (address or jurisdiction). Schema coverage is 100%, so baseline is 3, but the contextual explanation merits an extra point.

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 estimates municipal fees for a development project and explicitly excludes total project cost components. However, it does not differentiate from siblings like get_total_dev_cost or get_fee_breakdown, which could cause confusion.

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 guidance on when to use the tool (for municipal fee estimation) and what is excluded (total project cost), but it lacks explicit alternatives or when-not-to-use scenarios relative to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations so description carries full burden. Discloses behavioral traits: returns only official schedules, not projections; only for cities with multiple schedules; payment model (USDC or prepaid key). Missing are details on idempotency and side effects, but read-only 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?

Front-loaded with core action, then explains what it is not, then value, then parameters, then billing. Every sentence adds value, but slightly lengthy. 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?

Covers input constraints (multiple schedules required), output contents (delta, CAGR), and use case. No output schema, but return format is sufficiently described. Missing any mention of error cases or pagination, which is acceptable for a single-call 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?

Parameters are in schema with 100% coverage. Description adds 'pass jurisdiction or address' but little beyond schema's own descriptions. No format or constraints added beyond what schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'get' and resource 'dated revision history of jurisdiction's headline development fee' with specifics (prior years, adopted future steps, delta, CAGR). Distinguishes from siblings by emphasizing it's about historical trends, not projections or single-point 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?

Explicitly mentions when to use (to budget fee line at future permit pull date) and what input to provide (jurisdiction or address). Does not explicitly name alternative tools but implies not for single-point fees. Could stronger differentiate from siblings like 'get_dev_costs'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the behavioral transparency burden. It discloses that fees are aggregated from public schedules, normalized, and provides an honest coverage classification (deep/partial/estimated). It also states the result is indicative and should be verified with the jurisdiction. No contradictions 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 detailed and structured with bolded terms and clear sections. While it is longer than some, every sentence adds value given the complexity of the tool. The front-loading of the core purpose followed by details and alternatives is 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 the tool's complexity and lack of output schema, the description adequately explains the return values (aggregated figure, split, line summary) and coverage types. It covers input, output, and limitations (indicative). Minor gaps like error handling are acceptable for this level of detail.

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%, providing a baseline of 3. The description adds value by explaining that 'address' extracts city+state and that either parameter can be provided, reinforcing the schema's descriptions. This additional context justifies a score of 4.

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 a standard single-family home in a US jurisdiction, specifying what fees are included and what is returned (aggregate, split, summary). It distinguishes from sibling tools like 'get_fee_breakdown' and 'get_total_dev_cost' by noting that breakdown details and comparisons are in premium tools.

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 says when to use this tool (development feasibility analysis) and provides clear alternatives: 'For the fee-by-fee breakdown, per-meter water/sewer schedule, multi-jurisdiction comparison or a whole-project estimate, use the premium tools.' It also explains how to provide input (jurisdiction or address) and notes that the tool is free and indicative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description discloses that this is a premium paid tool (via USDC or prepaid key) and outlines the output structure (grouped fees with percentages and source details). It does not mention rate limits or error conditions, but for a read-only tool, the behavioral transparency is above average.

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 long but well-structured, front-loading key output features then covering parameters and payment. Every sentence contributes meaningful information, though a slight reduction in wordiness could improve conciseness without loss of clarity.

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 thoroughly explains the return value: fees listed separately with calculation basis, grouping, source URL, effective date, and per-meter schedules. This provides sufficient context for an agent to use the tool effectively. It could mention error handling, but overall it's complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters are described in the schema with 100% coverage. The description adds valuable semantics: explaining that 'jurisdiction' and 'address' are mutually exclusive, that 'dev_type' defaults to 'single_family', and the meaning of these inputs in the context of development fees.

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 function: retrieving a detailed fee-by-fee breakdown for a jurisdiction's development costs, including calculation basis, grouping, and source URL. It distinguishes itself from siblings by specifying its granularity and unique features like per-meter schedules and percentage groupings.

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 implies usage for detailed breakdowns but does not explicitly state when to use alternatives like get_total_dev_cost or list_jurisdictions. It provides good context on required input (jurisdiction or address) and optional dev_type, but lacks explicit when-not or alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It details what the tool returns (document name, URL, effective date, fee lines, published vs. estimated share, basis). It implies a read-only, data retrieval operation without side effects. However, it does not disclose potential errors, rate limits, or authentication requirements beyond the payment model.

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 relatively concise given the detail needed to explain the unique value. It front-loads the key action ('Get the PUBLISHED fee-schedule SOURCE') and uses formatting for emphasis. However, the last sentence about premium payment could be moved to a separate section.

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 description thoroughly covers what the tool returns (document name, URL, effective date, fee lines, published vs. estimated share, basis) and its use case (trazabilidad for pro-forma/underwriting). Given no output schema, this compensates well. However, it lacks examples of the return structure or error handling.

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% for both parameters (address, jurisdiction), with clear descriptions. The description adds minimal value by reiterating the mutual exclusivity ('Pass 'jurisdiction' or 'address''). It provides no additional formatting or examples beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the published fee-schedule source and per-fee provenance for a jurisdiction's development cost, including exact document name, URL, effective date, and published vs. estimated fee lines. This distinguishes it from sibling tools like estimate_dev_cost or get_fee_breakdown, which focus on calculations or summaries rather than source tracking.

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 instructs to pass 'jurisdiction' or 'address' and provides example formats. It also mentions the premium payment model (x402 or prepaid key). However, it does not specify when to use this tool over alternatives like get_dev_costs or rank_jurisdictions_by_cost, missing explicit guidance on exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the full behavioral burden. It discloses that $0 buckets mean 'not assessed' rather than missing, explains the output includes grand total, roll-up by bucket, and category shares, and provides real-world context (Phoenix, Fresno). It does not, however, specify whether the tool is read-only or has any side effects.

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 lengthy but well-structured. It front-loads the core purpose and then provides important context about why this tool is valuable. All sentences contribute useful information, though some trimming could be done without losing meaning.

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 that there is no output schema, the description adequately explains what the tool returns: a grand total, a roll-up by bucket, and each category's share. It also covers edge cases ($0 buckets) and explains the need for the tool over simpler alternatives. Considering the complexity of the tool, it provides sufficient context for an AI 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%, so the baseline is 3. The description adds minimal extra parameter semantics beyond the schema, clarifying that jurisdiction or address must be provided (one of the two) and that dev_type and meter_size are optional. It does not provide additional constraints or examples for parameter values.

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 grand total municipal development cost across all fee categories, not just water and sewer. It provides specific examples (transportation, parks, etc.) and distinguishes from other tools by emphasizing the comprehensive nature.

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 this tool (to get the full development cost, not just water/sewer), and specifies that jurisdiction or address is required while dev_type and meter_size are optional. It also mentions the premium cost and payment methods, though it doesn't explicitly name alternative tools for specific subsets.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses the premium cost model (pay per call with USDC or prepaid key) and default parameter behavior. It does not mention rate limits or idempotency, but the cost disclosure is valuable for an agent.

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 concise with three sentences, front-loading the main purpose. The business justification sentence adds context without being overly verbose.

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 absence of an output schema, the description explains the return structure well (table with per-meter-size breakdown of impact vs tap fees). It also provides usage context and pricing. Could be slightly more complete on return format details.

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 the description adds value by listing extended meter sizes up to 12", clarifying the address/jurisdiction mutual exclusivity, and emphasizing the default meter_size. This goes beyond the schema's enum values.

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 specifies the tool retrieves water & sewer development cost broken down by meter size, including fee categories. It distinguishes from sibling tools by focusing on water/sewer detail with meter size granularity, and emphasizes the practical value for projects.

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 input options (jurisdiction or address, optional meter_size) and mentions default meter size. However, it does not explicitly state when not to use this tool compared to siblings like get_total_dev_cost or breakdown_by_fee_category.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the behavior comprehensively: listing full coverage map, depth, freshness, and benchmark states. It also mentions the premium payment model. No annotations exist, so the description carries the full burden, and it does so without omissions or 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 informative but somewhat verbose, including marketing language about premium payment. It is front-loaded with the main purpose and structured logically, but could be more concise.

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 absence of an output schema, the description adequately explains the outputs (depth, freshness) and the optional filters. It covers the essential information needed to use the tool, though a slight lack of detail on the exact output format prevents a perfect score.

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 both parameters already provided. The tool description repeats the filter options without adding new meaning beyond what the schema provides, so the description does not significantly enhance parameter understanding.

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, specifying what is listed (depth, freshness, benchmark states) and that it is a directory an agent needs to know what it can ask for. It distinguishes itself from sibling tools focused on cost estimation or fee 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 explains when to use this tool (to know what jurisdictions are covered and data freshness) and mentions optional filters. It does not explicitly exclude alternatives or provide when-not guidance, but the context of sibling tools makes the use case clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description fully bears the burden. It discloses that the computation requires the full normalized dataset (agent cannot assemble itself), that state-benchmark estimates are excluded, and that the tool is premium (pay per call with x402 or prepaid key). These are critical behavioral traits beyond what is in the schema.

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 purpose and key output. However, it is verbose and repeats some information (e.g., basis options mentioned twice). At ~200 words, it could be more concise without losing clarity. The structure is logical: purpose, output description, filtering, payment note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must explain return values. It does so comprehensively: '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.' For a premium tool with 0 required parameters and no output schema, this is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description restates the parameters but adds minimal semantic value beyond the schema. It provides context for the basis parameter ('water+sewer only or GRAND TOTAL'), which is already in the schema. No additional limitations, defaults (beyond schema), or parameter interactions are explained.

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 EVERY covered US jurisdiction cheapest-to-priciest on municipal development cost') and clearly distinguishes the tool from siblings like compare_jurisdictions or estimate_dev_cost by focusing on a national leaderboard. It explicitly states the output includes a full ranked list with splits and summary statistics.

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 the use case: 'when the question is where in the country is it cheapest (or most expensive) to build?' It also provides filtering guidance (state, coverage) and notes that only jurisdictions with own published figures are ranked. However, it does not explicitly mention when not to use this tool or list alternatives, though the sibling context implies alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully discloses computational nature ('computable only over the full normalized cross-jurisdiction dataset'), behavior ('sharpens as coverage grows'), and payment requirements ('pay per call with x402 or set a prepaid key'). 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 verbose with marketing language ('PREMIUM...') and could be more concise. Although it front-loads the main purpose, the extra details extend it unnecessarily.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

It provides comprehensive details about output components (national roll-up, fee categories) and computational constraints, compensating for the lack of output schema. However, a bit more on the return format would be ideal.

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 schema descriptions are adequate, but the description adds context by explaining the default values and the meaning of 'basis' options ('total' vs 'water_sewer'), going beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies a clear action: 'roll the entire covered dataset up to the STATE tier' and lists precise outputs (number of cities, min/median/max cost, cheapest/priciest city, fee categories). It distinguishes from siblings by focusing on state-level aggregation rather than city-level or fee breakdown tools.

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 clearly states this is for 'state-level site-selection map a developer scans before drilling into cities' and provides optional parameters. However, it does not explicitly exclude alternative tools or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.