How often does this ZIP flood? FEMA NFIP flood-insurance claim history.
Scored across 3 tools
flood_history and flood_report both return single-ZIP NFIP claim data and could be confused at a glance, but the descriptions clearly separate a summary (totals + risk signal) from a detailed report ($ by year, zones, events). compare_zips is clearly distinct as a multi-ZIP comparison tool.
All three names use snake_case with a consistent subject-oriented style (flood_*, compare_*), which is predictable and readable. Minor deviation: compare_zips leads with a verb while the others lead with the domain noun, but the intent is still clear.
Three tools is thin but well-matched to a narrow read-only lookup domain; each covers a distinct granularity (single ZIP summary, single ZIP detail, multi-ZIP comparison). No tool feels redundant or out of scope.
Core retrieval is covered for a read-only dataset, but there are notable gaps: no ZIP validation/geocoding or lookup by address/county, and no way to get a free-tier detail view or aggregate statistics across a region. Agents can work around these only by chaining single-ZIP calls.
PRO. Compare flood-claim history across up to 10 ZIPs (house hunting, portfolio and lending risk).
| Name | Required | Description | Default |
|---|---|---|---|
| zips | Yes | ||
| access_token | No | Subscriber token from /success (or Authorization: Bearer) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It usefully reveals the PRO/subscriber gating and the 10-ZIP ceiling, but says nothing about the cost of exceeding the limit, auth failure behavior, or what a comparison result looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the access tier front-loaded and the scope limit immediately after the resource. Nothing is wasted, though the terse 'PRO.' fragment assumes the reader knows what that means.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no annotations and no output schema, the description covers purpose, tier, and input limit, but leaves return-value shape and over-limit behavior entirely unexplained — gaps that the absent structured metadata cannot fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only access_token is documented). The description compensates by disclosing the meaningful constraint on zips — a maximum of 10 — which the schema does not encode, but it adds no format details (e.g., leading zeros, 5-digit requirement) for the array items.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Compare) and resource (flood-claim history) plus a hard scope limit of up to 10 ZIPs, which implicitly distinguishes it from the single-location sibling flood_history. It does not explicitly name flood_history or flood_report as alternatives, so sibling differentiation is inferred rather than stated.
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 parenthetical use cases (house hunting, portfolio and lending risk) give context for when the tool is appropriate, and the 'up to 10 ZIPs' framing implies single-ZIP lookups belong elsewhere. However, no explicit when-not guidance or pointer to flood_history/flood_report is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. Insured flood-claim history for a US ZIP code (FEMA NFIP): total claims, claims in the last 10 years and a risk signal.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but does disclose useful traits: the lookup is free, the source is FEMA NFIP, and the output is scoped to insured claims. It does not mention coverage limits of NFIP data, behavior for invalid/non-US ZIPs, rate limits, or whether the 'risk signal' is derived or raw.
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?
One sentence, front-loaded with the 'FREE' cost signal and then the resource, source, and return contents. No filler and nothing an agent must scroll past.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup with no output schema, the description adequately explains what comes back and where the data originates. It falls slightly short on input edge cases and on how the 'risk signal' should be interpreted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'zip' parameter, so the description must compensate. It adds real meaning by specifying a US ZIP code, but gives no format detail (5-digit vs ZIP+4) or error expectations for malformed input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (insured flood-claim history), the scope (a US ZIP code), the data source (FEMA NFIP), and the returned fields (total claims, 10-year claims, risk signal). It does not differentiate itself from siblings compare_zips or flood_report, so an agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no mention of the sibling tools flood_report or compare_zips, which are the obvious alternatives for related flood questions. The 'FREE' marker hints at a cost consideration but is not a routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PRO. Full NFIP claims report for a ZIP: $ paid by year, average claim, flood zones, named flood events.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | ||
| access_token | No | Subscriber token from /success (or Authorization: Bearer) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It adds useful context by listing report contents and signaling a paid/subscriber ('PRO') tier, but it does not explicitly state read-only behavior, authentication requirements beyond the vague 'PRO' label, rate limits, or output format.
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 compact and front-loads the core purpose after the 'PRO.' marker. It contains little waste, though the isolated 'PRO.' token is ambiguous and slightly reduces 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?
For a report tool with no output schema and no annotations, the description gives a helpful list of return contents. However, it leaves out important context such as subscriber/authentication requirements, behavior relative to sibling tools, and response 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 description coverage is 50%: the access_token parameter is documented in the schema, while zip is undocumented there. The description reinforces that the report is for a ZIP, but it adds no syntax, format, or validation details for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and scope: a full NFIP claims report for a ZIP, including paid amounts by year, average claim, flood zones, and named events. It is clear what the tool does, but it does not differentiate itself from siblings like flood_history or compare_zips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool instead of flood_history or compare_zips, nor when not to use it. The only implied usage is that it applies to a single ZIP, while 'PRO' hints at subscriber access but does not explain prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_zipsflood_historyflood_reportFEMA flood zone, hazard history and demographics for any US address, with sources on every answer.
US ZIP code intelligence: demographics, weather, tax, crime, housing, voting, and more.
US rental market data by zip: rent, cap rates, vacancy, hazard risk, rent trends. Free, no auth.
FEMA NFIP flood claims by state and county, damage by water depth, county profiles. Read-only.
Add one secure layer between your agents and this server.
