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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds almost nothing beyond naming the source and temporal scope; it does not disclose that results default to Earth-bound approaches within 60 days, which is meaningful behavior for an open-world query.

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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though it is arguably too terse to carry any real signal for a 13-parameter tool.

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

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

Given 13 optional parameters, no output schema, and an open-world query, the description is thin. The schema documents defaults and formats, but nothing tells the agent what the response contains (record fields, distance units in output) or how the heavily parameterized filtering composes.

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

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

Schema description coverage is 100% across all 13 parameters, including defaults, units, and patterns, so the schema does the heavy lifting. The description contributes no additional parameter meaning, which is the baseline-3 case.

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 concrete resource (asteroid/comet close approaches to planets), the temporal scope (past and future), and the upstream source (JPL SBDB Close-Approach Data API). It does not explicitly distinguish itself from the sibling jpl_sbdb beyond the 'close approaches' framing, 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as jpl_sbdb for general small-body lookups. The agent must infer that this is the close-approach query tool from the description text alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the data provenance (US Government sensors), which is useful context, but says nothing about return format, ordering, or pagination behavior for a 13-parameter query 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?

A single efficient sentence with the resource and source front-loaded. Nothing is wasted, though it is arguably too short to be maximally useful.

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?

Annotations cover safety and the schema fully documents parameters, but for a tool with 13 filter parameters and no output schema the description never hints at the filtering/faceting capability an agent would need to know it can narrow results. Adequate but with a clear gap.

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

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

Schema description coverage is 100% with all 13 parameters individually documented, so the schema does the heavy lifting. The description adds no additional meaning about filters, ranges, or the date/velocity/energy semantics beyond what the schema already states.

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 resource (fireball/bolide events) and names the data source (JPL Fireball API) and provenance (US Government sensors). It is clearly distinct from orbital-element siblings like jpl_sbdb or jpl_horizons, though the verb is implicit rather than stated.

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 on when to use this tool versus alternatives, and no mention of the rich filtering capability that would be the main reason to select it. The agent must infer usage entirely from the name and schema.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds essentially nothing beyond corroborating the GET/read nature; it does not mention rate limits, that MAKE_EPHEM must be set to get an ephemeris, or response size characteristics.

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?

A single efficient sentence with the resource front-loaded and no filler. It is appropriately sized, though it is arguably too terse for an 11-parameter NASA API tool.

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

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

This is a complex tool with 11 parameters, 5 enums, and no output schema, yet the description never explains how the parameters combine (e.g., MAKE_EPHEM=YES plus EPHEM_TYPE to get an ephemeris). Full schema coverage and annotations mitigate somewhat, but the description leaves meaningful behavioral gaps for a tool of this complexity.

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

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

Schema description coverage is 100%, with enums and examples on every parameter, so the schema carries the full semantic load. The description adds no parameter guidance beyond what is already documented, which is the baseline-3 case.

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 resource and action: 'Ephemerides and object data for solar-system bodies from the JPL Horizons API (GET)'. An agent can tell it serves Horizons queries, but it does not distinguish itself from the closely related sibling jpl_horizons_file or explain what 'object data' covers versus a pure ephemeris.

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 when-to-use guidance, prerequisites, or exclusions. With siblings like jpl_horizons_file, jpl_sbdb and jpl_cad all serving solar-system body queries, the description offers no routing signal for choosing this tool over them.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the transport detail (POST to horizons_file.api), which is useful but not behaviorally rich, and says nothing about the expected payload structure or rate limits.

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?

A single tight sentence with the distinguishing constraint front-loaded; no filler. It is efficiently sized, though its brevity is partly what leaves the file-format payload unexplained.

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 an 11-parameter tool with full schema coverage and no output schema, the description is barely adequate. The one genuinely distinguishing feature – what a 'Horizons input file' payload must contain – is asserted but never described, relying entirely on the sibling tool.

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

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

Schema description coverage is 100% with 11 documented parameters and 5 enums, so the schema carries the semantic burden. The description adds no parameter-level meaning beyond what the schema provides, making the 3 baseline correct.

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

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

The description identifies the resource (JPL Horizons ephemerides) and precisely differentiates it from its sibling, stating it is 'same as jpl_horizons, but submits the parameters as a Horizons input file'. An agent can tell the two apart by the submission mechanism, though the core verb (query/fetch) is implied via the cross-reference rather than stated directly.

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 'but submits ... as a Horizons input file' clause implies the scenario for choosing this over jpl_horizons (file-based input), but it never explicitly states when to prefer one over the other or any prerequisites. Usage is inferable from the sibling comparison but not spelled out.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered. The description only adds the '(UTC)' timezone and API name, but says nothing about return format, error behavior, or whether both params may be sent simultaneously.

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?

A single front-loaded sentence that states verb, resource, timezone, and API with zero filler. Nothing can be trimmed without losing information.

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

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

