Earth & Sky

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

No annotations are provided, so the description carries the full burden. It discloses that the result is a point-in-time snapshot ('right now') and what data is bundled, but says nothing about freshness/caching, whether the payload is read-only, or the granularity of the earthquake totals.

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 bundled data sources are stated up front so an agent can decide immediately whether it needs this call.

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 must sketch the return value, and it does name both components (earthquake totals, ISS position). It stops short of describing the payload shape or units, which would fully close the gap for a zero-parameter aggregate 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 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 and scope: a one-shot snapshot combining 24h earthquake totals and current ISS position. This implicitly differentiates it from the sibling 'earthquakes' and 'iss_position' tools by being the combined call, though it never names those siblings explicitly.

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?

'One-shot summary' implies the use case (get both data points in a single call rather than two), but the description never states when to prefer this over calling earthquakes and iss_position separately, nor any exclusions. Usage is inferred, not specified.

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

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

With no annotations, the description carries the burden and does disclose the source (USGS) and the return fields (magnitude, place, depth, time). It does not state sort order, result freshness, or whether the call is a plain read against a public API, leaving meaningful behavioral detail undisclosed.

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

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

Two sentences, zero filler, with the data source and filter axes front-loaded and the return payload listed second. Every clause earns its place.

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

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

All parameters are optional and fully documented in the schema, and the description names the return fields, so an agent has enough to call it correctly. The remaining gap is the unaddressed overlap with the 'earth_now' sibling and result ordering.

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

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

Schema coverage is 100% and the schema already documents all four parameters, including the window enum and the 'not a geographic polygon search' caveat. The description restates the filter set without adding syntax or defaults beyond what the schema provides, 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+resource ('Recent earthquakes from USGS') and enumerates the three filter axes and the returned fields. It does not contrast itself with the closest sibling (earth_now), 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 filter list implies how to use it (narrow by window/magnitude/place), but there is no explicit when-to-use, no exclusions, and no routing to the overlapping 'earth_now' sibling for current events.

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

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

No annotations, so the description carries the burden. It discloses that the data is 'current' (a point-in-time snapshot) and names the returned fields, but omits freshness/update frequency, accuracy, and any dependency on a live data source.

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 waste; the resource and returned data are stated immediately.

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

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

For a zero-param, no-output-schema tool, the description must convey return values, and it does (latitude/longitude). Only minor gaps remain around freshness and format details.

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 the baseline is 4. There is nothing for the description to clarify beyond what the empty schema already conveys.

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 (International Space Station) and the exact data returned (current latitude/longitude). Clear enough to distinguish from the earth/sky/weather siblings, though it doesn't explicitly name what it is not.

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 siblings, no prerequisites, no exclusions. The word 'Current' implies a real-time snapshot but the description never states that explicitly or points to alternatives.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It implies a read-only lookup of astronomical data but does not state side-effect behavior, authorization requirements, default location handling, or error conditions.

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

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

The definition is a single focused sentence with no wasted words. The key concept, moon phase and illumination, is front-loaded and easy to scan.

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

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

For a simple read-only tool with a fully described input schema and no output schema, the description covers the basic purpose but omits important context such as what happens if location coordinates are omitted and whether outputs include additional fields. It is minimally 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%, so all three parameters are already documented in the schema. The description adds only that a date can be optional and that results are tied to a location; it does not clarify defaults or formatting 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?

The description clearly identifies the resource and returned values: moon phase and illumination for a location, with an optional date. It does not explicitly differentiate itself from siblings such as sky_at or sky_tonight, but the moon-specific focus is evident.

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

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

The description states the tool can use the current time or a given date, but it gives no explicit guidance on when to choose this tool over sibling tools like sky_at or sky_tonight. It also does not state any exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden; it usefully discloses that no API key/authentication is required and that results are computed astronomy rather than live observation ('pure astronomy', 'true moon phase'). It does not cover failure behavior (invalid coordinates, unrepresentable dates) or that the output is a derived data payload, leaving meaningful gaps for an unannotated 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?

Two sentences with the resource and returned fields front-loaded and no filler; 'pure astronomy, no API key' earns its place as a dependency note. The enumerated output list is dense but serves selection.

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

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

No output schema and no annotations, but the description compensates by enumerating the returned fields, which is what an agent needs to pick this over moon_phase or sky_tonight. Missing only edge-case behavior and any indication of response shape beyond the field list.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes slightly beyond by tying 'place' to lat/lon and 'instant' to the optional time argument, reinforcing the semantics. It says nothing about tz_offset, which the schema must carry on its own.

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?

A concrete verb-plus-resource statement: returns sky events (sunrise/sunset, moonrise/moonset, phase, illumination, dark window) for a given place and instant. The phrase 'for a place and an instant' implicitly separates it from the tonight-only variant, but it never names sky_tonight or moon_phase, so an agent must infer the split from sibling names 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?

'For a place and an instant' and 'no API key' give a loose usage context, so an agent can infer this is for arbitrary time/location queries rather than tonight-only. There is no explicit when-not, no mention of sky_tonight as the alternative, and no note on handling near-polar latitudes where rise/set events may not exist.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses that data is 'live hourly cloud cover' (implying an external/network dependency), that moon illumination is computed from first principles, that low cloud is weighted above high cloud, and what the response shape is. It does not cover failure modes, latency, or behavior at polar latitudes with no true darkness.

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

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

