DeepMap AI -- Earth Grounding

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

Beyond the readOnlyHint/idempotentHint/destructiveHint annotations, the description explicitly states that the output is a public aggregate that tracks the library and leaks no proprietary data. This is valuable behavioral context (privacy guarantee) that annotations do not provide.

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?

Single sentence, front-loaded with what the tool answers, and the parenthetical adds essential qualifiers without wasting words. Every phrase contributes.

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 zero-parameter capability query with annotations covering safety, the description is nearly complete: it states the output concept and its privacy boundaries. It does not give a concrete output shape, but no output schema exists and the aggregate nature is described well enough for an agent to invoke correctly.

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

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

The tool has zero parameters, which is the baseline-4 case: there is no parameter semantics burden. Schema description coverage is 100% trivially, and no doc comments are needed.

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 the tool reports what DeepMap can answer now plus coverage counts, which is a clear, specific purpose. It doesn't use an imperative verb like 'List' but the resource and scope are unambiguous. It doesn't explicitly distinguish itself from siblings, though its meta/coverage nature is apparent from content and sibling names.

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 no explicit guidance on when to call this tool versus the sibling tools (e.g., before choosing a specialized tool like ground_truth or check_hypothesis). The purpose implies it is a coverage/overview query, but there is no when-to-use or when-not-to-use statement.

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 the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond the schema by specifying the exact return payload for a direct match: verdict, positive control, honest bound, and anchor. It does not cover the no-match case, but that is a minor gap given the strong annotation coverage.

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

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

The description is two sentences with no filler, front-loads the core question, and packs the return contract into a readable list. Every sentence earns its place.

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

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

For a three-parameter read-only tool, the description covers the key semantics: what is queried, what a direct match returns, and why an agent should call it. The lack of an output schema is partially compensated by listing the return components, though no-match behavior and the optional limit parameter are not explained.

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 67%, with claim and domain already described in the schema. The description reinforces that the claim is a plain-language hypothesis but does not add meaningful meaning beyond the schema, and the limit parameter remains undocumented by both.

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 question and immediately names the resources being queried: the Null Museum and the Bitcoin-anchored hypothesis registry. It clearly distinguishes itself from siblings like run_controlled_test by framing this as a lookup that tells an agent whether a hypothesis has already been tested, not a tool that runs tests.

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 conveys when to use the tool: before testing an Earth-science hypothesis, to avoid re-running a dead idea. It does not explicitly name alternative tools or state when not to use it, but the 'never re-runs a dead idea' phrasing provides practical usage context that is clear enough.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful context that results are based on verified observations, but it does not disclose return format, thresholds, or coverage limitations.

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

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

The description is a single compact sentence with no filler words, and the hazard scope is front-loaded. It loses a point only because it is so brief that it leaves important usage and parameter guidance unstated.

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 three parameters, no output schema, and a large sibling set of risk-related tools, a one-line description is insufficient. It omits expected return values, parameter semantics, and usage conditions, leaving too much to inference.

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 0%, and the description says nothing about lat/lon format, radius_km units or default, or how these parameters affect results. An agent receives no semantic help beyond the bare schema field names and types.

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

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

The description clearly identifies the resource (ground stability) and specific hazard types (subsidence, void, karst, fault), and the phrase 'from verified observations' adds a useful scoping qualifier. However, it lacks an explicit verb like 'assess' or 'query' and does not directly differentiate itself from sibling tools such as seismic_hazard.

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?

There is no guidance about when to use this tool versus alternatives, no prerequisites, and no mention of sibling tools. The description implies use for ground-stability risk assessment, but an agent has to infer this from the resource name and hazard list.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the result includes a five-part answer plus provenance, but it does not clarify open-world behavior such as potentially missing answers or the shape of the provenance record. No contradiction with 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?

The description is a single compact sentence with no filler and every phrase carries meaning. It would be stronger if it started with an explicit action verb, but it is appropriately sized and readable.

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

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

For a simple two-parameter read-only lookup, the description names the output bundle clearly enough. However, with no output schema, it leaves gaps around response structure, whether individual answers can be null under open-world conditions, and any coordinate system assumptions.

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 0%, and the description does not mention lat, lon, coordinate system, valid ranges, or any other parameter semantics. The schema's lat/lon names are self-explanatory, but that meaning comes from the schema, not the description, which adds no parameter-level value.

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 resource—the bundled five-question ground truth answer—and enumerates its components (water / stability / hazard / resource / provability) plus a provenance record. It lacks an explicit verb like 'retrieve' or 'return', but the noun-phrase framing is still clear and the word 'bundled' differentiates it from individual sibling tools like ground_stability or water_availability.

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

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

