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

Annotations already declare readOnly, idempotent, non-destructive, non-open-world. The description adds genuine context the annotations cannot: it is FREE, reads a local bundled catalog, makes no network call, performs no run, and incurs no charge. That cost/side-effect disclosure is exactly the kind of value beyond structured fields.

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 with zero filler; the core action and the 'when to use' directive are front-loaded, with cost reassurance last as supporting detail.

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

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

With no output schema, the description should say what comes back, and it does — 'the full input schema and documentation' for the requested tool. Given a one-parameter, read-only intro-spection tool, this is essentially complete; only error behavior for an unrecognized tool name is unstated.

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 single parameter is documented with an example ('noaa-slr-inundation-threshold-screener'). The description adds only the domain context that the value must be one of 123 catalog tools, so the schema does the heavy lifting — baseline 3.

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

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

Specific verb (return) + resource (full input schema and documentation) + scope (any one of 123 tools in the catalog). Clearly distinguishable from the sibling run-gov-data-tool, which executes rather than describes.

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 the calling condition: 'Call this before run-gov-data-tool so the input is correctly shaped.' It names the alternative sibling and the ordering relationship, so an agent knows exactly when to reach for this tool instead of running directly.

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 declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true; the description goes well beyond that. It reconciles the readOnlyHint=false by explaining the tool is read-only toward the government source but starts a metered run billed to the caller's Apify account ($0.01/result, $3-10 per 1,000), states nothing is charged when a run fails or when all inputs fail validation, and discloses the key data caveat that only ~165 IC polygons exist nationally so a false institutional-control result does not mean no AUL exists. This is exactly the extra context 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 correctly: purpose, then routing rule, then alternatives, then cost/side effects last. It is long and dense with capitalized emphasis, but nearly every sentence carries decision-relevant information (cost math, failure-billing rule, boundary polygon caveat) rather than 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 12-parameter, zero-required, metered tool with no output schema, the description covers the mode switch, billing and failure semantics, what a "clear" vs "error" row means, and the boundary-check limitations. An agent has everything needed to invoke it correctly and predict cost.

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 already documents modes, defaults, ranges and ASTM distances, so the baseline is 3. The description still adds parameter-relevant meaning the schema does not: the per-result billing model that governs how maxResults/maxHitsPerProgram should be set, and the ASTM E1527-21 distance framing that motivates radiusMiles values (1.0/0.5/0.25 mi).

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 (EPA regulatory-records screen by address) and enumerates the exact databases covered (Superfund/NPL, RCRA CORRACTS/TSD/generators, TRI, UST, LUST, Brownfields, NPDES, AIR, TSCA, RMP). It also names the sibling it is NOT (site-due-diligence-bundle for a combined verdict, epa-drinking-water-quality-screener for water quality), so an agent can route 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?

"CHOOSE THIS for the ASTM E1527-21 Phase I records search at regulation distances" gives an explicit selection rule, followed by concrete alternatives for two adjacent siblings. It also points to describe-gov-data-tool for a verified example input, covering the pre-call discovery step.

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 per-result metering ($0.012/result, $12 per 1,000, down to $3.60 on paid plans), that failed runs are not charged, the run-budget fail-loud behavior, and the core guarantee that it never publishes a clear for a source that did not answer (NO_SERVICE_AREA instead). The 'read-only with respect to the government source' phrasing is carefully scoped and reconciles with readOnlyHint=false, which reflects the metered run side effect rather than a data write.

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 routing, then cost — a sensible order. The cost/billing block is longer than strictly necessary and repeats pricing twice, but every part is decision-relevant for an agent and nothing is pure padding.

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, no-output-schema tool the description covers the important behavioral contracts: no-false-clear, billing, budget, and partial return shapes (health_based_violation_details, NO_SERVICE_AREA rows). Return format is only sketched at a high level, but that is the main residual 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 already 100%, so baseline is 3, but the description adds real semantics: why includeLead dates results, why includePfas can be disabled for speed, that maxAssets overflow is logged and unbilled, and what simulateOutage is for. It does not restate the schemas so much as explain intent behind the flags.

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 (screen) and resource (US coordinate / public water system) and enumerates the exact evidence classes returned: SDWA health-based violations, LCR 90th-percentile lead results, UCMR5 PFAS detections. It explicitly names the sibling it is not (epa-contaminated-site-screener) and the domain boundary, 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?