For a simple two-param converter with full schema coverage and no output schema, the description is close to adequate. However it omits the interaction rule between the two optional parameters, which an agent needs in order to invoke the tool correctly.

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

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

Schema description coverage is 100%, so both parameters are already documented by the schema patterns and descriptions. The description adds no syntax, format, or mutual-exclusivity detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb ('Convert between') and specific resources ('Julian dates and calendar dates (UTC)'), and names the backing API. This is unambiguous and no sibling tool overlaps the date-conversion domain, so differentiation is implicitly satisfied.

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

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

The description gives no when-to-use context and, critically, no guidance on which parameter to supply. Since both 'cd' and 'jd' are optional and non-required, an agent gets no help deciding whether to provide one or both, or what happens with neither.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds real context: object mode returns pre-computed stored options rather than computing on demand, list mode is ranked by crit, and two API modes are deliberately unexposed. It does not discuss rate limits or result-size behavior for list mode.

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

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

Three tight sentences, front-loaded with the API identity, then mode behavior, then explicit exclusions. No filler and nothing repeated from the schema verbatim.

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 13-parameter, zero-required, read-only tool with no output schema, the description covers the mode selection that the flat schema cannot express and rules out two unimplemented modes. Return contents are named for object mode but list-mode record fields (other than crit ranking) are left implicit, which is a minor gap.

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

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

Schema coverage is 100%, so every parameter is already documented in the schema, making 3 the baseline. The description reinforces the mode split (which params belong to object vs list mode) and notes that JPL defaults year to the next five years, but it does not clarify the mutually exclusive nature of des/spk/sstr or how list-mode filters combine.

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: ballistic mission options to asteroids and comets from the JPL Small-Body Mission Design API, then enumerates its two operating modes (object vs list). An agent can tell what it returns (launch/arrival dates, V-infinity, time of flight) without opening the schema. It never names a sibling tool, so it is clear but not explicitly differentiated from jpl_scout or jpl_horizons.

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?

Clear routing logic: use object mode (des/spk/sstr) for one stored object and list mode for ranked accessible bodies by launch year. It explicitly rules out unsupported work by stating porkchop maps (mode M) and mission-extension searches (mode T) are not exposed, which prevents wasted calls. No guidance on when to prefer this over the neighboring mission/accessibility siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered externally. The description adds only a light behavioral note that the list is 'constrained' and that object mode exists; it says nothing about filtering behavior, result size, or the cost of the plot option beyond what the schema notes.

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?

A single front-loaded sentence with no filler. It is efficient, though the deliberately terse phrasing leaves useful detail (mode switching rules) on the table.

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 9-parameter, no-required-arg tool with a rich schema but no output schema, the description should clarify how filters apply only in summary mode and how des/spk trigger object mode. It gestures at the two modes but does not fully explain the parameter-to-mode relationship.

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

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

Schema description coverage is 100% across all 9 parameters, so the schema already documents ranges, enums, and modes (des/spk for object mode). The description only echoes the des/spk names and adds no syntax or interaction detail, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific resource (NHATS-accessible NEOs) and verb-ish operation (list or fetch one by des/spk), which is enough to distinguish it from nearby siblings like jpl_neo and jpl_scout. It is clear but does not explicitly contrast itself with those 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?

The description notes two modes ('constrained summary list, or one object by des/spk') but gives no when-to-use guidance, no prerequisites, and never names an alternative tool for comparison. The mode distinction reads as capability, not usage direction.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds no behavioral context beyond that—no mention of result volume, pagination, or how the database's optional family-dependent parameters behave.

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?

A single front-loaded sentence with no filler; the resource and source are stated immediately and the family examples are compact.

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

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

With 11 parameters (9 optional filters) and no output schema, the description is too thin: it never explains that libr/branch are conditionally required by certain families, nor how the numeric range filters combine. Much of what an agent needs to call this correctly must be reconstructed from the schema alone.

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

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

Schema description coverage is 100%, so every one of the 11 parameters is already documented with examples, ranges and enums. The description adds no syntax, unit, or semantic detail beyond the schema, so baseline 3 applies.

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

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

States the resource (periodic orbits in three-body systems) with concrete family examples and names the authoritative source database. It is distinguishable from siblings like jpl_horizons or jpl_mission_design, though the retrieval verb is implicit rather than 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?

No guidance on when to use this tool versus alternatives such as jpl_horizons or jpl_mission_design, and no prerequisites or exclusions are stated. The agent must infer applicability from the resource name alone.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive, covering the safety profile. The description adds only the single-object scope, and omits whether an identifier is mandatory, how missing objects are reported, or the deprecated-flag behavior.

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?

A single front-loaded sentence with no filler. Every word carries information about resource, scope, and source.

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

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

For a 12-parameter tool with no required fields and no output schema, the description is far too thin: it never says how to identify the object (sstr/des/spk) or how the boolean include-flags interact. An agent would have to reverse-engineer invocation from the schema alone.

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

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

