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

With no annotations, the description carries the disclosure burden and does so well: it states that no credentials are needed, identifies the automated processing methods, and lists the returned measurements and classifications. It stops short of discussing failure modes or operational constraints, though none are obviously critical for this analysis tool.

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

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

The description is well structured with a clear lead sentence, an Args block, a Returns block, and references. The references add scientific authority but are the least actionable part for an agent; overall the length is reasonable 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 six-parameter tool with no schema-level descriptions, the description supplies everything needed to invoke it: argument semantics, examples, defaults, output content, and authentication status. The presence of an output schema further reduces the need to document return structure, and nothing required for a correct call 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 0%, so the description is the only source of parameter meaning; it fully compensates by documenting all six parameters, including bbox order and CRS, date-range format examples, transect step units, collection options, and output formats. This is exactly the value the schema lacks.

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 action and object: 'Quantify coastal shoreline retreat and erosion rates (m/year) between two observation dates', and reinforces it with the method (MNDWI waterlines, DSAS transects). This is clearly distinct from sibling tools like simulate_sea_level_rise or detect_water_sar, and the pair of date ranges anchors the exact workflow.

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 a clear applicable context: multi-temporal analysis on open Sentinel-2 archives, zero-config, no credentials required, and a before/after date-range scenario. It does not explicitly state when not to use it or name alternative tools, so it falls short of a full routing guide.

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

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

No annotations are provided, so the description must carry the burden. It states the tool is zero-config and requires no credentials, which is useful, but does not disclose potential rate limits, data sources beyond the reference, or any limitations (e.g., reliance on cloud-free imagery). The description mentions the reference but not what happens with no data available.

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 structured with a clear intro, arguments, returns, and references. It is front-loaded with the core purpose and zero-config note. Every sentence adds value: the 'Returns' section informs the user of the output fields, and the reference adds scientific credibility. No fluff.

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

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

The output schema is present, so the description doesn't need to explain return format in detail, but it does anyway. It covers all parameters, zero-config requirements, and provides the data source reference. For a moderately complex tool with 4 parameters, this is complete. Missing details like coordinate range are minor given the schema's existence.

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 parameters. It does explain bbox, historical_year, recent_year, and format in simple terms, but it doesn't specify allowed values for format (summary, geojson, csv) or coordinate range for bbox. It adds meaning over the schema, which is good, but could be more explicit.

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 analyzes reservoir surface water shrinkage and drought dynamics using multi-temporal optical imagery, and names the specific EC JRC Global Surface Water parameters. It distinguishes itself from related tools like detect_water_sar by focusing on multi-year drought analysis rather than single-time water detection.

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 mentions 'Zero-config' and 'No credentials required', which implies ease of use without alternatives. It does not explicitly state when not to use it, but given the tool's unique focus on drought dynamics, the context is clear. It could name a sibling alternative but is not misleading.

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

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

With no annotations, the description carries the behavioral burden. It explicitly discloses the zero-config behavior, 'Streams public Landsat surface reflectance and thermal data without credentials,' and describes the return shape. It does not mention rate limits or side effects, but the tool is an analysis operation on public data and the disclosed auth/streaming behavior is materially useful.

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

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

The description is front-loaded with the core purpose and zero-config behavior, then cleanly structured into Args, Returns, and References. The References section with three full citations is arguably unnecessary for tool invocation, which keeps it from a 5, but the overall length and formatting are still reasonable.

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 fairly complex remote-sensing tool, the description covers the data source, authentication behavior, all parameters, and expected outputs (mean/min/max LST, UHI intensity, hotspot area, classification). The presence of an output schema and defaults in the input schema further reduces missing information, so an agent has enough to call 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 0%, so the description must fully document parameters. It does: bbox is defined as '[min_lon, min_lat, max_lon, max_lat] in WGS84,' datetime_range has a concrete example, and format enumerates all three allowed values ('summary', 'geojson', or 'csv'). This exceeds what the input schema provides.

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 states a specific verb+resource: 'Compute Land Surface Temperature (LST in °C) and map Urban Heat Island (UHI) microclimate hotspots using Landsat 8/9 Thermal Infrared (TIRS Band 10) and NDVI-derived surface emissivity.' This clearly distinguishes it from sibling EO tools because no other sibling is described as an LST/UHI analysis. It also names the exact data source and method, leaving no ambiguity about the tool's 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 gives clear usage context: use this tool when you need LST/UHI outputs from Landsat data, with examples such as 'Acquisition date window during warm season (e.g. '2024-06-01/2024-08-31').' It does not explicitly name alternatives or when-not conditions, but the context is strong enough for an agent to choose this tool over unrelated 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?

With no annotations, the description must carry full behavioral disclosure. It explains the internal pipeline (geocoding, discovery, filtering, modeling) and return format, and lists method references. Yet it omits key operational traits like requiring pre-configured credentials (a configure_credentials sibling exists), potential latency or rate limits, and whether large data downloads occur, leaving gaps for a complex tool.

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

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