Contains an explicit 'CHOOSE THIS for...' selector plus a 'It is NOT a property contamination screen — for soil and groundwater records at a site use epa-contaminated-site-screener' exclusion with a named alternative. It also routes to describe-gov-data-tool for a free example input.

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?

Adds substantial context beyond the annotations: it explains the readOnlyHint=false semantics (a metered run is started on the caller's Apify account), the exact billing model ($0.02/result, $20 per 1,000, discounted on paid plans), and the failure guarantee ('nothing is charged when a run fails'). It also discloses a reliability trait ('never reads clear when a layer did not answer'). This is exactly the kind of side-effect disclosure an agent needs before invoking a paid, non-idempotent tool, and it is consistent with the annotations rather than contradicting them.

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 core purpose and layer coverage are front-loaded, and the cost/side-effect block is clearly labeled. It runs long and repeats billing figures (per-check, per-1,000, plan discounts) plus a bare store URL, but each block still serves a distinct function.

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

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

With no output schema, the description carries the return-value burden and largely meets it by naming the verdict components (ceilings, offer status, prohibited/TFR/SUA/NSUFR layers) and promising no false 'clear' results. Layer-verdict structure and the exact result shape are still somewhat implied, keeping it short of a 5.

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, and the schema already documents layer semantics, point formats, and the maxPoints cap in detail. The description adds genuinely new meaning by tying parameters to cost ('$0.02 per check,' 'one Result event is charged per row'), which clarifies why points/maxPoints are economically significant.

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: 'Batch lat/lon to FAA UAS airspace verdicts,' and enumerates the exact determinations returned (LAANC ceilings and offer status, Class B/C/D/E, prohibited areas, TFRs, SUA, NSUFR, stadium TFRs). The domain specificity (FAA drone airspace) clearly separates it from the EPA/FEMA/HIFLD siblings without needing to name them.

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?

Usage is implied by the domain (batch airspace checks for drone operations) and it usefully points to describe-gov-data-tool for a verified example input. However, it never states when to prefer this over alternatives or any preconditions/exclusions, leaving the when-to-use decision 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?

Annotations only declare readOnlyHint=false / openWorldHint=true / idempotentHint=false; the description goes far beyond that, disclosing that it never writes to the government source, that each call starts a metered Apify run billed $0.008 per result ($2.40–$8 per 1,000 depending on plan), that failed runs are free, that benchmark costs exactly one extra request, and that credit_union currently fails fast at no charge.

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?

Long but well-structured: purpose first, then a clearly labeled 'COST AND SIDE EFFECTS' block and a store link. Almost every sentence earns its place, though a few phrases (e.g. the repeated 'reads live from the official government source' claim) overlap with content already implied elsewhere.

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, no-output-schema tool, the description is close to complete: it names the metrics returned, flags that every mode returns the same field set, and discloses cost and failure behavior. The only gap is that it never characterizes the response envelope (single JSON run output vs. dataset), which an agent would have to infer.

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 per-parameter docs are extremely rich (mode ordering, peerBasis fallback threshold, cost-cap semantics of maxResults), so the schema carries the load. The top-level description adds only the cost-per-result framing that ties into maxResults and does not enrich the other nine parameters, meriting the baseline 3.

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

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

States a specific verb+resource with scope: a bank/credit-union financial-health screen over FDIC data, enumerating the concrete metrics (capital ratios, CRE concentration, deposit runoff, ROA/ROE/NIM) and QoQ deltas. An agent can tell this apart from siblings like epa-drinking-water-quality-screener or fema-nri-county-risk-profile 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?

Gives clear routing and prerequisite guidance — call describe-gov-data-tool for a verified example input — and reinforces it via parameter docs (state is 'strongly recommended', inspect priorItems for delta mode). It does not state explicit when-not-to-use conditions against the other sibling tools, so it stops short of the top band.

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 readOnly=false, openWorld=true, idempotent=false, destructive=false; the description adds substantial non-annotation context: metered Apify billing at $0.006/result, cheaper on paid plans, no charge on failed runs, and that the source itself is never written to. It also discloses graceful county fallback on tract misses, going well beyond what annotations already say.

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 purpose is front-loaded ahead of cost and pricing details, and each block is coherent. It is somewhat long and includes pricing minutiae and a store URL that are useful but slightly padded, keeping it just short of ideal tightness.

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 does identify the key returned fields, plus it explains the metered run and fallback behavior for a moderately complex join tool with 5 optional params. Remaining gaps (record shape, pagination, mode return differences) are minor.

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

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

Schema description coverage is 100% and the schema already documents asset formats, mode selection (empty Assets triggers inventory mode), maxResults bounds, and resolution semantics with examples. The description adds little beyond what the schema provides (e.g., asset key types), so baseline 3 is appropriate.

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

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

The description states a specific verb ('Join any asset ... to FEMA's National Risk Index') and enumerates the exact resource/fields returned: composite risk score, expected annual loss, social vulnerability, resilience, and ranked top-3 hazards across all 18 perils. This is highly specific and an agent can immediately tell what the tool produces.

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 (reads live from the official source; call describe-gov-data-tool for a free verified example input) and implies use for asset-to-hazard joins. However, it never states when to prefer this over alternatives such as site-due-diligence-bundle or when the tool is inappropriate, so there are no explicit exclusions.

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

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

Goes well beyond the annotations by disclosing that each call starts a metered Apify run, the exact per-result price and plan-dependent discounts, that failed runs are not charged, and that the tool never writes to any external system. The readOnlyHint=false annotation is consistent with billing a run to the caller's account, so 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 the sibling routing, then cost/side effects in clearly labeled blocks. Slightly padded by the pricing breakdown and store-page URL, but for a metered paid tool those details earn most of their space.

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 names the return fields (wetland presence, Cowardin systems, types, acreage, 404 flag) and covers cost, side effects, and alternatives. Given five fully-described parameters and one required field, an agent has nearly everything needed, though error-row behavior is only 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 description coverage is 100% and every parameter (assets, maxResults, radiusMeters, computeNearestDistance, nearestSearchRadiusMeters) is already fully documented with ranges, defaults, and examples in the schema. The description implies radius-based screening and nearest-distance behavior but adds no syntax or semantics the schema lacks, 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?

States a specific verb+resource+scope: per lat/lon site, wetland presence within radius, Cowardin codes, acreage, and a Section 404 screening flag. It explicitly distinguishes itself from the sibling nhd-surface-water-404-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?

Gives an explicit chooser line ('CHOOSE THIS for National Wetlands Inventory polygons'), states what it does NOT answer (CWA §404 jurisdiction) and names the alternative tool for that case, plus notes the two are usually needed together and points to describe-gov-data-tool for a verified example.

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 call starts a metered run on the caller's Apify account at $0.01/result, that failed runs bill nothing, that read-only applies only to the government source, and it documents degraded-mode behavior (allowTruncatedLineFallback nulling complete-universe fields, grid_tier DEGRADED) plus a diagnostic simulateOutage seam. This is exactly the kind of cost/failure/auth context 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?

Long but front-loaded: capability and outputs come first, then usage contexts, then a clearly labeled COST AND SIDE EFFECTS block. The store-page URL is the only line that doesn't earn its place, but overall it is dense rather than padded.

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 12 parameters, no output schema, and no annotation-level cost disclosure, the description does the heavy lifting: it explains billing model, failure accounting, and named output columns (grid_tier, nearest_ge100kv_line_*). It is nearly complete, missing only a full return-shape summary, which the absence of an output schema makes slightly more important.

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 documents every parameter in depth (including the sub-100 kV nuance and the planned-line caveat), so the description need not repeat them. The description adds only marginal param-level context ('Includes sub-100 kV'), so 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+resource ('Transmission Line & Substation Distance API by Coordinates') and enumerates the concrete outputs: nearest line with kV/owner/overhead-underground, nearest substation, nearest plant, serving utility and ISO/RTO, nearby MW. This is clearly distinguishable from siblings like interconnection-queue-tracker or fws-wetlands-proximity-screener.

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 the use contexts explicitly (data-center, renewable, BESS and EV siting) and routes the agent to describe-gov-data-tool for a verified example. It stops short of stating when to prefer a sibling tool (e.g. vs interconnection-queue-tracker) or any exclusion conditions, so it lacks the 5-level 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 annotations with unusual precision: keyless access, live reads from the official source, no writes to external systems, but every call starts a metered Apify run billed $0.008/result (down to $2.40/1,000 on paid plans) and nothing is charged on failure. This directly explains why readOnlyHint is false — state/cost accrues on the caller's account — without contradicting 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?

Front-loaded with purpose in the first two sentences, then audience, source, and a clearly labeled COST AND SIDE EFFECTS block. The pricing sentence is dense but earns its place for a paid actor; only the store URL and audience line are marginal.

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 cost model, data source, keylessness, delta categories, and a pointer to a companion tool for example input — enough to call it correctly for a six-parameter, two-mode actor with no output schema. Return-shape detail (beyond named monitor fields) is left implicit, which is the only real 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 description coverage is 100%, so each of the six parameters is already fully documented in-schema (including mode, deltaOnly, maxResults truncation semantics). The prose adds the delta-row taxonomy and nothing new about parameter syntax or defaults, 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?

States a specific verb and resource: normalizes US ISO/RTO interconnection queues for seven named ISOs into one schema and tracks new/withdrawn/status-change/COD-slip deltas. Names the exact sources (SPP, MISO, NYISO, CAISO, PJM, ERCOT, ISO-NE) and the audience, so it is unmistakable against the gov-data siblings.

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 snapshot vs delta intent indirectly ('track new, withdrawn, status-change and COD-slip deltas') and points to describe-gov-data-tool for a verified example input. It does not explicitly say when to change maxResults or when deltaOnly is preferred over mode=delta, but the context for a monitoring workflow is clear.

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

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

Adds substantial context beyond the annotations: exact pricing ($0.01/result, $10 per 1,000, down to $3.00 on paid plans), that failed runs bill nothing, that each call starts a metered run on the caller's own Apify account, and rate-limit relief via socrataAppToken. It also reconciles the readOnlyHint=false annotation by clarifying the read-only property applies to the government source, not to the caller's account — a genuinely useful 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?

Front-loads purpose, then cross-checks, then a clearly labelled COST AND SIDE EFFECTS block, which is the right ordering for a metered tool. Length is justified by the 20-parameter surface, though the store-page URL and the repeated marketing phrasing ('Primary source verification') are mild 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 complex, 20-param, no-output-schema tool the description covers scope, cost, side effects, cross-checks and mode behaviour well, and points to a helper tool for example inputs. It does not enumerate the return shape for the classic lookup path (output schema is absent), leaving a small gap, but the roster verdict fields are described.

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 per-parameter descriptions are extremely detailed (mode semantics, board IDs, delta baselines, billing per row), so the schema carries the parameter burden. The top-level description adds only marginal parameter meaning ('start small' on maxResults, pointer to describe-gov-data-tool), so 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 ('Primary source verification for US professional licenses'), names the exact scope (19 state boards, name or license number, status/expiration/discipline) and the federal cross-checks (NPPES NPI, HHS-OIG). The sibling tools are all in unrelated domains (EPA, FAA, FEMA, wetlands, parcels), so no differentiation ambiguity exists.

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

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

Gives clear context for the main modes (classic lookup/roster vs roster-delta newly-licensed feed) and routes the agent to describe-gov-data-tool for a verified example input. It also advises starting small on maxResults because rows are billable. It does not, however, state when to prefer this tool over an alternative approach or any explicit exclusions.

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

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

Despite annotations existing, the description adds substantial behavior not in them: the metered run on the caller's Apify account, exact pricing ($0.012 per Result, down to $3.60/1,000 on paid plans), no charge on failed runs, live reads from the official source, and deadline/failure semantics. This explains the readOnlyHint=false nuance (no writes to external systems, but the call does incur billed side effects) rather than contradicting it.

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

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

Front-loaded with purpose and sibling routing, then cost/side effects last, and each sentence carries usable information (selection rule, alternative tool, pricing, store link). It is on the long side and the 94-field enumeration is dense, but little is genuinely redundant.

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 describing the return content (distance metrics, waterbody type, flow, stream order, HUC levels, jurisdictional call and reasoning, 404/WOTUS flag) and failure rows ("failure_kind deadline" with null counts). Combined with full schema coverage and rich annotations, 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 all five parameters (assets, maxResults, radiusMeters, runBudgetSeconds, includeNonNetworkFlowlines) are fully documented in the schema itself. The description adds output-field framing ("94 fields") but no parameter syntax or semantics beyond what the schema already provides, which is the expected baseline 3.

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

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

Starts with a specific verb+resource ("Screen any lat/lon against USGS NHDPlus HR surface water") and enumerates the concrete outputs (distance to perennial/intermittent/ephemeral reaches, mean annual flow, stream order, HUC codes, jurisdictional-likelihood call, Section 404/WOTUS flag). It explicitly distinguishes itself from the sibling fws-wetlands-proximity-screener — streams/waterbodies vs mapped wetland polygons — 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?

Gives an explicit selection rule ("CHOOSE THIS for Clean Water Act §404 surface-water screening") and names the alternative to use otherwise ("For mapped wetland polygons use fws-wetlands-proximity-screener"). It also points to describe-gov-data-tool for a verified example input, covering the pre-call discovery step.

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 per-Result metering ($0.02/lookup, $20 per 1,000, as low as $6/1,000 on paid plans), that nothing is charged on failure, that each call starts a run on the caller's Apify account, and that one output row is guaranteed per input address via lookup_status. It also explains deadline-cut behavior (lookup_cut_by_deadline, 'source_unavailable'), reconciling the readOnlyHint=false annotation by clarifying it is read-only toward the government source but creates a billed 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?

Front-loaded with the core purpose before coverage, pricing, and side effects, and the 'COST AND SIDE EFFECTS' block is clearly signposted. It is somewhat long and includes a store-page URL and pricing repetitions that could be trimmed, but nearly every sentence carries operational value.

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 metered, no-output-schema tool the description covers inputs, routing/fallback logic, billing, failure semantics, and the derived output fields (lookup_status, lookup_cut_by_deadline). An agent has enough to invoke correctly; only the concrete result record shape is left unspecified, which is minor given the fields it names.

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 three parameters (addresses, maxResults, runBudgetSeconds) are already fully documented in the schema, including defaults and edge behavior. The description adds little parameter-level detail beyond what the schema states, 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 and resource ('Address to parcel ID, owner name, mailing address & assessed value from official assessor rolls'), naming exactly what is produced. It enumerates the jurisdictions served and the Census fallback, so an agent knows the precise scope without opening the schema. The sibling tool describe-gov-data-tool is also named, distinguishing this from generic lookups.

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

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

Gives clear context: address-to-owner resolution with a Census geocoding fallback for uncovered areas, plus an explicit pointer to call describe-gov-data-tool for a verified example input before invoking. What is missing is explicit when-not-to-use guidance versus the other gov-data siblings (e.g., run-gov-data-tool), which is left implicit.

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?

Far exceeds the annotations: it discloses metered per-row billing on the caller's Apify account, that failed runs are free, that failure returns an error with no rows (distinct from a zero-row success), and that failures/zero-rows carry next_step, must_supply and a verified example_input. It also clarifies that read-only applies only to the government source, which explains rather than contradicts readOnlyHint=false and openWorldHint=true.

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 the one-line purpose before the cost and failure semantics, and every clause carries a fact an agent needs (pricing, error vs empty, free validation). It loses a point for restating "Call describe-gov-data-tool first" twice and running somewhat long.

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, a nested input object and 3 params, the description still closes the important gaps: return shape (rows), error-vs-empty semantics, cost model, and pre-flight validation behavior. An agent has everything required to decide and call 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 schema already documents tool, input and maxItems; baseline is 3. The description adds real meaning by telling the agent how to obtain the input object's shape (via describe-gov-data-tool) rather than guessing 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?

States a specific verb and resource with quantified scope: "Run any one of the 123 catalog tools with the given input and return its rows." It is clearly the generic executor in a catalog where siblings are individual named tools, so an agent can distinguish it 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?

Gives an explicit prerequisite workflow twice: call describe-gov-data-tool first to shape the input and to see the exact price before running. It does not, however, say when to call this generic runner versus invoking a specific named sibling like epa-contaminated-site-screener directly, leaving that routing decision 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that: it discloses the return format and the cost/latency profile ('no network call, no run, nothing charged'), which the annotations do not 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 purpose, then return value, then routing and cost. Every clause earns its place; no restatement of the tool name or padding.

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?

No output schema, but the description states what is returned (matching names with descriptions), and annotations carry the safety profile. For a two-parameter discovery search, nothing needed 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 both parameters are already documented and a baseline of 3 applies. The description adds example query values ('wetlands', 'FDIC', 'flood', 'drone airspace') that concretely illustrate what the query string may contain, marginally exceeding the schema's generic wording.

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 ('Search the full catalog of 123 US government data tools') with the exact match dimensions (keyword, agency, topic) and the return shape ('matching tool names with descriptions'). It also positions itself against the sibling tools by scope, so an agent can tell it apart from run-gov-data-tool and the dedicated 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?

Explicit routing rule: 'Use this first when the task is not covered by one of the dedicated tools above.' This names the alternative class and the condition that selects this tool. It stops short of naming the natural next step (describe-gov-data-tool / run-gov-data-tool), so it is strong 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?

Annotations already declare readOnlyHint=false, openWorldHint=true, and idempotentHint=false, and the description explains the nuance behind that profile: it never writes to any external system but each call starts a metered run on the caller's Apify account. It adds cost rates ($0.10 per result, down to $30/1,000 on paid plans), the failure-billing rule ('nothing is charged when a run fails'), and the live-source read behavior — none of which the annotations convey. No contradiction with readOnlyHint=false.

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?

Long but information-dense and front-loaded, with clear 'CHOOSE THIS' and 'COST AND SIDE EFFECTS' sections. The store-page URL and the describe-gov-data-tool pointer are arguably marginal, keeping it from a 5, but no sentence is pure 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 metered, multi-layer screening tool with no output schema, the description covers purpose, routing, exclusions, cost/billing model, side effects, and source fidelity, and points to a free example-input tool. Nothing an agent needs to select or safely invoke it 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 schema already documents assets, maxAssets, and radiusMiles in detail, including which layers honor the radius and which ignore it. The description adds per-site billing semantics ('one row per site, not per layer'), but that is the schema/annotations' territory rather than new parameter syntax. 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+resource and scope: a combined go/caution/no-go fatal-flaw verdict with a 0-100 score across 20 named federal layers, one row per site. It explicitly names the sibling it is not (an ASTM records review) and routes contamination-first questions to epa-contaminated-site-screener, so an agent can distinguish it 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?

Explicit selection guidance: 'CHOOSE THIS when you want one combined go/caution/no-go verdict for a coordinate across many unrelated layers,' plus a negative boundary ('NOT an ASTM records review... omits coordinate-less Superfund records') and a named alternative for the contamination-first case. Alternatives and the condition that selects them are fully stated.

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