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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new operational context: it is free, performs no network call, does not run anything, and charges nothing — useful cost/side-effect info 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?

Three short sentences, front-loaded with the action and scope, then the sequencing rule, then the cost caveat. No filler; every sentence carries information an agent needs.

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 explicitly says what is returned (full input schema and documentation), which covers the return-value gap. For a 1-parameter, annotation-rich tool this is complete.

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

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

Schema coverage is 100% and the schema already documents the single 'tool' parameter with an example. The description still adds value by bounding the domain to the 122 tools in the bundled catalog, telling the agent the parameter must name a catalog member rather than an arbitrary string.

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 ('full input schema and documentation') over a well-defined scope (any one of the 122 catalog tools). This is clearly distinguishable from siblings like search-gov-data-tools (discovery) and run-gov-data-tool (execution).

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 to call it before run-gov-data-tool 'so the input is correctly shaped', giving a concrete sequencing rule and the reason for it. It does not, however, contrast against search-gov-data-tools or state when describing is unnecessary.

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 goes beyond annotations by disclosing cost and side effects: 'read-only with respect to the government source — it never writes to any external system — but each call starts a metered run on YOUR Apify account, billed $0.01 per result ($10 per 1,000).' It also notes 'Nothing is charged when a run fails.' This is rich behavioral context that annotations alone do not provide. The annotations say readOnlyHint=false, but the description clarifies it is read-only with respect to the government source while being a metered run on the user's account — this is not a contradiction, it's a nuanced disclosure.

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 long but every sentence earns its place: it covers purpose, usage, alternatives, cost, side effects, and store page. The key 'CHOOSE THIS' guidance is front-loaded after the initial definition. It is dense but not redundant. It loses one point for length — it could be tightened slightly without losing 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?

Given the tool's complexity (12 parameters, two modes, multiple EPA programs, ASTM distances, billing model), the description is remarkably complete. It covers cost, failure behavior, mode differences, parameter interactions, and even provides a store page link. There is no output schema, but the description explains what rows are produced (billable rows per site hit, 'clear' rows, astm_summary rows). Nothing critical is missing for an agent to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds significant meaning beyond the schema: it explains the billing model per row, the difference between assets and inventory modes, the ASTM E1527-21 search distances, and the behavior of the 'state' hint with lat/lon. It also clarifies that 'programs' can be left empty to keep costs identical to previous versions. This is substantial added value over 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 opens with a specific verb and resource: 'Phase I ESA & Environmental Due Diligence: EPA Database Search' and immediately explains it produces an environmental database report over a list of EPA programs. It also distinguishes itself from siblings by naming site-due-diligence-bundle and epa-drinking-water-quality-screener as alternatives. This is a clear, specific, and well-differentiated purpose.

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

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

The description explicitly says 'CHOOSE THIS for the ASTM E1527-21 Phase I records search at regulation distances around one or more properties' and names alternatives: 'For a single combined verdict across twenty unrelated layers use site-due-diligence-bundle; for drinking-water quality use epa-drinking-water-quality-screener.' This gives clear when-to-use and when-not-to-use guidance.

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

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

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?

Annotations give only the generic safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description goes well beyond them by disclosing the metering model — a billable run on the caller's Apify account at $0.01/result ($3-10 per 1,000), no charge on failure, per-row billing even for NOT_FOUND/INCONCLUSIVE and even for the cheaper-looking statusOnly output. This is exactly the kind of cost/side-effect disclosure annotations cannot carry.

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 purpose and cost warning before the long capability list, and the COST AND SIDE EFFECTS block is clearly signposted. It is long, but with 20 parameters and multiple modes little of it is padding; the store URL and some marketing phrasing ('Nurses, MDs & OIG Exclusions') are the only borderline 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?

For a 20-parameter, zero-required, no-output-schema tool, the description covers mode selection, billing, default-applied values, failure behavior, and board-support caveats well. It stops short of describing the actual result/row shape (beyond 'verdict row', 'unsupported_filters', 'candidates_truncated'), which an agent would need since no output schema exists.

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 most parameter meaning and the baseline is 3. The description adds genuinely new semantics: that statusOnly has the same per-row price despite returning less data, that every roster verdict row is billable including negatives, and that the delta baseline is scoped by boards + professions (changing a filter resets it).

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

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

The description names a specific verb and resource (primary-source license verification across 19 state boards by name or license number) and enumerates the deliverable fields (status, expiration, disciplinary actions). It is immediately distinguishable from the sibling gov-data tools (parcel, EPA, FAA, HIFLD screeners), which serve entirely different 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?

It routes the agent explicitly: licenseNumber is 'the most precise search available — use it when you have it'; name should be used 'if lastName/firstName return nothing'; roster is for batch verification; roster-delta is for the newly-credentialed feed. It also explains when each mode returns nothing and bills nothing.

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

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

Despite annotations already indicating readOnlyHint=false, the description adds valuable nuance: it clarifies that the tool is read-only with respect to the government source but triggers a metered Apify run, discloses exact billing ($0.012/Result), mentions discounts, and explains failure behavior (nothing charged on run failure, rows with failure_kind 'deadline' when budget exhausted). This level of transparency goes far beyond what annotations provide and fully informs the agent of side effects and costs.

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 long, but every sentence carries relevant information. It is front-loaded with the core purpose and output enumeration, then addresses cost, alternatives, and parameter specifics. The formatting is dense but not repetitive. A slight penalty for wall-of-text presentation that could be parsed more quickly with headers or bullet points, but it 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?

For a tool with 5 parameters, no output schema, and significant cost/side-effect nuances, the description is exceptionally complete. It explains the 94 output fields, the live source, failure modes, budget behavior, and even provides test sites covering the outcome range. Nothing an agent needs to invoke this tool correctly is missing, including how to interpret results and how to join them back to source data via the label field.

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

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