Schema description coverage is 100%, so all 12 parameters are already documented, including the deprecation of 'cad'. The description adds no parameter syntax or interaction detail (e.g. that ca_body needs ca_data), so baseline 3 applies.

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

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

States a specific resource (orbital and physical data) and scope (one asteroid or comet) from a named database, so the agent knows what it gets. It does not differentiate from siblings such as jpl_sentry, jpl_cad, or jpl_horizons, which surface overlapping small-body data.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g. that an identifier must be supplied), and no routing to alternatives like jpl_horizons or jpl_sentry. The agent must infer usage entirely.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds the useful context that the objects are unconfirmed NEOCP entries (implying unstable/short-lived data), but says nothing about response shape, plot encoding, or compute cost of sampling orbits.

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?

A single front-loaded sentence that identifies the domain, the data source, and the analytical output with zero filler.

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

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

With no output schema and a dual-mode design (list mode via limit vs object mode via tdes/file/plot/orbits), the description should explain the two invocation modes and what each returns. It never mentions modes at all, leaving an agent to infer everything from parameter names.

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

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

Schema description coverage is 100%, so all six parameters are already documented, including the list/object mode distinctions and enum constraints. The description adds no parameter detail beyond what the schema provides, which is the expected baseline.

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

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

Specific verb+resource ('trajectory analysis and hazard assessment') applied to a specific target set ('unconfirmed objects on the NEOCP'). It is clearly distinct from confirmed-object siblings like jpl_sentry or jpl_sbdb, though it never names those siblings to sharpen the boundary.

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 statement of when to use this tool versus jpl_sentry, jpl_nhats, or jpl_sbdb, and no mention of prerequisites (e.g., that NEOCP objects are unconfirmed and may vanish). The implicit list-vs-object mode split is left entirely to the schema.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the enumeration of result modes, which is modest added context; it says nothing about rate limits, upstream Sentry availability, or result size behavior (the server-side limit is only disclosed in the 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?

A single compact sentence with the source and the mode list front-loaded; nothing is wasted. It is arguably too terse for eight interacting parameters, but there is no filler to trim.

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

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

With eight optional parameters, no required fields, no output schema and mutually exclusive mode combinations, the description is only minimally sufficient: it names the modes but does not explain that parameters are mode-gated or how the modes relate to each other. The rich schema compensates, keeping this adequate rather than poor.

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

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

Schema description coverage is 100% and the schema descriptions are unusually informative, including mode labels, examples (e.g. '29075 or 2011 AG5', '1e-5') and the note that limit is applied by this server. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific resource (Earth impact risk assessments from JPL Sentry) and enumerates the four output modes: summary table, single object, virtual impactors, removed objects. That is far more than a restated title. It does not, however, differentiate itself from the nearby jpl_scout or jpl_nhats siblings, which also concern impact risk, so an agent cannot route between them from this text alone.

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?

Listing the modes implies which parameter combinations to use, and the schema descriptions carry the actual mode mapping ('Object mode:', 'Summary/VI mode:'), but the description itself gives no when-to-use guidance, no prerequisites, and no statement of when to prefer a sibling such as jpl_scout. Usage is inferable rather than stated.

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

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

Annotations already declare readOnly, idempotent, openWorld, non-destructive; the description adds genuinely new behavioral facts: no API key is required, the date range is capped at 100 days, and images are embedded up to max_images with the rest listed by URL. It doesn't mention rate limits or error handling, so it's not 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?

A single dense sentence, front-loaded with the source and access modes, then the return shape and the no-key note. No filler, though the packing of modes, bounds, and outputs into one sentence makes it slightly heavy.

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

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

With no output schema, the description steps in to describe return fields (title, credit, plain-text explanation, image/video URL, page link) and the embedding behavior. Combined with mode constraints and the no-key note, an agent has everything needed 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 coverage is 100%, so baseline is 3, but the description adds a constraint not present in the schema: the date range cannot exceed 100 days. It also summarizes the date/range interaction, giving real value beyond the schema text.

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

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

States a specific verb+resource (retrieves NASA's Astronomy Picture of the Day from the NASA Science APOD API) and enumerates the three access modes: latest, single date, or range. This clearly separates it from siblings like nasa_images and nasa_epic.

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

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

Explains the three usage modes and the 100-day range limit, plus the 1995-06-16 lower bound. It does not explicitly say when to prefer this over nasa_images or nasa_epic, so it stops short of full alternative routing.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: compact envelope is the default with raw for upstream metadata, cursor-based Search After pagination semantics, and 'No API key needed' (auth requirement).

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

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

Purpose is front-loaded in the first sentence and each subsequent sentence carries distinct payload (filters, response mode, pagination, caveat, auth). It is dense but every clause earns its place; only the filter enumeration is slightly list-like.

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?

An output schema exists so return values need not be explained, yet the description still clarifies the compact-vs-raw envelope and the next_cursor contract. Combined with the auth note and the granules caveat, an agent has everything needed 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 100%, so the 39 parameters are fully documented structurally; baseline 3 applies. The description usefully groups the filter families (identifiers, temporal/spatial, platform/instrument/project, facets, sorting) and flags the compact/raw response_mode behavior, but adds no syntax beyond the schema.

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

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

States a specific verb (Search) plus the exact resource (NASA's Common Metadata Repository) and the two search domains (collections/datasets vs granules/files). Among siblings it is the only CMR metadata-search tool, so an agent can place it immediately.

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

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

Gives practical usage direction: continue pagination by passing only {"cursor": next_cursor}, and warns that collection matches do not prove granules exist for a time/place. It does not name explicit when-not-to-use scenarios, but no sibling tool overlaps enough to require exclusion guidance, so 4 is fair.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description still adds real value beyond them: no API key required, the 30-day request ceiling, and that response_mode=raw yields large payloads specifically for cme, cmea and wsa. It stops short of describing pagination or rate-limit behavior, which keeps it out of 5 territory.

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?

A single front-loaded paragraph that names the source and the primary constraint first, then the type list and response modes. It is dense but every clause carries information; the long event-acronym roster is the only slight 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?

There is no output schema, so the description reasonably covers return shape by explaining compact vs raw. Combined with rich annotations and full schema coverage, an agent has enough to invoke correctly; only the absence of error/empty-result behavior keeps it from 5.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema, and the description largely restates them (event types, compact vs raw). The 30-day window nuance is the only added semantics, so the baseline 3 is appropriate.

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

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

States a specific resource (DONKI space weather events) with the exact event-type taxonomy and names the upstream source (NASA CCMC DONKI API). An agent can immediately tell this apart from siblings like nasa_neo or jpl_fireball, which cover unrelated datasets.

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 'up to 30 days at a time' window implies a date-range use case, and enumerating the solar-flare/CME/storm event types hints at when the tool applies. However, there is no explicit when-to-use, no alternative named, and no exclusion guidance for an agent choosing among the 30 sibling NASA/JPL 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral note — filters are passed through verbatim with no automatic broadening — but says nothing about result ordering, pagination, or response shape.

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 zero filler; the resource and its scope lead, and the filter-behavior caveat follows. Nothing could be trimmed without losing information.

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

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

For a read-only query tool with fully documented optional parameters and no output schema, the description covers what the tool is but omits how results are returned and how it relates to overlapping siblings. Adequate, but with clear gaps.

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

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

Schema description coverage is 100%, so all five parameters (days, limit, source, status, category) are already documented with defaults, ranges, and examples. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

The description names a specific resource (natural events) and its origin (Earth Observatory Natural Event Tracker) with illustrative examples (wildfires, storms, volcanoes, ice). It is clear what the tool returns, though it does not distinguish itself from the similar sibling nasa_firms, which also covers fire/thermal events.

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

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

There is no when-to-use guidance, no mention of alternatives among the many NASA siblings, and no indication of when this source is preferable to nasa_firms or nasa_donki. The only guidance given concerns filter strictness, not tool 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: every image's metadata is returned while only a bounded number are embedded as JPEGs, which shapes expectations about response size. It says nothing about rate limits or the upstream DSCOVR availability window.

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?

A single front-loaded sentence with a colon-delimited clause that puts the resource first and the return shape second. No filler, though the parenthetical instrument expansion makes it slightly dense to parse.

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 optional and fully documented in the schema, and the description covers what comes back (full metadata, bounded embeds). With no output schema, it adequately sets expectations for a read-only imagery lookup; only upstream availability caveats are absent.

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

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

Schema description coverage is 100%, so date, collection and max_images are fully documented in the schema, including defaults and the 0-3 bound. The description only vaguely gestures at 'a bounded number embedded' and 'for a day', which the schema states more precisely, so it adds little beyond the structured fields.

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

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

Names the specific instrument (Earth Polychromatic Imaging Camera on DSCOVR) and the resource (full-disc Earth images for a day), and states what the response contains: metadata for every image plus a bounded number embedded. It does not explicitly distinguish itself from siblings like nasa_images, nasa_apod or nasa_gibs, but the instrument naming makes the scope identifiable.

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

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance. 'For a day' implies the retrieval context, but an agent choosing between nasa_epic, nasa_images and nasa_apod gets no routing help from the description.

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

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

The annotations already declare the full safety profile (readOnly, idempotent, non-destructive, open-world), so the description's marginal burden is low. It usefully adds that access goes through the TAP/ADQL service and that table names must be current, but says nothing about rate limits, result size behavior, or 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?

Two tight sentences, front-loaded with the core action and service, no filler. The second sentence is slightly redundant with the table parameter description but still earns its place by clarifying valid TAP names.

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, fully documented query tool with no output schema, the description is adequate but thin. It never states the return shape or that results are tabular rows from the selected columns, and gives no orientation on ADQL restrictions, leaving the agent to infer behavior from the schema alone.

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

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

Schema coverage is 100%, so every parameter is already documented with examples (ADQL WHERE, ORDER BY, select list, format enum, limit bounds). The description repeats the table-name semantics rather than adding new meaning beyond the schema.

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

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

States a specific verb (query) and resource (NASA Exoplanet Archive) via a named service (TAP/ADQL), and identifies the table namespace. It distinguishes the tool well from other NASA siblings by pointing at the Exoplanet Archive specifically, though it doesn't name any sibling it complements or overlaps with.

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

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

Usage is only implied by the topic: there is no statement of when to reach for this tool versus e.g. jpl_sbdb, jpl_horizons, or the other NASA endpoints. No prerequisites, no exclusions, no alternatives named.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds non-obvious context beyond the annotations: the required FIRMS_MAP_KEY (distinct from NASA_API_KEY) and the fact that the legacy lat/lon interface now requires radius_km and is internally converted to a bbox.

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

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

Three dense sentences, front-loaded with purpose, then credential requirement, then the legacy-interface caveat. Every sentence carries information; 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?

An output schema exists, so return values and pagination need no explanation, and the auth/key requirement is covered. Slight remaining gap: no guidance on choosing among the eight sensor sources beyond the NRT/SP gloss already in the schema.

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

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

Schema description coverage is 100%, so the per-parameter baseline is 3. The description earns an extra point by disclosing a cross-parameter dependency the schema only implies locally: latitude/longitude now require radius_km and are converted to a bbox before querying.

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

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

States a specific verb+resource ('Active fire/thermal anomaly detections from NASA FIRMS') plus the two scoping dimensions (bounding box, 1-5 day window). This clearly separates it from the many sibling tools, none of which deal with fire detections.

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 tells the agent which credential is required and when the legacy lat/lon path applies, which is useful context. It never states when to prefer this tool over an alternative sibling (e.g., nasa_eonet for events) or when-not to use it, so usage 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful protocol context (WMS GetMap, EPSG:4326) and that the output is an image, but says nothing about rate limits, tile capping, or what happens with unsupported layer/date combinations.

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?

A single tight sentence front-loads the verb and resource, then packs protocol and projection into a parenthetical. Nothing is wasted and nothing is buried.

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

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

With no output schema, the description correctly states the return type (an image) and the projection, and annotations cover the safety profile. Minor gaps remain around image size limits and whether the layer identifier must be a known GIBS layer, but an agent can call this successfully as written.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema (bbox format, date format, layer pattern, format enum, resolution default). The description only restates that date and bbox are the inputs, adding no syntax or constraint detail beyond what the schema provides. Baseline 3 applies.

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

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

States a specific verb (Render), resource (GIBS layer), and the underlying mechanism (WMS GetMap, EPSG:4326), so an agent knows exactly what operation this performs. It does not differentiate itself from siblings such as nasa_trek_tile or nasa_images, which an agent choosing between imagery tools would benefit from.

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

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

The description gives no when-to-use guidance, no prerequisites, and does not name any alternative among the many NASA/JPL imagery siblings. The agent must infer usage entirely from the layer/date requirement.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety and idempotency profile is covered. The description adds the useful behavioral fact that results are bounded thumbnails plus metadata URLs, but says nothing about rate limits, auth, or pagination beyond what the schema implies.

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 compact sentences, front-loaded with the action and resource, followed by the return behavior. No filler or redundancy; slightly more detail on distinctions from siblings would still earn 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?

With no output schema and seven parameters, the description does the necessary work of sketching the return shape (metadata, URLs, embedded preview thumbnails), which is the main gap structured data leaves. Routing guidance relative to sibling NASA media tools is the only missing piece.

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

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

Schema description coverage is 100%, so every parameter (q, page, page_size, max_images, media_type, year_start, year_end) is already documented in the schema. The description's only added semantic is that thumbnails are 'bounded', which mirrors the max_images schema entry. Baseline 3 is correct when the schema carries this much weight.

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 (Search) and resource (NASA's Image and Video Library) and specifies the return shape (item metadata and URLs, embedded thumbnails). It does not explicitly differentiate itself from media-adjacent siblings like nasa_apod, nasa_eonet, or nasa_gibs, but the resource name is unambiguous.

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 on when to use this tool versus alternatives such as nasa_apod or nasa_eonet, no prerequisites, and no exclusions. An agent must infer usage from the name alone.

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

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

Annotations already cover readOnly/idempotent/destructive/openWorld, but the description adds genuinely non-structured context: the feed is permanently frozen at a specific sol range and requires NASA_API_KEY. Data staleness and auth requirements are exactly what an agent needs to know and cannot infer from annotations.

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

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

Two tight sentences with the most important constraint (HISTORICAL DATA ONLY) front-loaded. Every clause earns its place: scope, fields, staleness, sol range, auth.

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 no-parameter, no-output-schema tool, the description covers what it returns (temperature, pressure, wind), where it comes from, why it's static, and what's required to call it. Nothing material 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?

Zero parameters, so there is nothing to document and the baseline is 4. The description appropriately spends its words on scope and freshness rather than inventing parameter guidance.

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

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

States a specific verb/resource (per-sol Mars surface weather) plus the data source and location (InSight lander, Elysium Planitia). The 'HISTORICAL DATA ONLY' framing immediately distinguishes it from a live-weather tool.

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

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

Makes clear when this is appropriate (historical/archival use) and warns that the feed is frozen at sols 675-681 and no longer updated, which is a strong usage signal. It stops short of naming an alternative sibling (e.g., nasa_mars_rover) for current conditions, so it isn't a full when/when-not routing.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds context the annotations cannot: that the upstream is dead, that calls still accurately report the upstream status, that no photos are fabricated, and that a NASA_API_KEY is required. This is exactly the extra behavioral disclosure expected.

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 deprecation warning is front-loaded in the first clause, followed by the precise failure mode and the key operational facts. Three compact sentences with no waste.

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 read-only, open-world API tool with a fully documented input schema and no output schema, the description supplies everything an agent needs before calling: deprecation status, upstream behavior, honesty guarantee, and the API key requirement.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including the sol/earth_date alternative and the max_images range. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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

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

The description names the resource (Mars Rover Photos API) and its exact current state (upstream 404 'No such app' since 2026-09-29). It clearly communicates what the tool does (still queries the upstream and reports status) but does not explicitly differentiate itself from any sibling tool, so it stops 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 DEPRECATED label and the 404 detail give strong implicit guidance that this tool should not be selected for photo retrieval. It does not, however, name an alternative tool or state an explicit 'use X instead' condition, which would be needed for a 5.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds two things annotations do not: the auth requirement (NASA_API_KEY) and the hard 7-day window constraint, both of which affect whether a call can succeed.

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?

A single dense sentence that front-loads the resource and enumerates the two modes without filler. It is slightly overloaded with parentheticals, but every clause carries 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?

With no output schema, the description carries some burden for return expectations, and it names what the feed contains (close approaches) and its date scope. Combined with full schema coverage and read-only annotations, an agent has what it needs, though a word on response shape would be ideal.

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

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

Schema description coverage is 100%, so every parameter's format, default and constraint is already documented. The description restates the 7-day limit, today-UTC default and ID-lookup mode rather than adding new syntax or edge-case meaning, so it sits at the baseline for a fully documented 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 names a specific resource and two distinct modes: a close-approach date feed (up to 7 days, default today UTC) and a single-asteroid lookup by ID. That is enough for an agent to know exactly what the tool returns. It does not differentiate itself from orbit/catalog siblings like jpl_cad or jpl_sbdb, which keeps it from a 5.

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

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

It clearly explains that asteroid_id selects a single-object lookup 'instead of the date feed', giving an agent the condition for choosing each mode, and states the NASA_API_KEY prerequisite. There are no explicit 'when-not-to-use' rules or named alternative tools, so it stops short of a 5.

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

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, and openWorld=true, so the safety profile is fully covered. The description adds the one behavioral detail worth knowing (results are file listings with download links), but says nothing about pagination, file counts, or failure modes for unknown accessions.

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?

One sentence, front-loaded with the verb and resource, with the parenthetical scoping the return content. Nothing superfluous.

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

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

For a simple one-parameter, read-only listing tool with no output schema, the description conveys enough: what is returned and how to invoke it. Minor gap in not mentioning behavior for invalid/unknown accession numbers.

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 a single parameter and 100% schema description coverage, the schema already documents the accession format and the OSD- prefix pattern. The description adds no parameter detail, so the baseline of 3 is appropriate.

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

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

States a specific verb (List) and resource (data files for a NASA OSDR study), and adds the useful scope detail that results include download links. No sibling tool covers OSDR study files, so differentiation is inherent.

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

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

Usage is implied: call it with a study accession when you need that study's files. There is no explicit when-to-use/when-not guidance, no prerequisites, and no named alternative among the many 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description adds little beyond that—it does not mention timeouts, rate limits, or that the data is model-derived/reanalysis rather than observational. With annotations carrying the behavioral burden, a 3 is fair.

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?

A single front-loaded sentence with zero filler that states the resource, granularity, and source. Nothing is wasted.

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

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

With 8 parameters and no output schema, the description is thin on what an agent receives back—no mention of returned fields, units, or response shape beyond 'daily'. The schema fully covers inputs, so this is adequate but not 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 100%, with every parameter documented including enums for community, format, and time_standard. The description adds no parameter meaning (e.g., valid POWER parameter names, date range limits), so the baseline of 3 applies.

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

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

The description names a specific resource (daily solar and meteorological data), its granularity (daily), and its scope (a point), plus expands the POWER acronym. It is clearly distinguishable from sibling tools, though it does not explicitly contrast itself with any of them.

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

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

There is no when-to-use guidance, no mention of prerequisites such as which communities map to which parameter sets, and no indication of when an agent should prefer a different NASA dataset tool. Usage is only implied by the tool name and domain.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the description wisely spends its budget elsewhere: it discloses that resolution is auto-raised to bound output, that no API key is required, and the exact per-observatory CSV columns returned. It does not mention error handling or the 366-day ceiling (left to the schema), so it is strong but not exhaustive.

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

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

Three compact sentences, front-loaded with the core purpose followed by output format and operational notes; no filler. Slightly dense with coordinate-system enumeration that the schema already carries, but nothing is wasted.

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

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

With no output schema, the description steps up by enumerating the returned columns and units (X/Y/Z km, lat/lon degrees, local time, radial distance), which is exactly what an agent needs. Remaining gaps such as pagination, error cases, and size limits are minor for a read-only data tool.

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

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

Schema description coverage is 100%, so all five parameters are already documented with constraints and examples, setting the baseline at 3. The description restates the coordinate system list and the auto-raised resolution factor but adds no new syntax, format, or interaction guidance beyond the schema.

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

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

States a specific verb+resource ('Positions of spacecraft (and the Moon and Sun) over a time range') sourced from a named provider, and pins down the coordinate systems and return shape. An agent can tell it apart from nasa_ssc_observatories (which it explicitly points to for IDs) and from sibling ephemeris tools like jpl_horizons.

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

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

Usage context is implied (use it when you need spacecraft/Moon/Sun positions over a time span), and it helpfully routes to nasa_ssc_observatories for observable IDs. However, it never states when NOT to use it or compares it to overlapping siblings such as jpl_horizons or nasa_tle, leaving alternative selection to inference.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior. The description adds useful context beyond that: it states no API key is required (auth) and that results include data time ranges and resolution (output shape). It does not mention pagination or rate limits, but with strong annotation coverage this is a solid contribution.

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

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

Three short sentences, front-loaded with the tool's scope, followed by usage and auth details. Every sentence adds value and there is no 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 simple discovery list tool with no output schema, the description covers purpose, output content (time ranges and resolution), usage with the sibling, and auth requirements. It could be more complete by mentioning pagination or result limits, but given the tool's simplicity and rich annotations, it is largely sufficient.

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

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

Schema description coverage is 100%, so the schema already fully documents both optional parameters (search and active_on). The description does not add any parameter-specific syntax, format, or matching behavior beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly identifies the resource (spacecraft and observatories computable by SSCWeb) and what the tool returns (IDs, data time ranges, resolution). It distinguishes itself from the sibling nasa_ssc_locations by telling the agent to use the IDs with that tool, though it uses a noun phrase rather than an explicit 'list' verb.

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 names the sibling tool nasa_ssc_locations and gives a concrete usage instruction ('Use the IDs with nasa_ssc_locations'), plus an auth note ('No API key needed'). It does not explicitly state when to call this tool versus other discovery tools, but the linkage to the sibling provides clear routing context.

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

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

Annotations already cover readOnly, idempotent, non-destructive and open-world behavior, so the bar is lower; the description adds a genuinely useful operational fact — 'No API key needed' — plus the fact that search results are relevance-ordered. It stops short of describing pagination or rate limits.

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?

One tightly packed sentence that leads with the resource and its purpose, then enumerates the two modes and the returned data. No filler or redundancy.

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

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

With no output schema, the description usefully names the fields a project includes (status, dates, program, TRL, lead org, description, benefits). The only real gap is not clarifying the relationship/priority between query and project_id, which matters for a 0-required-parameter tool.

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

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

Schema description coverage is 100%, so the schema already documents limit, query and project_id including ranges and examples. The description reinforces which fields a single-project fetch returns but adds no parameter syntax or constraints beyond the schema, matching the baseline of 3.

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

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

States a specific verb and resource: search NASA TechPort projects by keyword or fetch a single project by ID, with the fields returned enumerated. It clearly separates the two operation modes, though it does not explicitly differentiate itself from the near-neighbor sibling nasa_techtransfer, which shares the technology-transfer domain.

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 two modes ('search by keyword, or fetch one project'), which hints at when each parameter is appropriate, but never states that query and project_id are mutually exclusive or what happens if both/neither are supplied. No alternatives or exclusions are named.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety and idempotency profile is covered elsewhere. The description adds only the auth fact (no API key needed); it says nothing about rate limits, result ordering, or pagination behavior beyond what the schema already states.

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?

One front-loaded sentence that names the resource first, then the collections, then the auth caveat. Every clause carries information, though the parenthetical URL and enumeration make it slightly heavier than strictly necessary.

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

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

For a read-only search tool with fully documented parameters and no output schema, the description covers what is being searched and where. Return-shape details are absent but arguably unnecessary, leaving only a small gap around result structure and pagination.

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

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

Schema coverage is 100%, with the enum, default, limit range, and per-parameter descriptions all documented in the schema. The description merely restates the collection options in prose, adding no syntax or format detail beyond the structured fields, so the baseline of 3 applies.

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

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

The description gives a specific verb (Search) and resource (NASA's Technology Transfer portfolio), and enumerates the four searchable collections (licensable patents, issued patents, Software Catalog, Spinoff stories). It does not explicitly differentiate from the adjacent sibling nasa_techport, but the licensing/spinoff framing is clear enough for an agent to pick the right tool.

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

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

Usage is implied by the collections listed rather than stated: an agent can infer it is for finding licensable NASA technology, software, or spinoff products. There is no explicit when-to-use/when-not or reference to alternatives such as nasa_techport.

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 readOnlyHint/idempotentHint/openWorldHint already declared, the description still adds real value: it discloses the data source, that CelesTrak data is refreshed daily (freshness), and that no API key is required (auth). It does not describe pagination mechanics or result shape, so not a full 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?

A single well-packed sentence that front-loads the resource and then the two modes, with zero filler. Slightly dense with parenthetical provenance, but every clause (source, refresh cadence, no key) 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 6-parameter, zero-required, no-output-schema lookup tool, the description covers the two access patterns, the data origin and freshness, and the auth situation. Nothing an agent needs in order to call it correctly is missing; return format is standard TLE and need not be restated.

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

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

Schema description coverage is 100%, so every parameter (page, sort, sort_dir, page_size, satellite_id, search) is already documented in the schema, including defaults and the 'cannot be combined' constraint. The description reinforces only the satellite_id-vs-search split and the paged nature; baseline 3 is appropriate when the schema carries the semantics.

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

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

Names a specific resource (two-line element sets for Earth-orbiting satellites) and enumerates its two operating modes: single satellite by NORAD catalog number, or a paged name search. It also pins the upstream provider and data lineage (tle.ivanstanojevic.me; CelesTrak, refreshed daily). It does not, however, differentiate itself from overlapping siblings such as jpl_horizons or jpl_sbdb, so a 4 rather than 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 phrase 'one satellite by NORAD catalog number, or a paged name search' implies the two usage modes, from which an agent can infer that satellite_id is for a known satellite and search is for discovery. There is no explicit when-to-use/when-not guidance and no named alternative among siblings, so usage is only implied rather than stated.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely new operational context: no API key is required, and it names the payload fields returned (layer ID, mission, instrument, WMTS endpoint) — useful for a tool with no output 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?

Two tight sentences; purpose and scope come first, the downstream handoff second. No filler or repetition of the title.

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

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

With no output schema, the description carries return-value burden and does so by listing the returned fields and naming the tool that consumes them. Coverage of bodies, auth, and pipeline role is solid; only edge behaviors (pagination limits beyond the schema) are left implicit.

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

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

Schema description coverage is 100%, so every parameter (body enum, limit range, search, projection) is already documented. The description mentions the three bodies and layer types but adds no format or matching semantics for search or projection beyond the schema.

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

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

States a specific verb (search) plus the resource (map layer catalogs of Mars/Moon/Vesta Trek) and the content type (mosaics, colour hillshades, OGC WMTS tiles). It also explicitly distinguishes itself from the sibling nasa_trek_tile by naming it as the consumer of the returned layer IDs.

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

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

Gives clear usage context: discover layers here, then feed the returned IDs to nasa_trek_tile. It does not state when to avoid the tool or how search terms map to the catalog, but the workflow positioning is unambiguous.

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

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

Annotations already carry readOnly/idempotent/destructive/openWorld hints, and the description adds real context beyond them: it reads the layer's WMTS capabilities to validate the tile and pick the format, and it notes no API key is needed. These are concrete behavioral facts not present in the structured fields.

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

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

Front-loads the return value, then qualification and sourcing in tight sentences with no filler. Slightly dense but every clause is informative; nothing wasteful.

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

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

Covers layer sourcing, both addressing schemes, format validation and auth, which is enough for a tile-fetch tool. No output schema is needed since the return is an image, and annotations cover the safety profile; only the explicit prerequisite ordering with nasa_trek_layers is missing.

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

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

Schema description coverage is 100%, so the schema documents all 8 parameters (including the equirectangular-only lat/long note). The description restates the addressing dichotomy (zoom/row/col vs lat/long) but adds no syntax or format detail beyond it, so baseline 3 applies.

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

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

States a specific verb and resource ('One WMTS map tile image from NASA Mars Trek, Moon Trek or Vesta Trek'), and names the source of valid layer IDs (nasa_trek_layers), cleanly separating it from that sibling. An agent can tell what it returns without opening the schema.

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

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

Mentions that the layer comes 'from nasa_trek_layers' and gives the two addressing modes, which implies the workflow, but never states explicitly to call nasa_trek_layers first or when-not to use this tool. Usage is implied rather than instructed.

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