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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the useful detail that results are 'computed for home' (fixed observer location), but does not explain what 'home' resolves to or whether location can vary, and gives no sense of the returned item shape or ordering.

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 event list, the temporal window, and the location caveat are all packed economically. Slightly dense but appropriately sized.

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 calendar tool with no output schema, the description should convey what an entry looks like and clarify the unexplained `max_conjunction_deg` parameter. It covers the core range/default semantics well but leaves one parameter and the return shape unspecified.

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

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

Schema description coverage is 0%, so the description carries the parameter burden. It documents `days` with its 7-365 bound and `date` with its default, which is genuinely beyond the schema, but leaves `max_conjunction_deg` completely unexplained despite it being an opaque tuning knob.

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 ('astronomical calendar') with the event types it covers (conjunctions, occultations, moon phases, showers) and the temporal scope (next `days` from `date`). This clearly differentiates it from point-in-time siblings like tonight_highlights or sky_times, though it never names an alternative 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?

Implies usage through the range/default ('next `days` (7-365) from `date` (default today)'), which tells the agent how to call it, but there is no explicit when-to-use guidance and no distinction drawn against closely related siblings like event_highlights or tonight_highlights.

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 and openWorldHint=true, so the safety and openness profile is covered. The description adds only the data source; it says nothing about freshness, result count, caching, or whether feeds are live, which is the kind of context that would actually help here.

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 and the resource is stated first.

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 parameters, no output schema and annotations covering the safety profile, the definition is minimally viable. Because there is no output schema, some hint about what the headlines payload looks like (count, fields, ordering) would have made it 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter confusion is possible.

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 clear resource (latest headlines) and its source (Telescopius' astronomy news feeds), so an agent can recognize it as a feed-reader rather than an event or target lookup. It does not, however, explicitly distinguish itself from near-neighbours like astro_events, event_highlights and tonight_highlights, which an agent could plausibly confuse it 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?

There is no statement of when to reach for this tool versus the event/highlight siblings, and no prerequisites or exclusions are given. The agent is left to infer usage entirely from the sentence fragment.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered and closing a presentation window does not contradict a read-only hint. The description adds the lifecycle context (it closes the window from show_framing), but says nothing about error/idempotency behavior when no window exists. Adequate but not rich.

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

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

A single front-loaded sentence with zero filler: the action and its target are stated immediately. 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?

An output schema exists, so return values need not be explained, and with zero parameters the description covers the essentials. The only minor gap is unstated behavior on a stale or already-closed window, which slightly keeps it from a 5.

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

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

The tool takes zero parameters, so there is no parameter semantics to convey and the baseline of 4 applies. There is no ambiguity about what to pass, since the target window is implied by the show_framing pairing.

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 (close) plus the exact resource it acts on (the framing browser window opened by show_framing). By naming the sibling tool that created the window, it lets an agent distinguish this from the many other read/list siblings in the set.

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 makes the usage condition clear by tying it to show_framing's output ('the window opened by show_framing'), so an agent knows this is the teardown counterpart. It stops short of stating when-not to use it or what happens if no window is open, so it doesn't reach the explicit alternatives/exclusion bar.

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 and openWorldHint, so safety behavior is covered. The description adds two pieces of real context beyond that: the result count range (1-50) and that returned events carry local visibility flags. It stops short of explaining how 'local' is determined when no location parameter exists.

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 notable/upcoming qualifiers come first and the count range and output flag are packed into a tight parenthetical.

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-required-param, read-only lookup with no output schema, the description covers the essentials. It leaves open the time window for 'upcoming' and how 'local visibility' is resolved without a location input, and gives no differentiation from the near-identical sibling tools.

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

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

Schema coverage is 0% — 'limit' is a bare integer with only a default of 10. The description supplies the missing bound (1-50), which the schema lacks entirely, and contextually ties it to the number of events returned. It does not state what happens on out-of-range input.

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 ('the most notable upcoming sky events') with a scope qualifier ('upcoming', 'most notable') and the response content ('local visibility flags'). This separates it loosely from tonight_highlights, but it never names or contrasts with the 13 siblings that overlap heavily (astro_events, tonight_highlights), so an agent must guess at routing.

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 statement, no prerequisites, and no alternative named. The description gives no signal for choosing this over tonight_highlights or astro_events, which is the main ambiguity an agent faces here.

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 and openWorldHint=true, so the safety profile is covered. The description contributes only that the gear is tied to the Telescopius account (a personal-scope note), but says nothing about return shape, pagination, or account/auth requirements, so it adds little beyond the annotations.

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

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

A single short sentence with no filler, and the key resource is front-loaded. It is a fragment rather than a full statement, 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?

For a zero-parameter read-only tool with annotations covering safety, the description is minimally adequate in identifying the data domain. With no output schema, it could still say what the return looks like (a list of equipment), which it does only loosely by naming the categories.

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 the schema imposes nothing to explain; the baseline for 0-param tools applies. The description adds no parameter meaning because none exists to add.

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 (telescopes, cameras, other gear) and scopes it to the account, so the agent knows what data is involved. However it is a noun phrase with no verb, so it never states the operation (retrieval), leaving the agent to infer the action from the readOnly hint and the name.

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 prerequisites, and no mention of how this differs from siblings like my_observing_lists or observing_list. The agent must infer usage purely from the tool name.

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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the data is account-scoped ('The account's') and previews the returned fields, which is useful context, but says nothing about ordering, pagination, or what an empty result means.

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 fragment with zero waste and the resource 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 output schema, the description carries the burden of explaining what comes back, and it does list the key fields (id, name, target count). It is nearly complete for a zero-parameter reader; the only gap is the unspecified relationship to the similarly named 'observing_list' sibling.

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 per the baseline this dimension starts at 4. The description's parenthetical describes returned fields rather than inputs, which is fine since there is nothing to document on the input side.

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 concrete resource ('the account's saved observing lists') and enumerates what each entry contains ('id, name, target count'), so an agent can tell it is a retrieval of the user's saved lists. It never states a verb and does not differentiate itself from the near-identical sibling 'observing_list', which is the main reason 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?

There is no guidance on when to call this versus the sibling 'observing_list' or any other list-returning tool. The agent must infer from the name alone that this returns the account's own lists, with no stated prerequisites or exclusions.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the agent knows it's a safe, externally-informed read. The description adds that visibility is computed for the given night, which is useful context beyond the annotations, but it says nothing about defaults (e.g., location/date null behavior), rate limits, or output 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?

A single tight sentence with no filler. It is front-loaded with the resource, though the fragmentary phrasing sacrifices clarity for brevity.

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 five parameters at 0% schema coverage, no output schema, and only two annotations, the description is far too sparse. It fails to explain required list_id, location/date defaults, or what the returned target list includes, leaving the agent unable to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate for five undocumented parameters. It only vaguely references 'the given night' (hinting at date/timezone) and 'visibility' (hinting at lat/lon), but never explains list_id, lat, lon, date, timezone, their formats, or defaults. This is a severe gap.

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

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

The description names the resource ('observing list's targets') and a partial verb-like scope ('with visibility for the given night'), but it's a noun phrase rather than a clear action verb. It doesn't distinguish from siblings like tonight_highlights or my_observing_lists, leaving ambiguity about whether it lists lists or their contents.

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 versus my_observing_lists, tonight_highlights, or sky_times. It implies retrieving a list's targets for a given night, but doesn't state prerequisites like needing a list_id or how to obtain one.

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 cover read-only and open-world behavior, so the bar is lower. The description adds useful behavioral context: ordering defaults vary per field (popularity rank, largest size first), result pagination limit (1-120), and raw=True returns the untrimmed payload. It doesn't mention auth or rate limits, but for this read tool it conveys the key quirks.

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

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

The description is front-loaded with the purpose, then a compact parameter glossary. It is dense but structured and every sentence carries parameter semantics. It is appropriately sized for a 23-parameter tool, though the inline list format is somewhat terse.

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

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

Given the high parameter count, zero schema coverage, no output schema, and annotations covering safety, the description is fairly complete for calling the tool correctly. It misses some parameters and exact defaults for lat/lon/date, but the major ones and ordering behavior are explained. An agent could use it with minor guesswork.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: it explains name, size bounds, con, cat, az_quadrants, hour_min/max with twilight keywords, order accepted values, order_asc semantics, results range, and extra pass-through. Several parameters (lat, lon, date, types, mag_max, min_alt, page, timezone, moon_dist_min, min_alt_minutes) are not covered, leaving gaps, but the high-value/complex ones are clarified.

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

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

The description states a specific verb and resource ('Advanced target search across Telescopius' full catalogue') and the tool name matches. It doesn't explicitly contrast with siblings like target_info or tonight_highlights, but the search intent is clear from the name and opening.

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?

Implicit guidance is present through the parameter walkthrough (e.g., 'name: fuzzy name match'), but there is no explicit when-to-use/when-not or alternative-tool recommendation. An agent can infer it's the broad catalogue search, yet nothing states prerequisites or exclusions.

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

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

Annotations only give readOnlyHint and openWorldHint, so the description carries most of the behavioral load and does so well: it discloses that a visible browser window opens on this machine, that it persists until close_framing is called, and that the call returns a screenshot. It does not cover latency, what happens if the window is already open, or failure modes when the target cannot be resolved. Note: launching a persistent browser window is a side effect that sits uneasily with readOnlyHint, though the annotation most plausibly refers to data mutation.

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

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

The core behavior is front-loaded in the first sentence and the rest is a compact parameter glossary with concrete examples, so little is wasted. It is dense to the point of terseness in places (e.g. the ra_h/dec_deg clause), but nothing is padding.

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

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

With no output schema, the description correctly states what is returned (a screenshot of the framing) and how the session is torn down. For a 9-parameter tool with zero schema documentation, the coverage is good, but overlap_pct is unexplained and there is no note on resolution failures or what the screenshot looks like.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: it defines target as an object name resolved via the API versus a mere label when ra_h/dec_deg are supplied, gives the mosaic format ("COLSxROWS"), the rotation unit, and example formats for sensor_mm ("11.136x6.264") and sensor_px ("3840x2160"), and explains that the focal/sensor params override the default rig for this call. It leaves overlap_pct completely undocumented and gives only a minimal gloss for rotation.

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 verb (frame), a specific resource (a target), and the exact environment (Telescopius' Telescope Simulator with the configured rig in a visible browser window), plus the return artifact (a screenshot of the framing). It also names the sibling close_framing as the way to tear the session down, so an agent can distinguish it from the rest of the sibling set 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 establishes clear context: use this to frame a target and get a visual, the window stays open for hands-on adjustment, and close_framing closes it. What is missing is any explicit exclusion or routing statement, e.g. when to prefer target_info or search_targets over opening a live simulator window.

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 and openWorldHint=true, so the safety profile is covered. The description adds useful default behavior (date defaults to now, location defaults to home) and clarifies the astronomical-darkness range, but does not describe output format, timezone handling, or any operational 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?

The description is short, front-loads the main output, then adds two useful defaults. The line breaks are slightly fragmented but every sentence contributes information and nothing is redundant.

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

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

It describes the high-level return content (rise/transit/set and twilight times), which helps since there is no output schema. However, with four optional parameters and no schema descriptions, the description is incomplete about coordinate and timezone semantics, leaving gaps for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains the date format and that location defaults to home, but lat/lon coordinate formats and the timezone parameter are not addressed. Two of four parameters receive essentially no semantic explanation here.

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 astronomical resource: rise/transit/set times for the Sun, Moon and planets, plus all twilight times. It is specific enough to distinguish from general highlight or event tools, but does not explicitly name or compare against siblings like tonight_highlights or astro_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?

It gives input defaults for date and location but provides no guidance on when to choose this tool over alternatives such as tonight_highlights, astro_events, or weather_forecast. There is no stated when-to-use or when-not-to-use 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 safety (readOnlyHint, openWorldHint), so the bar is low. The description adds real behavioral context: the ephemeris daily/yearly mode distinction and the fuzzy-match fallback when an exact name fails, which is valuable for predicting results.

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?

Very short and front-loaded: purpose first, then ephemeris modes, then fallback behavior. No filler, though the ephemeris note is terse and relies on the reader inferring argument usage.

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 tool with zero schema descriptions and no output schema, the description covers only purpose, ephemeris, and fuzzy fallback. Half a dozen location/date/time parameters remain unexplained, leaving the agent unable to call it correctly without guessing.

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

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

Schema description coverage is 0% across 6 parameters, so the description carries the full burden but only explains the ephemeris value semantics (daily vs yearly). lat, lon, date, timezone, and name semantics are left entirely undocumented, so the gap is not compensated.

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 one named target with tonight's visibility windows, with concrete examples ("IC 1805", "Heart Nebula"). Distinguishes it implicitly from search_targets by specifying a SINGLE named target, but never names the sibling 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?

Usage is implied rather than explicit: you fetch info for one specific target, unlike search_targets. However, there is no explicit when-to-use guidance, no condition that selects it over search_targets, sky_times, or tonight_highlights, and no exclusions.

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

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

Annotations cover readOnlyHint and openWorldHint, so the safety profile is already handled. The description adds real behavioral context beyond that: results carry tonight's imaging windows with moon illumination and distance, moon_dist_min accepts the API's avoidance presets, and raw=True returns the untrimmed payload. It does not mention rate limits, pagination, or failure modes, but the added return-shape detail is substantial.

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 the remaining lines are compact, field-by-field note fragments with no filler. The telegraphic style is efficient, though the parameter notes are not visually separated from the summary sentence.

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, output-schema-less tool, the description covers what the results contain and how the filtering knobs behave, which is most of what is needed. It omits how date/timezone interact with 'the given night' and what happens when lat/lon are omitted, so an agent must guess at the location/time contract.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it delivers meaningful semantics for 5 of 9 parameters: types format and example values, min_alt units, min_alt_minutes' relationship to min_alt, moon_dist_min's preset strings, and raw's effect. It leaves lat, lon, date, and timezone unexplained, which is a real gap for a location- and time-sensitive tool, but the covered half is documented well beyond the schema titles.

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

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

The opening sentence states a specific resource and scope: Telescopius' curated popular targets that are well placed on a given night. That is more precise than a tautology and conveys 'curated list, not arbitrary search'. However, it never distinguishes itself from plausible siblings like search_targets or event_highlights, so an agent cannot tell from the text alone which of the two 'highlights/search' tools fits a given request.

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 explicit when-to-use or when-not-to-use guidance and no alternative tool is named, despite 11 siblings including search_targets and event_highlights. The scoping filters described (altitude, moon separation) imply a 'tonight's recommended targets' use case, but usage is left entirely to inference.

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

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

Annotations only cover readOnlyHint and openWorldHint, and the description adds genuinely non-obvious behavior: seeing/transparency are 0-100 scores, the API ignores temp_unit for daily stats, and hourly rows deliberately omit temperature/dew point because the upstream API was non-deterministic. That last detail is exactly the kind of provenance an agent needs to avoid misreporting values.

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

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

The purpose and return fields are front-loaded, followed by parameter and caveat notes. Sentences are dense and each carries information, though the paragraph could be broken into clearer bullets for the two distinct concerns (output fields vs. hourly_nights behavior).

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

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

With no output schema, the description usefully enumerates the returned fields and clarifies score ranges, which covers the return-value gap. It remains incomplete on inputs — nothing explains how lat/lon/timezone should be supplied or what happens when they are omitted.

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

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

Schema description coverage is 0%, so the description carries the full burden, but it only explains one of four parameters: hourly_nights (N nights of dark hours, 0 = summary only). lat, lon and timezone — essential for a location-based forecast — get no explanation of format, defaults, or whether they are required.

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 precisely ('Astronomy forecast') and enumerates the per-night data it provides (cloud cover, seeing, transparency, humidity, wind, temperature, dew risk, moon illumination), so an agent knows exactly what comes back. It does not explicitly contrast itself with siblings like sky_times or astro_events, so it falls short of the top score.

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 rather than stated: the agent can infer this is the tool for nightly astronomy weather, and the description explains the hourly_nights=0 summary mode. However, there is no explicit 'use this when...' statement or disambiguation against related siblings such as sky_times.

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