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

Annotations already declare readOnly/idempotent/non-destructive and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context — that it reads a catalog bundled with the server, makes no network call, and incurs no charge — which materially affects an agent's willingness to call it speculatively.

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 short sentences, front-loaded with what it returns, then the ordering instruction, then the cost disclosure. No filler, and the most decision-relevant facts come first.

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?

There is no output schema, but the description states exactly what comes back (full input schema and documentation), and the no-cost/no-network disclosure removes the main hesitation about calling it. Nothing an agent needs in order to call it correctly is missing.

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 single 'tool' parameter is already documented with an example. The description adds the constraint that the value must be one of the 120 tools in this server's catalog, which meaningfully narrows valid inputs 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 (Return) and resource (the full input schema and documentation) with an exact scope: any one of the 120 tools in the catalog. An agent can immediately tell this apart from run-gov-data-tool, which actually executes a tool.

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 instructs to 'Call this before run-gov-data-tool so the input is correctly shaped,' which gives clear ordering context relative to the sibling. It stops short of naming when this tool is unnecessary (e.g., when the schema is already known), so it is clear but not fully exhaustive.

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?

Goes well beyond the annotations: it discloses that the tool is read-only against the government source but starts a metered Apify run billed $0.01/result ($10/1,000, down to $3.00/1,000 on paid plans), that nothing is charged on failure, that no API key is needed, and that it reads live from the official source. This resolves the readOnlyHint=false signal by explaining the run-creation side effect, and adds cost/failure semantics annotations cannot express.

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 the core purpose and the CHOOSE-this/alternatives routing before cost details, which is well-structured. It is lengthy and somewhat repetitive (ASTM search distances appear in both the opening and later sections), but for a 12-parameter tool the length is largely earned.

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 fully carries the burden: it explains billing, failure semantics (assets failing validation fail the run and bill nothing), the extra astm_summary and boundary-intersection rows, and the IC-polygon caveat. An agent has everything needed to call it correctly and interpret the result shape.

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 every parameter in depth (modes, programs, ASTM distances, billing caps). The top-level description restates the thematic content (ASTM distances, database list, boundary checks) but adds little parameter syntax or format detail beyond what the schema provides. Baseline 3 is appropriate when the schema carries the burden.

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 (an EPA multi-database environmental due-diligence screen by address) and enumerates the exact databases covered (Superfund/NPL, RCRA CORRACTS/TSD/generators, TRI, UST, LUST, Brownfields, NPDES, AIR, TSCA, RMP) at ASTM E1527-21 distances. It explicitly distinguishes itself from siblings by naming site-due-diligence-bundle and epa-drinking-water-quality-screener, so an agent can route correctly without opening any 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?

Provides an explicit "CHOOSE THIS for the ASTM E1527-21 Phase I records search" trigger plus named alternatives for adjacent tasks (combined-verdict bundle, drinking-water quality). It also disambiguates internal modes (assets vs inventory) via parameter docs, leaving little to inference.

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?

Goes well beyond the annotations: it explains that it is read-only against the government source but each call starts a metered, billable run on the caller's Apify account ($0.012/result, $3.60–$12 per 1,000, nothing charged on failure), and that it "never clears a source that did not answer." The readOnlyHint=false is thereby reconciled rather than contradicted (the write is run creation, not external mutation), and non-idempotency is implied by per-call metering.

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 scope, then routing guidance, then cost/side effects, which is the right order. It is on the long side and the pricing breakdown plus store URL are somewhat promotional, but each block still earns its place for a paid, metered tool.

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 12-parameter tool with no output schema, the description covers the key semantic behaviors (NO_SERVICE_AREA row for unmapped locations, dated lead results, health_based_violation_details) and the cost model. Return-shape detail is partial but sufficient; nothing an agent needs to invoke correctly is missing.

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 schema itself is exceptionally rich (examples, semantics, and rationale for each of the 12 params). The description adds no parameter-level detail, so this sits at the baseline 3 — the schema carries the full burden and does so adequately.

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?