Front-loaded with the user-facing question, then method, then return values, then parameters — a sensible information order. It is tight overall, though the 'computed from first principles' and cloud-weighting detail is method trivia that an agent calling the tool does not strictly need.

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

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

There is no output schema and no annotations, so the description must explain returns and behavior, which it does (score scale, best run, verdict, weighting). Given four simple scalar parameters, the only real omission is behavior for edge cases like polar day/night or missing cloud data.

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

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

Schema coverage is 100%, so the schema already documents all four parameters with ranges and defaults. The description only echoes requiredness and optionality, adding no syntax, format, or interpretation beyond the schema. Baseline 3 applies 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?

The opening question names the concrete decision (stargazing/astrophotography usability tonight) and the body specifies outputs: a 0-100 score per night hour, best consecutive run, and a verdict. It is a specific verb+resource, but it never distinguishes itself from nearby siblings like sky_tonight, sky_at, or moon_phase, which an agent must guess between.

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 framing question — an agent can infer this is for planning observing sessions. There is no explicit statement of when to prefer this over sky_tonight, sky_at, or weather, and no exclusions. The closing 'lat/lon required; tz_offset and when optional' is parameter restatement, not usage guidance.

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

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

With no annotations, the description carries the full burden. It does usefully disclose that results are computed from first principles with no API key or ephemeris file required, which tells the agent about dependency and latency characteristics. It never states that the tool is read-only and side-effect free, nor whether results are approximate or how locations are resolved.

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

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

Two sentences, no filler, and the payload of returned values is front-loaded in the first sentence while the implementation note is relegated to the second. Every clause 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?

There is no output schema, and the description compensates well by enumerating the returned quantities. The remaining gap is sibling disambiguation against moon_phase and sky_at, which matters in a family of eight astronomy tools, plus silence on read-only safety.

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 lat, lon, when, and tz_offset all documented including valid ranges, so the baseline is 3. The description only gestures at the parameters via 'a place and night' and adds no formatting or defaulting detail 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?

Names a specific resource and enumerates exactly what is returned (sunrise/sunset, moonrise/moonset, phase and illumination, dark window), which is more than a restatement of the name. It stops short of distinguishing itself from close siblings like moon_phase or sky_at, so an agent still has to infer the difference.

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?

'For a place and night' implies the usage context (single location, single evening), but there is no explicit statement of when to prefer this over moon_phase, sky_at, or sky_seeing, and no note about when it would be the wrong choice. Usage is inferable but not guided.

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

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

No annotations are provided, so the description must disclose behavior. It explains the server-side state and cursor semantics well, including only-newer events and no rescan/client-side dedupe, but it omits auth needs, delete permanence, create idempotency/overwrite behavior, and error/rate-limit 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?

Three compact sentences front-load the distinguishing server-side cursor behavior and then list the actions and associated parameters. There is no filler, and the ONLY emphasis is 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?

Inputs are fully documented by the schema, but there is no output schema and the description explains only poll's return. It leaves create/list/delete response shapes unspecified, including whether create returns the id needed for later poll/delete.

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. The description adds useful action-to-parameter mapping: create uses min_magnitude and place, while poll/delete use id. It does not discuss owner or since_hours, but those are fully documented in the schema.

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

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

The description identifies the resource as stateful quake subscriptions and enumerates the four actions. It also explicitly contrasts server-stored filter/cursor behavior with a local tool, letting an agent distinguish it from one-shot earthquake siblings without opening the schema.

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

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

It implies use for ongoing subscriptions by explaining that poll returns only events newer than the last poll. However, it does not explicitly say when to choose watch over earthquakes or when not to use it, so the guidance is contextual rather than a clear when/when-not rule.

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

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

No annotations exist, so the description bears full behavioral burden. It does disclose two useful facts an agent would otherwise have to probe for: no API key is required, and the upstream source is Open-Meteo. It leaves undisclosed the return shape (which fields, what units, Celsius/Fahrenheit, wind speed unit), how current conditions are determined, and any rate limits or error behavior — significant gaps for a zero-annotation 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?

Two sentences, zero filler, with scope (current + 12h) and the auth-free property front-loaded. Nothing could be removed 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?

With no annotations and no output schema, the reader cannot learn what a response contains — no indication of fields (temperature, precipitation, wind, humidity) or units, which is the main thing left to describe. The auth and source disclosures are genuinely valuable, but for a data-returning lookup with zero structured return documentation, the definition stops short of 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 explicit valid ranges (-90 to 90, -180 to 180), so the schema fully carries parameter meaning. The description only restates 'latitude/longitude' and adds no format, precision, or coordinate-system guidance beyond what the schema already gives. Baseline 3 is correct when the schema does all the work.

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 concrete resource (weather) with an explicit temporal scope (current conditions plus the next 12 hours) and a location input contract (latitude/longitude), plus the data source (Open-Meteo). No sibling tool overlaps — none of earth_now, earthquakes, iss_position, moon_phase, sky_* or watch covers weather — so an agent can route to 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?

The description never states when to use this versus a sibling (e.g. sky_at, sky_tonight, which are astronomy-oriented and distinct but adjacent for outdoor/observation queries), nor any exclusion or prerequisite beyond the API-key note. Usage is inferable from the name and the temporal scope, which is the definition of implied rather than stated guidance.

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