The description is well-organized: purpose paragraph, args list, returns section, and references. It front-loads the aggregating purpose and then details each parameter, which is appropriate given the tool's complexity and 0% schema coverage. The references section adds scientific credibility but is arguably non-essential for invocation, making it slightly verbose.

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 8 parameters, no annotations, and an output schema, the description covers the parameter set thoroughly, provides examples, and states return format. Missing are prerequisites like 'configure_credentials must be called first' and potential error behavior, which would elevate it to a 5. Overall it is nearly complete for a turnkey analytical 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 0%, so the description is the only source. It documents all 8 parameters, including location format examples, an enumerated list of hazard_type values not present in the schema, datetime_range format, output format enum, defaults for water_level_rise_m/storm_surge_m, IPCC scenario presets, and the days lookback default. This makes the tool callable without external docs.

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 declares an 'Ergonomic All-in-One Planetary Hazard Assessment' that bundles geocoding, STAC discovery, scene filtering, and specialized hazard modeling into a single call. This clearly distinguishes it from specialized siblings like simulate_sea_level_rise or analyze_coastal_erosion, and the verb 'assess' plus resource (location/hazard) is explicit.

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 states the tool 'Replaces 4-6 manual tool calls' and bundles geocoding, STAC discovery, filtering, and modeling, which strongly implies use when a complete end-to-end hazard assessment is needed. However, it does not explicitly name sibling specialized tools or state when to prefer them instead, so the guidance is contextual 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?

With no annotations supplied, the description carries the full disclosure burden and adds significant value: it states zero-config access, streams public COG tiles without credentials, names the exact spectral bands, and describes the output. It does not discuss caveats such as cloud cover or data availability, leaving some behavioral detail implicit.

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

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

The description is front-loaded with a one-sentence purpose and then organized into Args/Returns sections, making it scannable. The academic references add credibility but are not needed for tool invocation, introducing a minor amount of 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?

Considering the tool has five parameters, no annotations, and an output schema that already exists, the description covers all call-relevant details: required and optional parameters, output content, standards, and access mode. An agent has everything needed 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 coverage is 0%, yet the description explains all five parameters with concrete examples: bbox format in WGS84, date range patterns (e.g., '2023-06-01/2023-06-30'), allowed collection values, and allowed format values. It fully compensates for the bare schema and clarifies optional defaults.

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 first sentence uses a specific verb 'Quantify' and names the exact resource ('post-fire burn severity and vegetation destruction'), method ('Normalized Burn Ratio Difference (dNBR)'), and data source ('Sentinel-2 NIR B08 and SWIR22 B12'). This clearly distinguishes the tool from siblings such as detect_active_wildfires or calculate_spectral_index.

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 establishes precise application context: post-fire assessment using pre- and post-fire date ranges and classification to USGS/EFFIS standards. It does not explicitly name alternative tools or exclusion scenarios, so it stops one step short of full 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the no-auth streaming approach ('Streams public COG bands via open HTTP range reads') and the return format ('JSON string with summary statistics, pixel count, and ASCII spatial density visualization'). However, it doesn't disclose failure modes such as behavior when the AOI has no data, what happens when cloud_cover filtering excludes all scenes, or performance implications for large bboxes. Decent but incomplete disclosure for a computational tool with zero annotation safety 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 purpose and Args section are well-structured and front-loaded. However, the References block (four academic citations: Rouse, Tucker, McFeeters, Key & Benson) adds substantial bulk with zero value for tool invocation — an agent doesn't need literature citations to call the tool correctly. That section could be trimmed without losing any operational 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 5-parameter complexity, 0% schema coverage, and zero annotations, the description is quite complete: it covers purpose, all parameter values/formats/defaults, and the return shape (though an output schema also exists). The main gaps are operational edge cases (empty AOI, all-scenes-filtered-by-cloud-cover, and error behavior), but the core information needed for a correct call is present.

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

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

Schema description coverage is 0% — the schema properties have no descriptions and no enums. The description fully compensates by documenting every one of the 5 parameters with concrete values and formats: collection ('sentinel-2-l2a' or 'landsat-c2-l2'), index ('NDVI', 'NDWI', 'NBR', or 'EVI'), bbox ('[min_lon, min_lat, max_lon, max_lat] in WGS84'), datetime_range ('2024-06-01/2024-06-30' example), and max_cloud_cover (default 15.0). This gives the agent everything the schema omits.

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 states a specific verb+resource: 'compute a spectral index (NDVI, NDWI, NBR, or EVI) for an Area of Interest'. It names the exact indices and collections supported, which distinguishes it clearly from compute siblings like calculate_burn_severity (focused on burn severity) and detect_water_sar (water detection). No ambiguity about what this tool does.

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 highlights 'Zero-config... No API keys or Copernicus account required', which implies this is the tool to use when credentials are absent, but it never explicitly names alternatives or gives when-to-use/when-not-to-use conditions. An agent must infer that, e.g., detect_dark_vessels or analyze_urban_heat_island are the right tools for other analyses rather than being routed to them. The zero-config note is a benefit statement, not a routing rule.

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

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