The description provides no guidance on when to use this tool versus its siblings. It does not say 'use this when you need all five answers at once' or mention any alternatives such as ground_stability, seismic_hazard, or water_availability for single-question lookups.

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, idempotentHint, and destructiveHint, covering the safety profile. The description adds meaningful behavioral context: each returned null/bound/retraction includes a positive control for trustworthiness, and the system 'carries its own retractions.' This goes 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?

The description is short and front-loaded, with the core action and resource in the first sentence. The second sentence is somewhat rhetorical but compact and reinforces the trust/credibility angle.

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

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

For a simple read-only list tool with no output schema, the description covers the main operation and return content at a high level. However, 'limit' semantics and valid domain format are left unspecified, and the absence of an output schema means an agent must infer the response structure from the prose.

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 0%, so the description must carry the weight for both parameters. It clarifies 'domain' by saying the listing is 'optionally by domain', but it never explains the 'limit' parameter, its default, or acceptable domain values.

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: 'List DeepMap's documented nulls / bounds / retractions (the Null Museum)'. It also adds the optional domain filter, making the tool's purpose clear. It does not explicitly differentiate from siblings, but the resource is distinctive enough that an agent can tell it apart.

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

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

The description implies usage by describing a listing operation with an optional domain filter. However, it does not state when to prefer this tool over siblings or mention any exclusions, leaving the 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?

The parenthetical 'gated, honest null' adds a behavioral clue beyond the annotations: the tool may return a truthful null rather than fabricating an indication, and some gating condition may apply. This is useful but underdeveloped—neither the gate nor the null conditions are explained. With no output schema, the description bears more burden than it fully carries.

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 extremely short and front-loaded, but brevity is achieved at the cost of clarity through unexplained jargon like 'gated' and 'honest null.' The text resembles a label or annotation rather than a self-contained description, so it qualifies as under-specification more than effective conciseness.

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 required coordinates and no output schema, the description omits parameter semantics, return shape, and usage context amid many sibling tools. It does not explain what happens when no resource is present, how 'gated' affects calls, or which siblings cover overlapping resources. An agent has enough to guess the domain but not enough to call it correctly with confidence.

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 0%, and the description does not mention lat, lon, or the optional type parameter at all. An agent must infer that location is relevant and cannot learn how to format coordinates or what the type string accepts. This is a critical gap for a three-parameter tool with no enums or schema hints.

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 four resource categories (geothermal, mineral, gas, water) and signals a lookup-style capability, so it is more specific than the bare tool name. However, it uses the nominalization 'indication' instead of a concrete verb and never mentions the lat/lon query basis, leaving exactly what the tool returns or computes unclear. It also does not distinguish itself from the overlapping sibling water_availability.

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?

No guidance is provided for when to call this tool instead of siblings such as water_availability, ground_truth, or verify. The resource list implies a use case, but the description does not state prerequisites, exclusions, or alternatives. 'Gated' hints at access restrictions but not when the gate opens.

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 adds substantial behavioral detail beyond the annotations: it fetches real data, performs lock-in detection with a local-background null and a positive control, returns UNTESTABLE if the reference line is not recovered, and distinguishes synthetic demo vs. live authenticated modes. This is rich, specific behavioral disclosure with no contradiction to 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?

The description is information-dense and mostly front-loaded with the key purpose. Some promotional phrasing ('honest verdict it cannot fake', 'Lab-as-an-API') is not strictly necessary, but the structural content about controls, tiers, and recipe earns its place.

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

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

For a tool with no output schema, the description gives adequate context on methodology, control behavior, and tier availability. The main gaps are unspecified return-value structure and minimal guidance on parameter selection (especially lat/lon/window_days), but the overall operational context is strong.

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 only 50%, and the description does not meaningfully clarify lat, lon, window_days, or hypothesis beyond what the schema states for carrier and observable. It indirectly references carrier via the positive control line but leaves core parameters underspecified for an agent selecting values.

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 a specific verb and resource: 'run a REAL, bounded controlled test at a location' and get a verdict. It distinguishes this tool from generic 'verify' siblings by emphasizing the lab-as-an-API methodology with positive/negative controls, though it does not explicitly name sibling alternatives.

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 explains when the tool is appropriate — when a grounded, cannot-fake controlled test is needed — and notes free vs. authenticated tiers. However, it does not explicitly state when not to use it or how it compares to sibling tools like check_hypothesis, verify, or ground_truth.

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, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful context by noting the ledger is 'outcome-excluded' and that there is 'no platform-wide accuracy figure,' which warns agents about the output's limitations. It does not explain return structure or data computation, but it does add value beyond 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?

