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

No annotations are provided, so the description carries the burden. The word 'Return' implies a read-only, side-effect-free operation, and the description explicitly frames it as a preparatory step. It does not mention potential complications, but the simplicity and clarity suffice.

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 concise sentences deliver the purpose and usage without redundancy. Every word adds value, and the structure front-loads the core function.

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

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

With a single parameter and no output schema, the description fully covers what the tool does (returns schema/docs), when to use it (before running another tool), and why (correct input shaping). No critical information is missing for an agent to use it 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 coverage is 100% with a parameter description and example. The description adds context about the catalog size (114 tools), clarifying that 'tool' must be one of these, which is beyond the schema. This enriches the parameter'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 returns the full input schema and documentation for any catalog tool, using a specific verb ('Return') and resource ('any one of the 114 tools'). It distinguishes itself from siblings like run_gov_data_tool and search_gov_data_tools by its meta-informational role.

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 guidance to call this tool before run_gov_data_tool to shape input correctly, giving a clear when-to-use context. However, it does not mention when not to use it or alternative tools like search_gov_data_tools, so it lacks full 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?

With no annotations provided, the description carries the full burden and does so admirably. It discloses billing behavior ('one billable row per nearby EPA-listed site'), failure modes ('If EVERY asset fails the run FAILS and nothing is billed'), data limitations (AUL boundary caveat), and the non-substitute disclaimer for ASTM E1527-21. It also explains how 'astmMode' widens fetches and affects rows.

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

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

The description is lengthy but well-structured and front-loaded. It opens with a clear purpose, then explains modes, then parameter details. Every sentence adds value, including caveats and examples. While not terse, the length is justified by the tool's complexity (12 parameters, two modes). It avoids redundancy with the schema by adding context rather than repeating definitions.

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 (12 parameters, no output schema, no annotations), the description is remarkably complete. It explains both operational modes, output row structures, billing implications, error conditions, data limitations, and default behaviors. It even offers concrete examples in the 'assets' parameter. Everything an agent needs to decide when and how to invoke the tool is present.

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 enriches all 12 parameters beyond the schema. It explains the 'mode' values in detail, distinguishes between address and lat/lon 'assets' formats, details 'programs' defaults and opt-ins, maps 'radiusMiles' to ASTM distances, and provides real-world data completeness stats for 'onlyWithCoords'. This adds significant meaning beyond the schema's own descriptions.

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

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

The description clearly states the tool's purpose: 'Phase I ESA & Environmental Due Diligence: EPA Database Search.' It specifies the resource (EPA contaminated-site databases) and the action (screening locations against them). It distinguishes from siblings by its focus on contaminated-site due diligence and mentions both modes (assets and inventory), which clarifies scope.

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 strong usage context: it says 'Environmental due diligence by address' and explains the two modes ('assets' for screening, 'inventory' for listing sites). It doesn't explicitly name alternatives, but the purpose is so distinct that siblings (e.g., water quality, wetlands) are clearly excluded. It also gives guidance like 'No API key' and 'Reads live from the official government source.' Lacking explicit 'do not use when...' statements, but the context is sufficient.

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 several critical behaviors: it never clears a source that did not answer, reads live from official government sources, describes caching and refresh behavior, and explains the retry budget and failure handling via simulateOutage. This is strong transparency given no annotations are provided.

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 and repetitive, repeating phrases like 'Never clears a source that did not answer' and including extensive legal context. It is structured as a single dense paragraph, which hampers quick scanning and comprehension.

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 provides rich context on purpose, data sources, regulatory deadlines, and failure modes, but it omits any description of the output format or structure. Given no output schema, this is a minor gap; the parameter descriptions fill most of the context need.

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 12 parameters have detailed descriptions with examples, edge cases (e.g., violationYears window, refreshPfasCache behavior, simulateOutage diagnostic), and explicit defaults, making semantics exceptionally clear 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 defines the tool's function as screening US coordinates for drinking water quality data, including SDWA violations, lead results, and PFAS detections, and distinguishes it from other environmental screeners by naming the specific data sources and regulatory 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?