With no annotations, the description must carry the behavioral disclosure burden. It discloses the return format (JSON status with verified capabilities) and the benefits of providing credentials, but it does not state whether credentials are persisted, whether they overwrite existing settings, or how verification works. For a state-changing configuration tool, these are meaningful gaps, though the term 'configure' implies mutation.

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 efficiently organized: purpose, optionality, provider-specific argument details, and return value. Every sentence carries needed information, and the critical provider-argument coupling is presented in a scannable list. No filler or redundant restatement of the schema is present.

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 zero annotations and zero schema description coverage, the description provides robust context: provider-specific requirements, the public-access alternative, the unlock benefits, and the return format. It is slightly incomplete around persistence, error handling, and whether existing credentials are replaced, but the core invocation model is fully covered and an output schema exists to describe return structure.

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 fully compensates: it maps each provider value to its real-world service, specifies that username/password are required for CDSE, and defines token_or_key as an API token or subscription key for the other providers. This information is entirely absent from the input schema and is essential for correct invocation.

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-resource pairing—'Dynamically configure optional credentials'—and enumerates the four supported providers (CDSE, NASA Earthdata, Planetary Computer, FIRMS). It distinguishes itself from the sibling get_credential_status by focusing on configuration rather than reading status, and the optionality framing clarifies exactly what the tool does.

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 provides clear context for when configuration matters: 'Providing credentials unlocks official full-granule archive downloads and higher rate limits,' and explicitly notes that public access works without credentials. It implies the alternative is to skip configuration for public access, but it doesn't name other tools or state a direct when-not-to-use condition.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool as a read-only operation ('Retrieve'), which is consistent with the lack of destructive hints, but it doesn't disclose any side effects (e.g., whether it runs an analysis or just returns stored config), rate limits, authentication needs, or what happens if the recipe doesn't exist. This is a significant gap for a tool with no annotation support.

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

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

The description is concise and front-loaded with the core purpose in the first sentence. It includes a brief Args and Returns section for structure, with no filler or redundant phrasing. It could be slightly more compact, but it's efficient and well-organized.

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 single-parameter tool, the description is fairly complete. It explains what it returns (JSON string with recipe specification and step definitions) and provides examples. However, given the lack of annotations, it would benefit from clarifying whether it requires any sampling or validation and what the error behavior is. Since the output schema exists, return value details are partially covered, but the description's brief mention of return is still helpful. Overall, adequate but missing a bit of behavioral context.

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 0%, so the description must compensate. It does mention 'recipe_name' and provides two concrete examples, which adds meaning beyond the schema's bare property name. However, it doesn't explain the format (e.g., must match a recipe from 'list_pipeline_recipes'), which would help, so it partially compensates but is not fully sufficient.

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 retrieves detailed configuration, parameters, and step sequence for a pipeline recipe, which is a specific verb-resource pair. It is distinct from siblings like 'list_pipeline_recipes' (which likely lists recipes) and 'run_pipeline' (which executes), but it doesn't explicitly name these alternatives, so it's not a perfect 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?

The description implies usage by stating it retrieves configuration and parameters, which is appropriate when you need details of a specific recipe. However, it doesn't explicitly state when to use this over 'list_pipeline_recipes' (e.g., when you need the full recipe specification, not just a list) or when not to use it. No exclusions or alternatives are mentioned, so it's clear but not explicit.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It discloses the absence of required credentials and the open NASA FIRMS data source, which is useful. However, it does not mention side effects, rate limits, network dependence, or whether the operation is strictly read-only, though 'detect' implies it.

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

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

The operational part is structured well with Args and Returns sections, and the main purpose is front-loaded. However, three full academic citations with DOIs add substantial length and do not directly help an agent select or invoke the tool, so the description is not optimally concise.

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 four parameters, no schema descriptions, and no annotations, the description covers all required invocation details: parameter semantics, defaults, no-auth behavior, and expected returns. The output schema exists and covers return structure, so the missing details like output format specifics are not a serious 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 0%, but the Args block fully compensates by explaining every parameter: bbox order and WGS84 coordinate system, days range (1 to 10) and default, allowed source products, and allowed output formats. This is exactly the kind of semantic detail an agent needs beyond the bare 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-resource pair: 'Detect active wildfires and thermal anomalies from open NASA FIRMS feeds (VIIRS / MODIS)', and further narrows scope by mentioning clustered perimeters, Fire Radiative Power, and fire danger classification. This clearly distinguishes it from fire-related siblings like calculate_burn_severity.

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 clear usage context: it is for active wildfire detection from NASA FIRMS and emphasizes 'Zero-config' and 'No credentials or API keys required.' It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to select it over non-fire detection tools.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It does disclose several traits: zero-config, no credentials, public data usage, and the output categories (TRUSTED, DARK_VESSEL, SPOOF_OR_ABSENT) with oil slick alerts. However, it does not mention potential limitations (e.g., detection accuracy, processing time, error handling, or dependence on AIS availability). It also includes references to algorithm papers, which are not behavioral disclosures. Given the lack of annotations, a 3 is appropriate—it provides useful context but not a complete behavioral profile.

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 well-structured with clear sections (purpose, args, returns, references) and front-loads the core purpose in the first sentence. However, it includes a list of five academic references that are not necessary for an agent to invoke the tool correctly—these add noise. The overall length is justified by the parameter details, but the references could be pruned to improve 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?

Given the tool's complexity (7 parameters, no schema descriptions) and the presence of an output schema, the description covers all necessary input semantics, returns a summary of output categories, and mentions behavioral aspects like zero-config. It explains the purpose, parameters, and expected output formats. Nothing critical for calling the tool is missing—bbox format, date range syntax, AIS source options, and output choices are all specified. The output schema, not shown, likely provides the detailed return structure, so the description's return text is supplementary.

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?