Names a specific verb+resource (screen any US coordinate for the public water system serving it) and enumerates the data domains: SDWA violations, Lead & Copper Rule 90th-percentile results, UCMR5 PFAS detections. It explicitly distinguishes itself from the sibling epa-contaminated-site-screener, so an agent can route without opening either 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?

"CHOOSE THIS for public water-system quality" plus an explicit exclusion: "It is NOT a property contamination screen — for soil and groundwater records at a site use epa-contaminated-site-screener." This is the when/when-not/alternative pattern done cleanly.

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?

Annotations declare readOnlyHint=false and idempotentHint=false, and the description explains exactly why: each call starts a metered Apify run billed $0.02/result, with nothing charged on failure, while remaining read-only toward the government source. It also discloses the 'never reads clear when a layer did not answer' verdict behavior — rich context beyond the structured hints.

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 purpose and layer list, with cost/side-effect disclosure in a clearly labeled block. Dense and mostly earned, though the trailing store-page URL and repeated billing figures add minor 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?

With no output schema, the description still conveys what each point yields (LAANC ceiling, whether LAANC is offered, prohibited/SUA/TFR status), the one-row-per-point billing model, and the safety cap. Nothing an agent needs to invoke it correctly is missing.

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 layers, points, and maxPoints are already fully documented in the schema, including the enum title mapping and the class_airspace caveat. The description adds no syntax or format detail beyond what the schema provides, 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 states a specific verb and resource — batch lat/lon converted to FAA UAS airspace verdicts — and enumerates the exact layers (LAANC ceilings, Class B/C/D/E, prohibited areas, TFRs, NSUFR, stadium TFRs). An agent knows precisely what this tool produces 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?

It gives strong in-tool guidance (defaults to all eight layers, why class_airspace cannot be excluded, cost per result) but never states when to choose this tool over its siblings like epa-contaminated-site-screener or other run-gov-data-tool entrants. Usage is implied by the domain rather than routed explicitly.

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?

Well beyond the annotations, it discloses the metered-run billing model ($0.008/result, down to $2.40 per 1,000 on paid plans), that failed runs are not charged, that it is read-only with respect to the government source, and that credit_union selection fails immediately without billing. This is exactly the kind of side-effect and cost context annotations cannot express.

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?

Purpose is front-loaded, then a clearly labeled COST AND SIDE EFFECTS block, so the most decision-relevant facts come first. It is somewhat long and ends with a store-page URL, but every sentence carries actionable information.

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 10-parameter tool with no output schema, the description covers cost, side effects, feature availability and the returned metric families, which is what an agent needs to decide and invoke correctly. Return field shapes are left to the schema, which is acceptable given there is no output schema to lean on.

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 all ten parameters are already fully documented in the schema, including enum semantics, defaults and worked examples. The top-level description adds little parameter detail beyond the schema; 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 opening sentence names a specific resource and domain (bank/credit-union financial health from FDIC/NCUA data) and enumerates the exact outputs: capital ratios, CRE concentration, deposit runoff, ROA/ROE/NIM, asset quality, QoQ deltas, peer percentiles and health flags. No sibling tool shares this domain, and an agent can tell precisely what it gets 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 supplies clear operating context: mode meanings with use-cases ('delta = the headline run-risk signal', 'stress = the triage view'), a recommendation to scope by state, and a cost-cap rationale for maxResults. It stops short of an explicit when-to-use/when-not statement versus other tools, but no near-alternative exists among 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?

Annotations (readOnlyHint=false, idempotentHint=false, openWorldHint=true) are all reconciled explicitly: the description states the tool is read-only against the government source yet starts a metered run on the caller's Apify account at $0.006/result, and that failed runs are not charged. That is exactly the behavioral context an agent needs and cannot infer from the schema, including the graceful tract-to-county fallback that never fails the run.

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?