The description is a single sentence with no redundancy, and the important caveat about accuracy is compactly placed in parentheses. It is concise and front-loaded, though the noun-phrase opening ('Seismic hazard via...') is slightly less direct than a verb-led sentence would be.

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 and 0% parameter documentation, the one-sentence description leaves significant gaps: parameter semantics, expected return values, and usage context are all missing. The ledger and accuracy caveats are helpful but insufficient for an agent to confidently invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate, but it mentions none of the four parameters: lat, lon, region, or horizon_days. The agent only knows parameter names and types from the schema, with no semantic guidance on units, coordinate format, region behavior, or horizon interpretation.

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 identifies the resource ('seismic hazard') and clarifies the data source ('public, outcome-excluded prediction ledger'), which is reasonably specific. However, it lacks an explicit verb like 'retrieve' or 'query,' and it does not name sibling tools to differentiate from, though the ledger caveat provides some separation from related earth/space tools.

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

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

The description gives no when-to-use guidance and mentions no alternatives or exclusions. Sibling tools like ground_stability and space_weather_grid_risk could easily be confused with this one, but the description does not explain when to choose seismic_hazard over them. The 'via the ledger' phrase hints at context but does not direct usage.

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 communicate that this is read-only, idempotent, open-world, and non-destructive, so the description only needs to add context. It contributes the notion of point-based infrastructure exposure, but does not describe any output shape, coordinate expectations, or data limitations. This is acceptable but not rich.

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

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

The one-sentence description is tight and front-loaded, with no wasted words. It is under-specified for completeness, but as a purely conciseness and structure measure it earns its place.

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

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

For a simple two-parameter read-only tool, some burden is lower, but with no output schema and no return semantics, the agent cannot anticipate what the exposure value represents or its units. The description also omits relevant context like coordinate reference system and any usability caveats for GIC assessment.

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 0%, so the description must explain what lat and lon mean, what range or format is expected, and how they determine the point. The phrase 'at a point' only weakly echoes the schema; no units, coordinate system, or bounds are supplied, leaving the agent to guess.

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 identifies the tool's domain—GIC/space-weather exposure—and clarifies that it applies to infrastructure at a point, which distinguishes it from sibling hazard tools like seismic_hazard, ground_stability, and water_availability. It lacks an explicit verb such as 'calculates' or 'returns,' but the core purpose is understandable.

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?

No guidance is given for when to use this tool versus related hazard tools such as ground_stability, seismic_hazard, or water_availability, and no exclusions or preconditions are mentioned. The agent must infer appropriate usage from the name and the one-line description alone.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context (the verification is anchored to a Bitcoin record), but it does not disclose behavior beyond that, such as failure modes, required preconditions, or what happens when the claim is not found.

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

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

The description is a single, front-loaded sentence with no filler or repetition. The main weakness is the slash ambiguity between 'claim' and 'ledger hash chain,' which slightly reduces precision without adding significant length.

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

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

For a simple one-parameter, read-only tool, the description is minimally viable: it names the operation and the anchor. Still, it omits usage guidance, return semantics, and parameter details, which are needed because there is no output schema and schema coverage is 0%.

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 0%, so the description needs to compensate. It never explains claim_hash's format, semantics, optionality, or relationship to a 'claim' vs the 'ledger hash chain.' The parameter name is suggestive, but not enough for an agent to confidently construct the value.

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

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

The description uses a specific verb ('Verify') and identifies a resource ('a claim / the ledger hash chain against the Bitcoin-anchored record'). However, the slash introduces ambiguity about whether it verifies a claim, a ledger hash chain, or a claim expressed as a ledger hash, and it does not clearly differentiate from siblings like check_hypothesis or ground_truth.

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?

No guidance is given on when to use this tool versus the many validation-related siblings (check_hypothesis, ground_truth, ground_stability). There are no exclusions, prerequisites, or alternative-selection cues, so an agent must guess which tool fits a given task.

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

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

Annotations already cover readOnly, idempotent, openWorld, and non-destructive behavior. The description adds meaningful context beyond those: the data source (GRACE groundwater trend), the two-tier behavior, and the 'non-locating' property of the authenticated atlas indication. This gives the agent useful behavioral expectations without contradicting 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?

Two sentences with no filler. The core purpose is front-loaded, and the second sentence concisely conveys the free-vs-authenticated distinction. Every clause adds 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?

There is no output schema, yet the description does not describe the return value's shape, resolution, or units. It also does not explain depth_m or how the point is interpreted. The tier behavior is helpful, but for a tool with four parameters and no output schema, this is not complete enough for confident invocation.

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 0%, so the description must compensate. It explains the authenticated parameter's meaning indirectly and implies lat/lon define the point, but depth_m is completely unexplained, and units or coordinate conventions are not given. This is only partial compensation for the schema gap.

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 resource (replenishable-water availability) and a clear scope (at a point). It implicitly distinguishes itself from sibling tools like ground_stability or seismic_hazard by focusing on water, but lacks an explicit verb or named sibling comparison, so it falls just short of a 5.

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

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

It gives useful tier-selection guidance: free tier uses public GRACE data, authenticated tier adds a derived atlas indication. However, it does not explicitly say when to choose this tool over alternatives like resource_indication or ground_stability, so usage guidance remains implied rather than explicit.

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