With schema description coverage at 0%, the description must fully compensate, and it does. The 'Args:' section explains every parameter in plain language: bbox with coordinate order and datum, datetime_range with example, ais_source with options, pfa_factor with meaning (CFAR threshold), sea_state with options, custom_ais_records with required fields, and format with output formats. This is a textbook example of compensating for an undocumented 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 precise statement of functionality: 'Detect maritime vessels in Sentinel-1 SAR imagery and correlate them with open AIS transponder data to flag unreported ‘Dark Vessels’'. This clearly specifies the resource (SAR + AIS data) and the action (detection and correlation), and distinctly separates it from siblings like detect_water_sar (water vs vessels). It also adds the compliance context (MSFD Descriptor 8), which is a useful, specific qualifier.

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 notes 'Zero-config: Queries public Sentinel-1 and open AIS telemetry without credentials or API keys', which implies it is for users without credentials, but it never explicitly says 'use this tool when you need to detect dark vessels' or contrasts with alternatives. No when-not or exclusion criteria are given. The usage context is only implicitly conveyed via the zero-config mention; there is no direct guidance on when this tool is more appropriate than other vessel-detection utilities.

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

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

With no annotations present, the description carries the behavioral disclosure burden. It clearly states that the tool runs with zero configuration, requires no credentials, classifies pixels below a decibel threshold as water, and returns a JSON string with water percentage and backscatter characteristics. This goes beyond the bare function name and gives useful behavioral context, though it does not mention edge cases or 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 well-structured and front-loaded with the core purpose and zero-config behavior. The Args and Returns sections are compact and directly useful. The references add methodological credibility but are not strictly necessary for tool invocation, so it is concise but not perfectly lean.

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 three parameters, no annotations, and a schema with zero description coverage, the description covers everything needed to invoke it correctly: required inputs, optional threshold with default, return format, and the underlying method. An agent can confidently call this tool with just bbox and datetime_range based on the provided guidance.

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

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

The input schema has 0% description coverage, but the description fully compensates by explaining each parameter: bbox format and coordinate system, datetime_range with an explicit example, and threshold_db with its meaning and default value. This adds essential semantic meaning that the JSON schema alone does not 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?

The description opens with a specific verb and resource: 'Perform all-weather surface water and flood inundation mapping using Sentinel-1 C-band SAR radar backscatter.' This clearly distinguishes it from sibling tools like detect_dark_vessels or assess_location_hazard by naming the exact task and data source. It is not a tautology and provides enough specificity for an agent to know what the tool does.

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 clear context for when this tool is relevant: all-weather water and flood mapping with SAR. It also highlights a practical condition: zero-config and no API keys needed, which helps an agent decide to use it without credential setup. It does not explicitly name alternatives or exclusions, so it misses the highest bar, but the guidance is clear enough for selection.

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

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

No annotations exist, so the description carries the full burden. It discloses the tool's read-only discovery behavior, explains how query and category filters behave, and states that the return value is a JSON string listing tools, categories, descriptions, and the active profile. It does not discuss error cases or side effects, but this appears to be a safe search tool, so the gap is minor.

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 well structured: a one-sentence summary, a brief contextual note about progressive discovery, a category list, and an Args/Returns section. It is longer than necessary due to the category examples, but each part earns its place by making the tool's contents immediately understandable.

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 that an output schema exists and there are only two optional parameters, the description is complete enough for safe invocation: it explains the purpose, both parameters, the valid categories, and the response shape. It could mention behavior when no arguments are supplied, but the optional/default schema makes that reasonably clear.

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 0% and there are no enums, so the description must compensate. It does so thoroughly: 'category' is described as an optional category filter, 'query' is described as an optional keyword filter for tool names and descriptions, and the valid category values are enumerated. This gives the agent everything needed to use the parameters correctly.

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 starts with a specific verb and resource: 'Search and progressively discover eo-mcp tools across categories.' It clearly identifies what the tool does and differentiates it from the domain-specific sibling tools by positioning it as a discovery/metadata tool. The category list with tool examples further reinforces the tool's scope.

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

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

The description explains that this tool implements the client-side progressive discovery pattern (search, inspect, execute) recommended for MCP clients, which clearly signals when it should be used: as the first step before selecting and invoking domain tools. It does not explicitly name alternatives or state when not to use it, but the context is strong enough for an agent to infer correct 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?

With no annotations, the description carries the behavioral disclosure burden and does a good job: it reveals credential requirements, that the tool generates a URL and curl command rather than necessarily downloading directly, and that the return is a JSON string with a verified endpoint, authorization header, and execution instructions. It does not cover error cases or rate limits, but the core behavior is transparent.

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

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

The description is compact and well-organized: an action-oriented opening sentence, a credential prerequisite, an Args section, and a Returns section. Every sentence contributes useful information without redundancy or 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 single-parameter tool with an output schema, the description is largely complete: it explains the parameter format, credential prerequisite, and return contents. Missing details include what happens if credentials are absent or invalid and how the returned curl command should be executed, but these are reasonable gaps given the tool's simplicity.

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

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