The description implies usage for drinking water regulatory compliance checks (e.g., LCRI and PFAS deadlines) but does not explicitly compare to alternative tools; however, the specificity of the purpose is high enough to guide selection among sibling screeners.

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 discloses key behavioral traits: 'Verdict is gated - it never reads clear when a layer did not answer' and 'Reads live from the official government source.' It also notes billing per result row in the parameter description. This is valuable beyond a simple read/write hint.

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, using just a few sentences to state purpose, key behavior, and source. It does list all layers, which is somewhat redundant with the schema but aids quick comprehension. No 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?

Without an output schema, the description should clarify the response format. It mentions verdicts but does not state what the verdict object looks like (e.g., per-point results, layer-specific details). It covers batch limits and gating, but lacks explicit error handling or return structure, leaving some ambiguity.

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 thoroughly documents all three parameters. The description adds no additional parameter-specific semantics beyond mentioning batch lat/lon, which is already in the points parameter description. Baseline applies.

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: 'Batch lat/lon to FAA UAS airspace verdicts' with a specific list of layers. It distinguishes itself from sibling tools by focusing on drone airspace checks (LAANC, no-fly zones) rather than other government data domains.

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 (any drone airspace query), but does not explicitly discuss alternative tools or when not to use it. It mentions batch processing and live data, but lacks direct comparison to other tools or exclusions.

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 exist, so the description carries the transparency burden. It discloses keyless access, live reads from the official source, and derived health flags, which is useful behavioral context. But it does not mention operational traits like output size limits, pagination, rate limits, or write/read-only status; the cost per record is buried in a parameter description, not in the main description.

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

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

The description is a single, information-dense paragraph plus a store link; no filler or tautology. It front-loads the core purpose and key metrics and closes with a useful source reference. It could be slightly more structured (e.g., bullets) but is appropriately sized for the tool's complexity.

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

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

With no output schema, the description compensates by enumerating the major return field categories (assets, deposits, equity, ROA, ROE, NIM, asset quality, health flags, deltas) and explaining the mode/benchmark concepts are deferred to schema. It gives enough domain context to understand what the tool returns, though it does not specify output shape or size bounds. For a 10-parameter tool, this is 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?

Schema description coverage is 100% and every parameter has extensive meaning (examples, defaults, behavior, tradeoffs). The tool description itself adds no parameter-level detail, instead summarizing the domain. Per the baseline rule, with high schema coverage, a score of 3 is appropriate; the schema is doing the heavy lifting.

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 identifies a specific resource: a bank and credit-union financial-health API built on FDIC/NCUA data, with explicit mentions of metrics (ROA, ROE, NIM), quarter-over-quarter deltas, peer-percentile scoring, and health flags. This distinguishes it sharply from the environmental/geospatial sibling tools. The verb+resource structure is implicit ('API ... provides') but unambiguous and highly specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states the tool reads live government data and focuses on financial health, which implies when it would be appropriate (bank health analysis) versus the environmental screeners. However, it offers no explicit when-to-use or when-not-to-use guidance, no named alternatives, and no exclusion criteria. Usage context is present but only implied by the domain.

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 mentions that it reads live from the official government source, which is a behavioral trait. However, it does not disclose other behaviors like rate limiting, error handling, fallback mechanisms (e.g., tract-to-county fallback is only in parameter docs), or any side effects. Since no annotations are provided, the description carries the transparency burden but only partially satisfies it.

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

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

The description is a single, well-structured paragraph that front-loads the main purpose and then lists key outputs. It is concise, avoids redundancy with the schema, and effectively communicates the tool's value without unnecessary detail.

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 moderate complexity and the absence of an output schema, the description adequately covers the primary return values and the general use case. It does not delve into edge cases or limitations, but these are partially addressed in parameter descriptions. Overall, it provides sufficient context for an agent to understand when and how to use the 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?

The tool description does not add any semantic information about parameters beyond what the input schema already provides. The schema descriptions are thorough (covering all parameters, defaults, and fallbacks), so the description does not need to repeat them. Given the high schema coverage, a 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 clearly states the tool's core function: joining assets to FEMA's National Risk Index hazard profile, and enumerates the specific outputs (composite risk score, expected annual loss, social vulnerability, resilience, top-3 hazards). It also distinguishes itself from sibling tools by focusing on risk profiles and supporting multiple asset inputs. The reference to the store page reinforces its identity.

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 does not provide any explicit guidance on when to use this tool versus alternative environmental screening tools, nor does it mention conditions that would favor this tool. While the purpose implies a scenario (e.g., needing FEMA risk data), no concrete usage criteria or exclusions are stated.

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 burden of behavioral disclosure. It mentions that the tool 'reads live from the official government source,' which is a useful behavioral trait. However, it does not disclose error handling, billing behavior, or potential limitations such as rate limits or data freshness. No contradiction exists, but the transparency is limited to a single trait, missing other important aspects.

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, consisting of two sentences that front-load the core purpose and key output details. It includes a URL for additional information without bloat. Every sentence contributes value, making it well-structured and 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?