Schema coverage is 100%, but the description adds significant semantics: it explains the [{lat, lon, label}] shape, gives concrete decimal-degree examples, clarifies defaults and clamping (e.g., maxResults default 1000, radiusMeters default 1600), offers use-case guidance (1000 m for Phase-I ESA, 3000 m for utility-scale), and explains the implications of includeNonNetworkFlowlines (layer 4 lacks NHDPlus value-added attributes). This adds meaning well beyond the raw schema definitions.

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: 'Screen any lat/lon against USGS NHDPlus HR surface water.' It specifies the exact resource (NHDPlus HR), the verb (screen), and enumerates the 94 output fields. It also explicitly distinguishes itself from the sibling fws-wetlands-proximity-screener by naming the alternative and its condition. This is a model of purpose clarity.

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: 'CHOOSE THIS for Clean Water Act §404 surface-water screening — streams, waterbodies and their relative permanence. For mapped wetland polygons use fws-wetlands-proximity-screener.' It also provides contextual advice for radiusMeters (typical ESA review vs. utility-scale projects) and explains the behavior of runBudgetSeconds. This leaves no ambiguity about when to select this tool over alternatives.

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

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

Annotations only flag the generic profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false); the description explains why — each call starts a metered Apify run billed $0.02/result, with nothing charged on failure. It also discloses the read-only relationship to the government source and the one-row-per-address contract, which is materially useful beyond the annotations.

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, but the entry is bloated: a title restatement, an extensive jurisdiction list that repeats the schema parameter description verbatim, pricing marketing ('Low on paid Apify plans'), and a store-page URL. Several sentences do not earn their place for an agent deciding whether to call the 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?

There is no output schema, and the description compensates by naming the returned fields, the one-row-per-address guarantee, and the lookup_status signal, plus cost/side-effect disclosure. A brief note on absent-coverage output shape would close the remaining gap, but the essentials are present for a 2-parameter 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%, and the schema already documents addresses (format, examples, routing/fallback) and maxResults (cap, default 100). The description adds no syntax or semantics beyond that, so the baseline of 3 applies; its coverage list largely duplicates the schema text.

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 names a specific transformation — US street address → parcel ID, owner name, mailing address, assessed value — and identifies the authoritative source (official assessor rolls). It reads as a distinct lookup capability against the sibling gov-data 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?

It gives clear context for use: which jurisdictions are covered by direct assessor lookup, which fall back to Census geocoding (lat/lon only), and that every input yields exactly one row. There is no explicit 'do not use this when…' or named alternative tool, so it stops short of full routing 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?

Goes well beyond the annotations by disclosing cost semantics (metered run on YOUR Apify account, billed per result row, no charge on failure) and failure/empty-result semantics (a failed run returns an error and no rows, so zero rows means the source was genuinely reached and matched nothing). The careful phrasing 'read-only with respect to the government source' is consistent with the readOnlyHint=false annotation, which reflects the billing side effect rather than any external write, so there is no contradiction.

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-loads purpose, then cost and side effects in a clearly labeled block, so an agent gets the critical cost warning early. Slightly penalized because 'Call describe-gov-data-tool first' is stated twice, which is a redundant repetition rather than a distinct point.

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 meta-tool with a nested input object and no output schema, the description covers the essentials an agent needs: what is returned (rows), where cost comes from, and how to interpret failures versus empty results. It does not discuss the output shape of a successful row set beyond 'its rows', but that gap is minor given the variable nature of 122 underlying tools.

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 tool, input, and maxItems (including the 1-1000 bounds and default 200). The description only adds the modeling hint that input should match the schema returned by describe-gov-data-tool, which is marginal value over the schema's own 'Input object matching the schema returned by describe-gov-data-tool' text. 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?

States a specific verb and resource ('Run any one of the 122 catalog tools ... return its rows') and explicitly scopes itself against the sibling describe-gov-data-tool, which shapes the input. An agent can immediately tell this is the execution entry point versus the discovery/describe tools 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?

Gives clear prerequisites and sequencing: 'Call describe-gov-data-tool first to shape the input' and again to see pricing before running. It names the alternative tool and the condition that selects it, but offers no guidance on when NOT to run this (e.g., preferring a pre-bundled sibling like site-due-diligence-bundle) or awareness of the other 122 tools' direct-call pattern, so it stops just short of full when/when-not coverage.

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 declare readOnly, idempotent, non-destructive and closed-world, so the bar is low, yet the description adds genuinely new operational context: it reads a catalog bundled with the server, makes no network call, triggers no run, and incurs no charge. That cost/latency disclosure is exactly the kind of trait 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?

Three sentences, front-loaded with the purpose, then usage routing, then the cost note. Every sentence earns its place, though the final 'FREE: ... no network call, no run, nothing charged' clause is slightly redundant in its triple phrasing.

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 two-parameter read-only search with no output schema, the description covers purpose, routing, return shape ('matching tool names with descriptions'), and cost behavior. 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 coverage is 100%, so both query and limit are already documented in the schema, making 3 the baseline. The description's example keywords ('wetlands', 'FDIC', 'flood') and the phrase 'agency, or topic' add a little color about what query matches, but no syntax or limit behavior 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?

Specific verb (Search) plus a precisely scoped resource (the full catalog of 122 US government data tools) and the match dimensions (keyword, agency, topic). It also positions itself against the sibling set by telling the agent this is the fallback when no dedicated tool covers the task.

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 states 'Use this first when the task is not covered by one of the dedicated tools above,' which is clear routing guidance against the sibling tools. It stops short of naming a specific sibling (e.g. describe-gov-data-tool) or describing what to do when no match is returned, 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 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.