The input schema only provides a string property with no description, so the description adds crucial meaning: product_id is an official Copernicus UUID or product name, and it gives a concrete real-world example format. This fully compensates for the 0% schema description coverage.

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: generate an authenticated download URL and curl command for a full Sentinel/Copernicus product package from CDSE. It distinguishes itself from siblings like stac_search or query_nasa_opera by focusing specifically on product-package download with credentials.

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 clear context: use this when you need to download an official Copernicus granule, and it explicitly notes the prerequisite of CDSE credentials configured via environment variables or configure_credentials(). It does not explicitly name alternatives or exclusions, but the purpose is specific enough for an agent to route correctly.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It explains that the tool computes a composite scorecard, returns a JSON string, and references specific indices and DEM data. However, it does not disclose potential execution cost/time, data availability limitations, whether any resources are created, or what happens when a location cannot be resolved.

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 well-structured with a numbered indicator list and clear Args/Returns sections, making it easy to parse. The academic references and the 'Create with Compute' phrasing add some noise but do not prevent efficient use.

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 tool with an output schema, the description covers the input semantics, default behavior, return type, and the four analytical layers. It is slightly incomplete in not distinguishing use cases from sibling tools and not explaining the 'Create with Compute' pattern, but overall it provides enough for an agent 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 coverage is 0%, but the description fully compensates by explaining all three parameters: location includes named examples and bbox syntax, datetime_range is described as an observation window with a default, and format lists the allowed output values. This goes well beyond the bare 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 states a specific verb and resource: 'Produces a holistic environmental and climate scorecard for any city or region' and enumerates four concrete indicator groups (NDVI, NDWI, DEM, thermal/flood hazard). This clearly distinguishes it from specialized sibling tools like detect_water_sar or calculate_spectral_index.

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 phrase 'holistic environmental and climate scorecard' implies this is for broad multi-layer audits rather than single-metric analysis, which gives some context. However, the description never explicitly states when to use this tool versus siblings such as assess_location_hazard, analyze_urban_heat_island, or detect_water_sar, and it offers no exclusion criteria.

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

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

No annotations are provided, so the description carries the full burden. It describes the return format (display_name, center, bbox) which is useful, but it does not state that the operation is read-only, nor does it mention any failure modes, rate limits, or authentication needs. For a geocoding tool, read-only behavior is likely obvious, but the description could be more explicit about non-mutating nature and error handling.

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

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

The description is concise, starting with the core action in the first sentence. It then neatly separates Args and Returns. Every sentence adds value, with no fluff. It is front-loaded with the main purpose and structured for quick scanning.

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 a single parameter and a described return format, the description is complete. It explains the input and output sufficiently for an agent to call it correctly. The presence of an output schema (not shown) further reduces the need to describe the return value in detail. Nothing essential 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?

The schema provides no description for place_name (coverage 0%), so the description must compensate. It does so thoroughly: 'Location name, city, or geographic feature' plus three examples ('Valencia, Spain', 'Lake Tahoe', 'Imperial Valley'). This gives the agent clear guidance on what input is acceptable, far beyond the bare schema.

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

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

The description clearly states the tool geocodes a place name into a WGS84 bounding box. It uses a specific verb (geocode) and resource (place name), and gives concrete examples. It stands out distinctly from all sibling tools, none of which are geocoding-related, so no confusion arises.

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: when you have a place name and need a bounding box or coordinates. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or mention that it is the go-to for geocoding among siblings. Since there are no similar siblings, this is not a critical gap, but the guidance is only 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?

With no annotations, the description must carry behavioral disclosure. It does reveal key behavior: optional output_json_path means it can write a file or return JSON, and it lists basemap choices and return shape. However, it does not mention side effects such as file overwriting, required credentials, or whether any external state is modified.

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 neatly structured: one-sentence purpose, bullet-style Args, and one-sentence Returns. Every line adds information and there is no filler.

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

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

Given five parameters and no annotations, the description covers the purpose, all parameter semantics, and return behavior, which is largely sufficient. It falls short only on edge behaviors like overwrite semantics and permission requirements, and it does not route the agent away from export_interactive_map.

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%, but the Args section documents all five parameters with meaningful detail: bbox order `[min_lon, min_lat, max_lon, max_lat]`, layers as JSON string or GeoJSON references, an example output path, and enumerated basemap themes. This fully compensates for the empty schema coverage.

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?

Opens with a specific verb ('Export') and a specific resource ('native GeoLibre project configuration file'), then names the exact target applications (GeoLibre Desktop Tauri / Web). The GeoLibre-specific resource and target apps distinguish it from the sibling export_interactive_map, so an agent can select it without schema inspection.

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 an explicit use context: one-click importing of eo-mcp analysis layers into GeoLibre, and it defines the output target. It stops short of naming alternatives or when-not-to-use conditions, so it is clear but not a full routing guide.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses side effects (optional 'save HTML directly to disk'), output form ('Confirmation JSON with file path and status, or HTML content preview'), and expected output characteristics. It does not discuss overwrite behavior or permissions, but for a generation/export tool this is reasonably transparent.

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

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

The description is well structured: a purpose sentence, a short feature list, an Args block, and a Returns block. It is not overly long, but the feature bullets (especially 'dark titanium glassmorphic UI overlay') are more promotional than necessary for tool invocation. Still, every section earns a place in helping the agent understand behavior.

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 five parameters, zero schema descriptions, and no annotations, the description covers all essential invocation details: required vs optional args, coordinate format, GeoJSON source, and return behavior. An output schema exists, so return values need not be deeply explained. Missing context is mainly the effect of hazard_type on rendering and any file overwrite semantics, but an agent can call this 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 entirely, and it does. It gives the exact bbox order ([min_lon, min_lat, max_lon, max_lat]), states WGS84, provides a title example, explains that geojson comes from eo-mcp hazard tools, lists example hazard_type values, and clarifies output_html_path's purpose. This is strong parameter documentation.

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: 'Generate a standalone interactive MapLibre GL JS HTML application from hazard results.' This clearly identifies both the action and the output. It does not explicitly contrast itself with the sibling export_geolibre_project, so it stops short of full sibling differentiation.

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

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