Purpose is front-loaded in the first sentence and the cost/side-effect block follows in a clearly labeled 'COST AND SIDE EFFECTS' segment, which is justified for a metered tool. It runs slightly long — the discounted-plan pricing ('down to $1.80 per 1,000') and the store URL are marginal — but nothing is genuinely wasted.

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 still enumerates the returned fields and both operating modes, covers the resolution/fallback semantics, and discloses billing. An agent has everything needed to decide whether to call it and what to expect back.

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 all five parameters thoroughly, including the assets format examples and the maxResults billing coupling. The description restates the asset types and modes but adds no syntax or format detail beyond what the schema provides, 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?

States a specific verb and resource — join an asset to FEMA's National Risk Index hazard profile — and names the output dimensions (composite risk score, expected annual loss, social vulnerability, resilience, top-3 hazards). Scope (county/tract, 18 perils) is explicit, so an agent can distinguish it from the other gov-data siblings 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?

Explains the two operating modes (asset mode when 'assets' is populated, inventory mode when it is empty) and how resolution interacts with each. It does not name competing sibling tools such as site-due-diligence-bundle or epa-contaminated-site-screener, so the routing guidance is strong but not exhaustive.

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?

Goes well beyond the annotations by disclosing the billing model ($0.008/result, discounts to $2.40 per 1,000, no charge on failure) and reconciling the readOnlyHint=false with reality: read-only toward the government source, yet each call starts a metered Apify run. This is exactly the side-effect context the annotations flag but don't explain.

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 purpose, then usage routing, then cost and side effects, so the ordering is sensible. The pricing passage and trailing store URL are somewhat verbose, but each block carries distinct, useful information, so it stays reasonably tight.

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 carries the return-value burden and does so by listing the per-site outputs (presence, Cowardin codes, acreage, 404 flag). Combined with the radius/nearest-distance semantics surfaced in the schema, an agent has enough to call it correctly, though per-row failure behavior is only detailed in the schema.

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 already documents assets, maxResults, radiusMeters, computeNearestDistance and nearestSearchRadiusMeters in depth (including the true-circle screening and nearest-distance tradeoff). The description adds only the framing 'per lat/lon site' and output content, which is baseline value when the schema does 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?

States a specific verb and resource ('wetland due-diligence API', 'USFWS Wetlands Proximity Screener - Section 404 Site Risk API') and enumerates the outputs (Cowardin codes/systems, wetland types, acreage, Section 404 screening flag). It names the sibling nhd-surface-water-404-screener and describes the boundary between them, so an agent can distinguish them without opening schemas.

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?

'CHOOSE THIS for National Wetlands Inventory polygons... It does NOT answer Clean Water Act §404 jurisdiction — for surface-water features and relative permanence use nhd-surface-water-404-screener. The two are usually needed together.' This gives explicit when-to-use, when-not, the alternative, and a co-usage note.

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?