Although there is no output schema, the description clearly enumerates the key outputs (presence, codes, types, acreage, flag) and notes the live data source. It is sufficient for an agent to understand what the tool returns and its operational nature. Minor gaps like request limits or cost are covered in the parameter schema, so the description is fairly 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 has 100% description coverage, meaning all parameters are well-documented in the schema itself. The main description does not add further parameter-level meaning, such as format or constraints. Per the rubric, with high schema coverage, the baseline is 3, and the description provides no additional context, so 3 is justified.

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 as a USFWS Wetlands Proximity Screener for Section 404 site risk, listing specific outputs like wetland presence, Cowardin codes, types, acreage, and a screening flag. It distinguishes itself from sibling tools by focusing specifically on wetlands via the NWI, which is a unique domain among the listed environmental screeners.

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 frames it as a due-diligence tool for site selection, indicating when it should be used. It implies usage for wetland-related screening but does not explicitly state when to avoid it or mention alternative tools. The reference to live data from an official source adds credibility and a reason for preference. No direct comparison to siblings is provided, so a score of 4 is appropriate.

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 several behavioral aspects: it reads live government data, explains billing per row, details failure modes (e.g., truncated line fallback, simulated outage diagnostics), and clarifies how optional flags affect output. This goes beyond basic annotations, though rate limits or exact failure conditions are not fully specified.

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

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

The description is a single dense paragraph that front-loads the main purpose and lists outputs. It is not overly verbose, though it includes many details. It is well-structured and avoids redundancy.

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

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

Given the complexity (12 parameters, no output schema), the description covers the core behavior, data sources, billing, and failure modes. It is reasonably complete, though it could briefly mention the expected output shape or typical use-cases more explicitly.

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 provides extensive per-parameter descriptions (coverage 100%). The description adds context about data sources (official government source) and overall purpose, but does not significantly enhance parameter understanding beyond the schema. Since schema coverage is high, the baseline is 3; the added context justifies 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 functionality: it calculates distances to transmission lines, substations, power plants, and utility/ISO information for given coordinates. It explicitly lists outputs and use cases (data-center, renewable, BESS, EV siting), making its purpose unambiguous.

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 does not explicitly mention when to use this tool versus alternatives (e.g., other proximity screeners). It implies suitability for grid-related siting through examples, but lacks direct comparative guidance or criteria for selection.

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 transparency burden and provides useful behavioral context: it is keyless, reads live from official government sources, and normalizes/tracks deltas. It does not mention potential side effects like internal KV snapshot writes or rate limits, but the read-oriented framing is reasonably transparent.

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

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

The description is compact and front-loaded with the core function, followed by audience, auth, and data-source context. The store link is a useful addition 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?