The description states that the tool generates maps 'from hazard results' and accepts GeoJSON 'from any eo-mcp hazard tool,' which implies when it should be used. However, it gives no explicit when-not-to-use guidance or comparison to alternatives such as export_geolibre_project.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully states that the result is a JSON string, accounts are masked for privacy, and it reports configured accounts plus unlocked APIs. This goes beyond a generic status description, though it could further clarify what 'zero-config mode' means or how failures are reported.

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 focused sentences, front-loading the main purpose and then clearly noting the return format. Every sentence adds value, and there is no redundant restatement of the tool name.

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 status tool with an output schema, the description is complete: it explains what is inspected, what the result contains, and that sensitive data is masked. No critical operational detail is missing for an agent to 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?

The tool has zero parameters, so there is no parameter-semantics burden on the description. The schema coverage is effectively complete, and the description adds relevant context about the output content without needing to explain parameters.

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 the specific verb 'Inspect' and clearly identifies the resource: 'current status of all satellite provider credentials, zero-config mode, and active capabilities.' This makes the tool's read-only purpose distinct from siblings like configure_credentials.

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 the tool is for checking credential/configuration status, but it does not explicitly state when to prefer this tool over configure_credentials or other siblings. Context such as 'before configuring credentials' or 'to verify setup' would improve routing, but the purpose is clear enough to infer 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?

With no annotations, the description takes on the behavioral burden and largely succeeds: it discloses the access mechanism (AWS STAC), explicitly states that no credentials are required, and summarizes the JSON return payload including slope statistics and an ASCII map. It falls short of 5 by omitting operational constraints such as bbox size limits or rate restrictions.

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

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

The description is front-loaded with purpose and organized with Args and Returns sections, making it scan well. The three references at the end add scholarly credibility but do not help an AI agent invoke the tool correctly, which prevents a 5.

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 tool with an output schema, the description is mostly complete: it names the data source, explains no-auth access, documents both parameters, and summarizes the return value. It omits potential constraints such as bbox size/area limits and does not explicitly state the default for calculate_slope, though the schema provides that default.

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 supply parameter meaning, and it does: bbox is specified as [min_lon, min_lat, max_lon, max_lat] in WGS84, and calculate_slope is explained as computing mean and maximum slope in degrees. This fully compensates for the minimal 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 action ('Extract') and a precise resource ('digital elevation (in meters) and terrain slope' from 'Copernicus DEM GLO-30'). This is clearly distinct from sibling EO tools like calculate_spectral_index or download_copernicus_granule without needing to inspect 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?

The description provides some useful context: it is zero-config, queries an open AWS STAC, and requires no API keys. However, it does not explicitly state when to choose this tool over alternatives like download_copernicus_granule, nor does it describe exclusions, leaving usage mostly implied.

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

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

With no annotations, the description carries the full burden and does disclose the primary behavior ('List') and the return format ('JSON string cataloging...'). However, it does not explicitly address side effects, authentication needs, or whether the list is static or dynamic—though 'List' implies read-only, it is not stated.

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 short sentences with no filler. The core purpose is front-loaded, and the return format is given in a clearly separated second sentence. Every word 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 0-parameter listing tool with an output schema, the description is nearly complete: it names the resource and specifies the JSON return contents. The only contextual gap is not pointing agents to describe_pipeline_recipe for recipe-level details, which would help navigation among sibling 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?

The tool takes 0 parameters, so parameter semantics are trivially covered by the empty input schema. The baseline of 4 for 0-parameter tools applies; the description adds no parameter information, but none is 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 uses a specific verb ('List') and a specific resource ('pre-built compound hazard and multi-spectral pipeline recipes'), making it immediately distinct from siblings like run_pipeline or describe_pipeline_recipe. It also states the return content, reinforcing what the tool is for.

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 on when to choose this tool over alternatives such as describe_pipeline_recipe (for details on a specific recipe) or list_supported_collections (for datasets). The description implies a browsing use case but never states exclusions or conditions.

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

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

With no annotations provided, the description carries the full burden. It clearly states the return format as a JSON string and enumerates the content, which gives an agent a concrete expectation. It does not mention side effects, but 'List' inherently implies a read-only operation, making this reasonably transparent.

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

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

The description is extremely concise: one purpose line and one return line. It is front-loaded with the main action and uses no filler, making it easy to parse quickly.

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 tool, the description is complete: it states what is listed, the return type, and the scope ('available in eo-mcp'). An output schema exists, so the agent can rely on it for exact structure. No critical operational detail 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?

The tool has zero parameters, so schema coverage is trivially 100% and no parameter description is needed. The description adds no parameter details because there is nothing to add; baseline 4 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 and resource: it lists supported open satellite collections, spatial resolutions, spectral bands, and STAC sources. However, it does not explicitly distinguish itself from related siblings like stac_search or discover_eo_tools, so it misses the sibling-differentiation aspect 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?

The intended use is implied by the description—call it when you need to know which collections are supported—but there is no explicit when-to-use vs. alternatives guidance. No exclusions or comparisons to sibling tools are provided, leaving usage context 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?

With no annotations, the description carries the full burden and does well: it discloses the data sources, that no API keys are needed, that it correlates satellite measurements with ground stations, and what outputs are produced. It does not cover rate limits, latency, or failure behavior, which keeps it just short of a 5.

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

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

