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 does disclose that the tool is a read-only check and implies a yes/no result, but it doesn't describe the response format, error behavior, or limitations (e.g., locations outside mapped areas).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no waste. The first sentence states the core purpose, and the second adds practical usage guidance. Information is front-loaded and every sentence earns its place.

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 two-parameter tool with fully described inputs, the description is largely complete: it explains what it checks, when to run it, and what the result conveys. It doesn't specify the exact return format, but 'tells you whether' sufficiently implies a boolean or coverage-status response.

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 schema already documents both parameters. The description only refers to 'a given location' and adds no further parameter-level detail, matching the baseline for full schema coverage.

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 verb ('Check whether'), a specific resource (FEMA National Flood Hazard Layer), and a clear outcome (has official flood map coverage). It positions the tool as a preliminary coverage check, setting it apart from sibling data-retrieval 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?

Provides explicit when-to-use guidance: 'Run this first if other tools return no data.' This is a clear condition and sequencing hint. It doesn't name sibling tools explicitly, but 'other tools' is understandable in the context of the sibling list.

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 carries the full burden of behavioral disclosure. It discloses the spatial search radius (~100m), the unit/meaning of results (feet above datum, 1% annual chance flood), and an important limitation (BFEs absent in some zones). It does not describe return format or error behavior, but the key operational constraints are clearly surfaced.

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?

Four concise sentences, each contributing essential information: what the tool returns, what BFE means, why it matters, and critical caveats. The description is front-loaded with the main purpose and avoids redundant or filler wording.

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 two-parameter geographic lookup, the description covers the tool's purpose, meaning, relevance, search radius, and a key limitation. There is no output schema, so a bit more detail about the exact structure of the returned features could be helpful, but the description is sufficiently complete for an agent to select and invoke the tool correctly.

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 lat/lon parameters are already documented in detail. The description adds the behavioral context that the search happens within ~100m of the coordinate, but does not add much new semantic meaning beyond what the schema provides. Baseline 3 is appropriate.

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 verb and resource ("Get Base Flood Elevation (BFE) lines near a location from the NFHL") and explains the meaning of BFE. This clearly differentiates it from sibling tools like get_flood_zone and get_firm_panel, which target different NFHL data. An agent can understand exactly what this tool returns without opening the schema.

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 clear context for when to use the tool: it is relevant to construction requirements and insurance rating, searches within ~100m of the coordinate, and notes that BFEs are not present in all flood zones. It does not explicitly list alternative tools or say 'use X instead', but the context is strong enough for an agent to infer appropriate usage relative to the siblings.

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 full burden and does disclose the main behavior and return content: panel number, suffix, effective date, and panel type. However, it does not mention potential edge cases such as unmapped locations, coordinate precision requirements, or what happens when no FIRM panel exists for the location.

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 two sentences with no filler: the first states what the tool returns, the second states its purpose. Every sentence adds value and the core purpose is front-loaded.

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

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

For a simple two-parameter lookup with no output schema, the description adequately explains return values and intended use. It could be slightly more complete by noting behavior for locations without a mapped FIRM panel, but overall the agent has enough information to call the tool correctly.

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

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

The schema already provides 100% coverage with clear descriptions for both lat and lon, including WGS84 and valid ranges. The description adds no parameter-specific meaning beyond describing a 'location,' so the baseline of 3 is appropriate.

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 verb ('Get'), a specific resource ('FEMA FIRM panel number and metadata'), and the exact items returned (panel number, suffix, effective date, panel type). This clearly distinguishes it from siblings like get_flood_zone or get_lomas, which target different flood-related data.

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 to use the tool 'to identify which flood map covers a location and when it was last updated,' giving clear context for when to invoke it. It does not explicitly name alternatives or provide when-not-to-use conditions, but the use case is specific enough to guide an agent.

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 carries the full burden of behavioral disclosure. It signals a read-only lookup through the verb 'Look up' and enumerates the returned fields (zone code, SFHA, floodway, BFE, FIRM panel citation). It does not mention edge behaviors like coordinates outside NFHL coverage or error handling, but the core operation and outputs are clearly disclosed.

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 two tight sentences with no wasted words. The first sentence announces the action and resource, the second lists outputs and positions the tool; everything earns its place.

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 input schema fully documents the only two parameters, and the description lists the key return fields, which is essential since there is no output schema. It also positions the tool as the primary flood-risk lookup. The main gap is the absence of guidance on coverage limitations or failure behavior, but the tool is simple enough that this is not a critical omission.

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 lat and lon are already documented with ranges and WGS84 decimal-degree units. The description only references 'lat/lon coordinate' generically and adds no further semantic detail, which meets the baseline but does not exceed it.

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 operation — 'Look up the FEMA flood zone designation for a lat/lon coordinate' — and identifies the authoritative source (NFHL). It also lists concrete return values, making the tool's purpose very clear. However, it does not explicitly contrast itself with sibling tools like get_base_flood_elevations or get_firm_panel, despite overlapping return fields.

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?

'This is the primary tool for flood risk lookup' provides clear context for when to select this tool. It does not explicitly state when to avoid it or route to alternatives, so the guidance is strong but not fully comprehensive.

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 carries the full behavioral burden. It discloses the ~100m search radius and location-based search behavior, which is valuable. But it does not mention response shape, result limits, ordering, or what happens when no LOMAs are found.

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?

Three sentences with no waste: action, domain definition, and search radius. The LOMA definition earns its place by helping differentiate from LOMRs without adding bloat.

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

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

The tool is simple and invocation is clear, but there is no output schema and no annotations. The description should ideally state what a successful response contains or how results are ordered/limited; the missing return-value expectations leave the agent partly guessing.

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 lat and lon and their ranges, so the schema already handles parameter meaning. The description adds the ~100m radius context, which clarifies the 'near a location' phrasing, but does not add format or syntax details 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?

States a specific verb and resource: 'Get Letters of Map Amendment (LOMAs) near a location.' It defines a LOMA in a way that inherently distinguishes it from the sibling get_lomrs (a LOMA does not revise the FIRM), so an agent can tell them apart without opening extra context.

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?

Gives clear context for when to use the tool: searching for LOMAs near a coordinate within ~100m. However, it does not explicitly name alternatives or state when not to use it, leaving the distinction from get_lomrs and other flood-related siblings implicit rather than direct.

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 of behavioral disclosure. It states the return fields (case number, project name, effective date, status) and explains what LOMRs are, but it does not explicitly state that the operation is read-only or mention any limits, permissions, or edge-case behavior.

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-loaded with the core action. The second sentence clarifies the LOMR concept and the third lists the return values; every sentence earns its place with no wasted words.

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

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

For a simple two-parameter lookup with no output schema, the description covers purpose, input concept, and return fields. It misses guidance on distinguishing LOMRs from LOMAs or any result limits, but it is otherwise reasonably 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?

The input schema already documents lat/lon with descriptions and 100% coverage, so the description does not need to repeat them. It only refers generically to 'a location' and adds no parameter-specific meaning, placing it at the baseline of 3.

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 opens with a clear verb and resource ('Get Letters of Map Revision (LOMRs) that affect a location') and adds useful context about what LOMRs are and their effect on flood zone designations. However, it does not explicitly contrast this tool with its sibling get_lomas, so it earns a 4 rather than a 5.

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 use whenever LOMRs for a location are needed and explains their significance, but it provides no explicit when-not-to-use guidance or reference to alternatives such as get_lomas. The choice of when to use this tool versus related siblings is left to inference.

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