The description covers domain, scope, audience, auth, and data source, and the schema supplies exhaustive parameter detail. There is no output schema and the description does not fully specify the response structure, but the normalized-queue/delta concept is enough to orient an agent reasonably well.

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%, and the input schema already provides detailed semantics for all 6 parameters. The description adds overall domain context but no parameter-level detail beyond what the schema already contains, so the baseline 3 applies.

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 ('Normalize', 'track') and names the exact resource ('US ISO/RTO generator interconnection queues') across all 7 ISOs. It clearly distinguishes the tool from sibling data tools by domain and functionality.

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 audience and context are clear ('renewables developers, land agents, energy consultants'; live US ISO queue monitoring and deltas), making the intended use obvious. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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. It discloses important behaviors: reads live from official government sources, every returned row is billable (including negatives), roster capped at 200 entries, OIG surname-only hits are flagged for review rather than reported, and rate limits can be raised via a Socrata token. It does not explicitly state read-only nature or error handling, but the described behaviors add substantial transparency beyond 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 a single paragraph that front-loads the primary purpose and then briefly highlights additional features. It is concise and avoids redundancy, though the store page link is arguably unnecessary for an API description. The structure is efficient and scannable, with the main verb and resource stated upfront.

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 gives a solid overview of capabilities (search, bulk screening, discipline checks, OIG screening) and limitations (billing, roster cap). However, it does not explicitly describe the output format for non-roster searches (only mentions verdict fields within the roster parameter). Since there is no output schema, more detail on return structure would improve completeness, but for a 17-parameter tool it covers the core functionality adequately.

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 provides 100% coverage with highly detailed descriptions for all 17 parameters, so the baseline is 3. The tool description itself does not add parameter-specific semantics beyond what the schema already specifies. While it mentions billing implications and roster caps, these are also covered in the schema descriptions. Thus, the description adds no additional parameter meaning 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 identifies the tool as a License Verification API for US professional licenses, specifying target professions (Nurses, MDs), sources (19 state boards, NPPES, HHS-OIG), and core actions (search by name/license number, verify status/expiration/disciplinary actions, bulk roster screening). This distinguishes it sharply from sibling tools focused on unrelated domains like FDIC or wetlands.

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: it is for verifying US professional licenses, screening OIG exclusions, and bulk roster checks. It does not list explicit exclusions or alternatives, but the sibling tools are all in different domains (environmental, financial, etc.), making the appropriate use case obvious. Lacks an explicit 'when not to use' statement, but the context is sufficient.

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. It discloses that the tool reads live from the official government source, that one asset always produces exactly one row, and that layer 4 lacks NHDPlus value-added attributes. It also explains the default clamping behavior for parameters. This is strong behavioral disclosure for a read-only screening tool.

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

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

The description is front-loaded with the tool's purpose and key outputs, then dives into parameter details. It's long but every sentence earns its place—the example with five sites is verbose but serves as a powerful calibration for the agent. The structure is logical: purpose, outputs, source, then parameter semantics.

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 (94 fields, 4 parameters, no output schema), the description is quite complete. It explains the output fields, the jurisdictional call, the data source, and parameter behavior. The only gap is that it doesn't describe the output format (e.g., whether results are returned as a dataset or inline), but the absence of an output schema and the tool's nature as a screener make this less critical.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema: it explains the standard shape for assets, provides a detailed example with five prefilled sites that deliberately cover the range of outcomes, and gives practical guidance for radiusMeters (Phase-I ESA vs utility-scale). The includeNonNetworkFlowlines parameter is well-explained with trade-offs.

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 screens lat/lon coordinates against NHDPlus HR surface water data, listing the 94 output fields and the jurisdictional-likelihood call. It distinguishes itself from siblings like fws-wetlands-proximity-screener by focusing on NHD surface water and Section 404/WOTUS flags, and it names the specific government source.

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 (screening any lat/lon against NHD surface water) and includes practical guidance in the parameter descriptions (e.g., radiusMeters for Phase-I ESA vs utility-scale siting). It doesn't explicitly state when not to use it or name alternatives, but the sibling list and the tool's specific scope make the usage context 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, the description carries the transparency burden. It discloses read-only behavior ('Reads live from the official government source'), cost per lookup, the fallback to Census geocoding, and the guarantee that each input yields one output row with a 'match_confidence' field. It lacks explicit rate limits or failure modes, but covers key behaviors.

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 dense but not overly verbose. It leads with a clear summary, then details scope, use cases, cost, and data source. The structure is logical, though the repeated phrasing about addresses and output rows could be tightened slightly.

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 gives a high-level list of fields but not the exact response structure. It also doesn't specify error handling, rate limits, or authentication requirements. For a read-only lookup tool, this is a moderate gap that could leave users uncertain about response format in edge cases.

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 includes detailed descriptions for both parameters. The tool description reinforces the address parameter's behavior (one row per input, fallback) and explains the maxResults cap. This adds meaningful context beyond the schema, especially regarding output consistency.

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: converting street addresses into parcel IDs, owner names, mailing addresses, assessed values, and coordinates. It specifies geographic coverage (Chicago/Cook County, Philadelphia, NYC) and distinguishes from sibling tools by focusing on parcel ownership 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 provides explicit use cases (address-grounding for AI agents, proptech, skip tracing) and mentions the scope and fallback behavior. While it doesn't directly compare to sibling tools, the domain-specific nature and geographic limits make it clear when this tool is appropriate.

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 full burden. It mentions billing to the user's Apify account and that it returns rows, but does not disclose whether the operation is read-only, potentially destructive, or has side effects. Since this runs arbitrary tools, the description should clarify safety characteristics but does not.

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 concise sentences, front-loaded with purpose and cost. Every word earns its place, with no redundancy or verbosity.

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 is minimal for a tool that runs 114 different tools with variable outputs. It states output as 'rows' but does not explain the structure, pagination, or how to discover available tools (though sibling tools like search_gov_data_tools partially cover this). Without an output schema, more detail on return format or error handling would improve completeness. Still, given the schema covers parameters, it is adequate but not rich.

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

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