The definition is well-structured and front-loaded, with the core purpose in the first line followed by a compact Args/Returns breakdown. Minor redundancy in the Zero-config sentence and the appended references add a small amount of nonessential weight.

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 four parameters, no annotations, and moderate scientific complexity, the description covers the main context: purpose, data sources, credential-free access, return contents, and parameter semantics. It could still explain what each output format yields and mention limitations like temporal availability.

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%, but this description compensates fully by documenting every parameter: bbox order and CRS, gas choices and default, datetime_range format with an example, and format options. This goes well beyond the bare 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: 'Monitor atmospheric trace gas emissions' using Sentinel-5P TROPOMI and OpenAQ validation, and names the exact gases (NO2, SO2, CO, CH4). This clearly distinguishes it from sibling monitoring/detection tools such as detect_active_wildfires or monitor_crop_phenology.

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 tool's intended use is implied strongly by the purpose and the 'Zero-config' line, which tells agents no credentials are required. However, it never explicitly states when to prefer this tool over alternatives or what conditions would make a sibling tool more appropriate, so guidance is only implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add context by noting 'Automatically samples cloud-free Sentinel-2 observations' and 'Zero-config,' which tells the agent the tool handles data selection. However, it does not mention any limitations, processing time, data availability constraints, or whether the operation is purely read-only in terms of external side effects.

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 well-structured with clear sections: purpose, args, returns, references. The essential information is front-loaded. The scientific references at the end add credibility but do not help an agent select or invoke the tool, so they keep it from a perfect conciseness score.

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 has an output schema and only one required parameter, the description is largely complete: it covers all parameters, the return summary, and the automatic Sentinel-2 sampling behavior. However, it omits details like valid year ranges, bbox size limits, or error conditions, which would be useful for an agent handling edge cases.

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

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

Schema description coverage is 0%, but the description's Args section fully compensates. It explains bbox format (WGS84 coordinates), year default, crop_type examples, and format enum values ('summary', 'geojson', 'csv'). This gives the agent everything needed to set each parameter correctly, far beyond the bare 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: 'Monitor agricultural crop phenology, growth trajectories, and vegetative anomalies across seasonal cycles.' It further specifies exact outputs (SOS, POS, EOS, drought stress vs baseline), making it clearly distinct from sibling tools like calculate_spectral_index or analyze_reservoir_drought. An agent can confidently recognize this as the tool for crop growing-cycle analysis.

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 clear context: use this tool when you need to monitor crop phenology, seasonal growth, or vegetative anomalies. The 'Zero-config' note suggests it is a turnkey option, but it does not explicitly mention when not to use it or name alternative tools, so it stops short of full guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the return format (JSON string with granules, asset URLs, coverage metadata) and describes what the tool does, but it does not mention pagination, error behavior, authentication requirements, or any side effects. It is read-only in nature but this is not explicitly stated, and the description lacks deeper behavioral detail that would be expected without 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 well-structured with clear sections for Supported Products, Args, and Returns. It is front-loaded with the purpose and each section is concise, providing necessary detail without verbosity. The only minor excess is the repetition of '30m' in product descriptions, which is not wasted but could be considered slightly 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?

Given the tool's complexity (6 parameters, 3 product types, output schema present), the description is nearly complete. It covers the product catalog, parameter semantics, and return type. The presence of an output schema means the description need not detail return values, but it still provides a high-level description of the return. Missing elements include any mention of authentication, rate limits, or data availability constraints, but these are minor for a query tool of this nature.

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 0%, so the description must fully compensate. The description includes an explicit 'Args:' section that explains each of the six parameters (bbox, datetime_range, product_type, max_cloud_cover, limit, format) with clear meaning, units, and examples for datetime_range. This is comprehensive and adds substantial value beyond the bare 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 it searches and inspects NASA JPL OPERA datasets, and enumerates the three supported product types (dswx, dist, rtc) with their specific purposes. This is a specific verb+resource with a defined scope that distinguishes it from generic STAC search tools and other sibling detection 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 provides no explicit guidance on when to use this tool versus alternatives like stac_search or detect_water_sar. It lists the products it supports but does not mention exclusions or alternative conditions that would route an agent to a different tool. The usage context is only implicit from the product descriptions.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses the supported SQL subset, spatial predicates, and the JSON return shape, which is substantial. It does not explicitly state whether execution is read-only/in-memory or describe error behavior, but the query semantics are clearly scoped.

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

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

The description is compact, front-loaded with purpose, and organized into Supports, Args, and Returns sections. The example SQL query is illustrative rather than padding, and every sentence earns its place.

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

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

All three parameters are explained, the input data source is specified, supported operations are enumerated, and the return format is defined. For a self-contained query tool with no annotation coverage, an agent has everything needed to select and 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 0%, but the Args section fully compensates. The sql parameter includes a concrete example, geojson specifies a GeoJSON FeatureCollection sourced from eo-mcp tools, and table_name explains the virtual table concept and its default value. Every parameter's meaning is clear.

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: 'Execute spatial SQL queries on GeoJSON FeatureCollections or tabular geospatial metadata.' It then enumerates the supported SQL and spatial predicates, making the tool's function unambiguous and distinguishing it from the many geospatial analysis 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?

It gives clear context: use this tool when you need SQL-style filtering, grouping, ordering, or spatial calculations over GeoJSON produced by any eo-mcp tool. It does not explicitly name alternative tools to avoid or state when-not-to-use conditions, so it stops short of the strongest guidance.

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

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

With no annotations, the description carries the burden of disclosing behavior. It usefully mentions the sandbox environment, pre-loaded libraries, and JSON response containing status, stdout, stderr, and exported variables. However, it omits safety and limitation details for arbitrary code execution, such as sandbox restrictions, timeouts, or filesystem/network access.

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

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