Goes well beyond the annotations: discloses metered billing ($0.01/result, $10/1k, down to $3/1k), that failed runs bill nothing, reads live from the official source, and explains the DEGRADED fallback behavior. The readOnlyHint=false annotation is not contradicted in spirit (writes happen to the agent's own Apify run storage, not external systems) but the description's 'read-only with respect to the government source' wording could be clearer about the run-storage side effect.

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 purpose, but the description is long and the COST AND SIDE EFFECTS block plus the extensive allowTruncatedLineFallback narrative make it dense. Much of the cost detail is essential, but the store page URL and some repetition (e.g., billing rules restated) add noise.

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 12-parameter read tool with no output schema, the description covers billing, data sources, fallback behavior, and default-on vs off semantics well. It could more explicitly enumerate the returned columns or clarify the readOnlyHint=false annotation's meaning, but an agent has enough to invoke 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 description coverage is 100%, so baseline is 3; the description adds meaningful semantics beyond the schema — notably the billing consequence of skipErrorRows, the low-confidence nature of includePlanned, and the DEGRADED fallback semantics of allowTruncatedLineFallback. This lifts it above baseline.

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+resource (distance to transmission lines, substations, power plants by coordinates) with concrete output fields (kV, owner, overhead/underground, utility, ISO/RTO, MW nearby). Clearly distinguishable from siblings like interconnection-queue-tracker or fws-wetlands-proximity-screener, which cover different resources.

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?

Names intended use cases (data-center, renewable, BESS, EV siting) which implies when to use it, and the include* flags let an agent scope the screening. It does not, however, explicitly compare against sibling tools or state when NOT to use this one.

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?

Annotations give only the safety profile, and the description goes well beyond it: metered Apify run at $0.008/result with plan-based discounts, no charge on failed runs, invalid ISO codes fail before billing, snapshot mode writes to the actor's own KV store, and low maxResults truncates trailing ISOs and excludes them from withdrawn detection. This is exactly the operational context an agent needs before invoking a metered, stateful call.

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 the core purpose, then a clearly labelled COST AND SIDE EFFECTS block. The pricing paragraph is slightly repetitive (two price restatements) but each section is scannable and nothing important is buried.

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 carries the return burden and largely does it — it names the emitted row types (new, withdrawn, status_change, cod_slip, iso_summary) and describes synthetic rows. It does not specify pagination or the shape of an individual queue record, which is the only notable gap.

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, but the description still adds value: the whole-federation size (~18,200 records) and the advice to raise maxResults to ~20000, plus that unrecognised ISOs now fail the run rather than silently falling back to all seven. It stops short of explaining priorItems/priorKvKey interaction in any detail beyond what the schema already says.

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 (normalize + track deltas) on a specific resource (US ISO/RTO interconnection queues) and enumerates the exact 7 sources covered. The sibling tools are other gov-data utilities, none of which touch interconnection queues, so an agent can route unambiguously without opening a 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?

Names an audience (renewables developers, land agents, energy consultants) and gives clear mode-selection context (snapshot vs. delta, deltaOnly for scheduled monitor runs). It never explicitly says when NOT to use it or names an alternative tool, 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?

The dedicated 'COST AND SIDE EFFECTS' section goes well beyond the annotations: it explains that calls are metered runs on the caller's Apify account, priced $0.01/result ($10 per 1,000) and as low as $3.00 per 1,000 on paid plans, with no charge on failed runs. It also clarifies the read-only scope ('never writes to any external system') and that every returned verdict row — including NOT_FOUND and INCONCLUSIVE_SOURCE_ERROR — is billable, which is exactly the kind of trait the readOnlyHint=false / idempotentHint=false annotations imply but don't explain.

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?

Purpose, coverage, and cost are front-loaded under an explicit heading, and the cost block is dense with genuinely decision-relevant facts. It is longer than strictly necessary — the store URL and the 'Nurses, MDs & OIG Exclusions' marketing line could go, and some capability claims are double-stated — but nothing is buried or misleading.

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 17-parameter, zero-required, no-output-schema tool, the description covers the important agent-facing unknowns: cost model, billing on negative results, roster cap of 200, and the roster verdict row shape (verdict, match_score, match_tier, NPI cross-walk, OIG screen). It does not describe what a single-record search returns or default-response size, which is a minor gap against its otherwise solid coverage.

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 17 parameters are already fully documented at the field level, and the top-level description mostly restates the search modes (name, license number, states, roster) rather than adding syntax or precedence rules. Baseline 3 is appropriate when the schema does 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 opening states a specific verb-and-resource ('License Verification API ... Primary source verification for US professional licenses') and enumerates scope: 19 state boards, NPI registry cross-check, HHS-OIG exclusion screening, bulk roster mode. This is unmistakably distinct from every sibling (site due diligence, EPA/FEMA/FAA screeners). An agent can route to it 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?

It gives concrete selection cues: use licenseNumber when you have it (most precise), fall back to full name if lastName/firstName return nothing, use a hyphenated board ID to target one board rather than a bare state code, and use roster mode for batch verification. It never states when NOT to use this tool or names an alternative, but the tool has no functional sibling to redirect to, so the coverage is strong.

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?

Annotations are present but thin, and the description adds substantial context the annotations cannot: the read-only-vs-metered distinction ('never writes to any external system — but each call starts a metered run on YOUR Apify account'), exact pricing ($0.012/result, $12 per 1,000, down to $3.60), and the failure-billing exception. This explains why readOnlyHint is false despite reading a government source, which is exactly the gap annotations leave.

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 purpose, routing, cost and side effects before the long field enumeration, and every clause carries information. It is longer than strictly necessary — the 94-field list and the trailing store URL are dense extras — but nothing is padded with filler.

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 return content (94 fields, jurisdictional-likelihood call with reasoning, 404/WOTUS flag) and by disclosing cost and side effects. An agent has everything needed to decide, invoke and interpret this 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?

Schema description coverage is 100%, so the schema already carries parameter meaning and the baseline is 3. The description adds outcome interpretation (HIGH creekside, LOW desert wash after Sackett, coastal case) rather than new parameter syntax or format detail, so it does not clear the bar to 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?

States a specific verb+resource+scope ('Screen any lat/lon against USGS NHDPlus HR surface water') and enumerates the returned fields (distances to perennial/intermittent/ephemeral reaches, flow, stream order, HUC, 404/WOTUS flag). It explicitly distinguishes itself from the sibling: 'For mapped wetland polygons use fws-wetlands-proximity-screener.' An agent can route between the two without opening either 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?

Gives explicit when-to-use ('CHOOSE THIS for Clean Water Act §404 surface-water screening') and a named alternative for the adjacent case (wetland polygons → fws-wetlands-proximity-screener). It also documents cost conditions and that failed runs are free, so the agent can reason about invocation risk.

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 COST AND SIDE EFFECTS section discloses a great deal beyond annotations: metered Apify account billing at $0.02/Result ($20/1000, down to $6/1000 on paid plans), no charge on failed runs, and read-only vs the government source. This is unusually rich operational 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?

Front-loaded purpose is strong, but the marketing copy ('Address-grounding primitive for AI agents, proptech & skip tracing', 'Reads live from the official government source', store URL) adds promotional bulk that a calling agent does not need. The billing detail earns its place; the slogan sentences do not.

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 sources, fallback, billing, and side effects. The description mentions unmatched addresses return match_confidence 'none' (from the schema), but there is no output schema, so the full set and shape of returned fields (owner, mailing address, assessed value, coordinates) is only loosely implied rather than enumerated.

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 both parameters are already fully documented in the schema including examples, caps, and defaults. The description adds no parameter syntax or format detail 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?

Specific verb+resource: turns street addresses into parcel IDs, owner names, mailing addresses, assessed values, and coordinates. Names the exact data sources (Cook County/Chicago, Philadelphia, NYC assessor rolls, with Census geocoder fallback), which distinguishes it from every sibling, none of which are address-to-parcel 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 clear context ('address-grounding primitive', skip tracing/proptech) and the fallback behavior for out-of-area addresses. It does not name an alternative sibling or state explicit when-not-to-use conditions, but the scope is unambiguous.

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?

Goes well beyond the annotations by disclosing metered billing per result row on the caller's Apify account, no charge on failed runs, and the crucial failure-vs-empty distinction (a failed run errors rather than returning zero rows). It also reconciles the readOnlyHint=false annotation by clarifying that the run is read-only toward the government source but starts a billed run on the user's account — context no annotation conveys.

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 the core action, then a clearly labeled COST AND SIDE EFFECTS block, so a reader gets the essential contract immediately. However, 'Call describe-gov-data-tool first' is stated twice, which is mild redundancy in an otherwise efficient definition.

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 wrapper tool with no output schema, the description covers everything an agent needs: cost model, failure semantics, zero-row meaning, prerequisite describe call, and row-limit behavior. The absence of an explicit return shape is acceptable because the tool delegates to the described per-tool schema.

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 'tool', 'input', and 'maxItems' are already documented, and the description's repeated 'describe-gov-data-tool first to shape the input' is more usage guidance than parameter semantics. It mildly enriches the 'input' parameter by explaining where its shape comes from, but the schema does the heavy lifting, making 3 the correct baseline.

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 precise verb+resource+scope: runs one of 120 catalog tools with a given input and returns its rows. It also implicitly distinguishes itself from describe-gov-data-tool, which is named as the schema-shaping step rather than the runner, so an agent can tell the two apart.

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 instructs the agent to call describe-gov-data-tool first to shape the input and to check the price before running, which is clear usage context and a named alternative. It stops short of stating when NOT to use it (e.g. vs. search-gov-data-tools or the bundled sibling tools), so it is strong but not exhaustive.

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?

Annotations already cover safety (readOnly, idempotent, not destructive, closed-world). The description adds cost/latency context beyond annotations: 'FREE: reads a catalog bundled with this server — no network call, no run, nothing charged.' This is valuable non-structured behavior. It doesn't describe result ordering or pagination, keeping it below 5.

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 tight sentences, front-loaded with purpose, then routing, then cost note. Slightly dense with examples but every clause earns its place. No filler.

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 purpose, routing, cost, and that it returns matching names with descriptions. Since no output schema exists, the description appropriately signals the return shape. The only gap is result ordering/pagination behavior, which is minor for a catalog search.

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 both parameters are fully documented in the schema (query match targets, limit default/max). The description adds nothing beyond the schema about parameters, so 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?

States a specific verb+resource ('Search the full catalog of 120 US government data tools') with the exact matching fields (keyword, agency, topic) and example queries. Clearly distinguishes this discovery tool from the sibling run/describe tools and the dedicated domain 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?

Explicitly routes the agent: 'Use this first when the task is not covered by one of the dedicated tools above.' This is a precise when-to-use cue with an implicit when-not-to-use (when a dedicated tool fits), which is exactly the routing the siblings demand.

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?

Annotations mark readOnlyHint=false and openWorldHint=true, and the description explains why by disclosing that each call starts a metered run on the caller's Apify account, billed $0.10 per result with tiered pricing, and that failed runs are not charged. It also clarifies the read-only scope ('never writes to any external system'), which is consistent with rather than contradicting the false readOnlyHint.

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 text is dense and front-loaded: identity, then choose/not, then cost/side effects, then store link. Every sentence carries information, though the layer enumeration and pricing detail make it longer than strictly necessary.

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 supplies the return shape ('go/caution/no-go fatal-flaw verdict and 0-100 score'), the cost model, the billing granularity, and the scope limitations like omitted coordinate-less Superfund records. Nothing an agent needs to call and interpret it correctly is missing.

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 already documents all three parameters in depth; the baseline is 3. The description adds only marginal semantics (e.g. 'one row per site, not per layer' and 'smaller means a tighter on-site screen'), which does not meaningfully exceed what the parameter descriptions already provide.

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+resource (environmental due diligence bundle producing a 20-layer site scorecard) and enumerates the concrete layers and verdict format. It clearly differentiates itself from the sibling epa-contaminated-site-screener and other point tools, so an agent can select it 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?

Explicitly says 'CHOOSE THIS when you want one combined go/caution/no-go verdict for a coordinate across many unrelated layers' and gives the when-not ('NOT an ASTM records review') plus the alternative ('For a contamination-first question use epa-contaminated-site-screener'). This is a complete when/when-not/alternative routing.

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