Schema coverage is 100%, so the schema fully describes all three parameters, including defaults and ranges for maxItems. The description adds no additional meaning beyond the schema, but since coverage is high, a baseline of 3 is appropriate. It does tie the 'input' parameter to describe_gov_data_tool, which is helpful context.

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: it runs any one of 114 catalog tools and returns their rows. This is specific and distinguishes it from sibling tools, which are individual named tools. The verb 'Run' with the resource 'any one of the 114 catalog tools' is unambiguous.

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 executing any catalog tool generically, but does not explicitly state when to prefer this over a dedicated tool or when to avoid it. It does reference describe_gov_data_tool for input schema, providing some context, 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 provided, the description carries the full disclosure burden. It reveals the search scope (114 tools), matching dimensions (keyword/agency/topic), and return format ('matching tool names with descriptions'), which covers the core read/search behaviors. It omits edge-case behaviors such as result ordering and empty-result handling, but those are minor gaps for a catalog search tool.

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

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

The description is two sentences with all content earning its place: the first sentence states action, scope, and examples; the second covers return format and usage triage. It is front-loaded and contains no filler or repetition of schema details.

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 low-complexity search tool with two fully documented parameters and no output schema, the description covers purpose, query examples, return content, and usage context. Minor gaps remain around edge-case behavior (empty results, ordering), but the tool is simple enough that the description is nearly 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%, so 'query' and 'limit' are fully documented in the structured schema, setting the baseline at 3. The description adds useful query examples and the agency/topic framing, but it does not add new semantic facts about the parameters beyond what the schema already states.

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-resource pair ('Search the full catalog of 114 US government data tools') and clarifies the search dimensions (keyword, agency, topic) with concrete examples like 'wetlands' and 'FDIC'. It also explicitly distinguishes itself from the sibling tools by positioning itself as the general fallback: 'Use this first when the task is not covered by one of the dedicated tools above.'

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 gives explicit when-to-use guidance: 'Use this first when the task is not covered by one of the dedicated tools above.' This simultaneously identifies the alternative (the dedicated sibling tools) and implies the when-not-to-use condition (when a dedicated tool covers the task), providing clear triage.

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. It discloses that the tool 'reads live from the official government source,' indicating a read-only, network-dependent behavior. However, it does not mention potential latency, rate limits, error handling, or what happens with invalid inputs. This is some transparency but not rich.

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

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

The description is front-loaded with the core purpose and includes a useful list of the 20 layers. It is longer than necessary, and the Store page URL is not relevant to tool invocation, but the structure is clear and each piece of information contributes to understanding the tool's scope.

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

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

Given the complexity of a 20-layer bundle, the description covers the main purpose, output, and data source. It lacks a detailed output schema description, but since no output schema is provided, the mention of verdict and score is sufficient for selection and initial invocation. The gap is minor.

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 provides 100% coverage with detailed descriptions, examples, ranges, and defaults for all three parameters. The description itself does not add parameter semantics, but the schema already handles the full burden. 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 clearly states the tool performs environmental due diligence by returning a go/caution/no-go verdict and a 0-100 score across 20 federal layers. It uses a specific verb 'returns' and lists the layers, which distinguishes it from sibling single-purpose screeners.

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 this tool: for comprehensive environmental due diligence in a single call. It implies it can replace multiple individual screeners, but it does not explicitly name alternatives or state when NOT to use it, so it falls short of a 5.

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