The description is compact and front-loaded with the main purpose. The Args and Returns sections are concise and directly useful, with no filler.

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

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

For a one-parameter arbitrary-code tool, the environment and return contract cover most operational needs, and an output schema exists for return details. The main gap is the lack of explicit sandbox limitations, but the description is otherwise reasonably complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does: script_code is defined as 'Valid Python code string to execute,' and the preloaded libraries give concrete context about what the code can use. It does not explain the export mechanism precisely, but the single parameter is sufficiently clarified.

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: 'Execute an arbitrary agent-generated Python geospatial processing script.' It effectively distinguishes this from sibling pipeline tools like run_pipeline and list_pipeline_recipes by emphasizing arbitrary agent-generated code rather than predefined recipes.

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 this tool is for free-form Python execution, but it does not explicitly name alternatives or exclusion conditions. An agent must infer when to use run_geospatial_script versus run_pipeline or other sibling tools.

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

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

With no annotations, the description carries the behavioral burden. It explains what happens (pipeline execution, returns a formatted summary, GeoJSON, or CSV) and notes there is no self-hosted infrastructure. However, it does not disclose side effects, compute/quota implications, or failure behavior, which would be useful for an execution tool.

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

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

The description is long, but the length is justified by a complex tool: purpose, recipes, step vocabulary, args, and returns are clearly separated. A short opening sentence front-loads the core purpose, and the enumerated lists are scannable; some marketing phrasing like 'Empowers users and AI agents' adds little.

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 tool with 0% schema coverage and no annotations, the description covers the essentials: valid recipe names, available pipeline steps, parameter formats, and return types. It does not specify detailed schemas for custom JSON steps or error/edge-case behavior, but the provided output schema and sibling tools reduce that 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 0%, but the Args section fully compensates: spec is explained with recipe names and JSON-structure options, location gives both a name and bbox format, format enumerates the three output options, and parameters provides a concrete JSON override example. This exceeds what the bare schema offers.

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 uses a specific verb-resource combination: 'Execute a declarative multi-step Earth Observation processing pipeline or pre-built recipe.' It clearly separates the tool from single-step EO tools and from discovery siblings like list_pipeline_recipes by framing it as execution of a full pipeline.

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

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

The description provides strong contextual guidance: it lists four ready-made recipes and explains that a custom declarative JSON can be supplied instead. It does not explicitly name alternatives or say when not to use this tool, but the recipe/step lists make the intended use obvious.

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

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

No annotations are provided, so the description carries the full burden. It discloses the data source, streaming from open AWS STAC, lack of credentials, modeling approach, and output formats. It omits potential performance limitations or edge-case behavior, but it provides substantial behavioral context beyond the bare schema.

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

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

The opening sentence is specific and front-loaded, and the Args/Returns structure is easy to parse. The references add credibility but are not strictly operational; still, the description is efficiently organized and not bloated.

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 schema descriptions and no annotations, the description covers required inputs, optional parameters, return fields, and methodology. It does not mention bbox size limits, processing time, or failure modes, but it is complete enough for correct 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%, and the description fully compensates by explaining every parameter: bbox order, water_level_rise_m and storm_surge_m units and defaults, scenario allowed values, and format options. This goes well beyond the sparse schema information.

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 action: 'Simulate coastal sea-level rise and storm surge inundation using Copernicus DEM GLO-30 and hydrologically connected flood-fill modeling.' It is clear about the resource and method. However, it does not explicitly distinguish this from sibling tools such as assess_location_hazard or analyze_coastal_erosion, so it falls 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?

The description implies usage for coastal flood simulation with zero-config and EU Floods Directive compliance, and it notes no API keys are required. It does not explicitly state when to use this tool versus alternatives or provide exclusions, so guidance is only 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.

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

No annotations are provided, so the description carries the full burden. It does disclose the zero-credential/no-auth behavior and, in the Returns line, the response shape (JSON of scenes, dates, cloud cover, asset keys). But for an external network tool it omits explicit disclosure of outbound network dependency, latency, rate limits, and failure behavior - exactly the context an agent needs before invoking a third-party API.

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?

Well-structured with a front-loaded one-sentence purpose, a terse zero-config note, then clearly labeled Args and Returns sections. The detail in Args is justified for a six-parameter external API tool, and every section earns its place without fluff.

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

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

For a 6-parameter external STAC search with an output schema, the description covers purpose, auth model, all parameter semantics, and return format - the essentials for correct invocation. It falls short only on operational disclosures (error handling, rate limits, latency) that would round out full completeness.

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% (properties carry only titles, no descriptions), so the description must compensate - and it does. The Args section documents all six parameters with formats, examples, and coordinate systems (e.g., bbox in WGS84, datetime_range RFC3339 with examples, max_cloud_cover 0-100). Minor gaps: bbox doesn't state it needs exactly 4 numbers and collections isn't cross-referenced to list_supported_collections for valid IDs.

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-resource pair ('Search free STAC catalogs for available satellite scenes') and names the three filtering criteria (spatial, temporal, cloud), which clearly distinguishes it from siblings like list_supported_collections (list only) and download_copernicus_granule (download vs search). No ambiguity about what this tool does.

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 'Zero-config: Queries public STAC endpoints with zero credentials or API keys required' note implicitly tells an agent this is the right tool for public, credential-free data access and implies credentialed data belongs elsewhere. However, it never names alternatives or gives explicit when-to-use / when-not-to-use guidance against siblings like query_nasa_opera or query_spatial_sql, leaving routing partially to inference.

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