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

Annotations already declare readOnly=true, idempotent=true, openWorld=true, so the safety profile is covered. The description adds genuinely non-obvious context: the data source is IMCCE SkyBoT and results are geocentric, plus what fields come back. It omits limits (max rows, how a large radius is handled) but for a read-only query tool this is solid added value.

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, front-loaded with the resource and scope, with the source/frame parenthetical doing real work. The return-field list ("name, class, V mag, separation, motion") is mildly redundant given an output schema exists, but it is compact enough not to be 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?

An output schema exists so return values needn't be spelled out, and annotations cover safety, leaving parameter meaning as the main gap. An agent still lacks coordinate units and the meaning of radius_arcsec, and cannot tell whether the result set includes comets or natural satellites despite the tool name saying asteroids.

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. It explains epoch_iso precisely (UTC, with a worked example) but leaves ra/dec units and expected ranges unstated, and radius_arcsec — including its 30 arcsec default and what it governs — is never mentioned despite being the parameter that defines "near".

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: known solar-system objects near a position at a given time, with the upstream service (IMCCE SkyBoT) and frame (geocentric) named. That implicitly separates it from stellar/transient siblings like simbad or ztf_objects_near, though it never names an alternative explicitly. Note the mild mismatch between the tool name (asteroids_at) and the broader description ("solar-system objects").

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 "near a position at a given time" implies the invocation condition, but there is no explicit when-to-use guidance, no prerequisites, and no routing to or away from siblings such as whats_here or ztf_objects_near. 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, openWorld and idempotent, so the safety profile is covered. The description adds that multiple external services are queried and which ones, which supports the openWorld hint, but doesn't say whether links are returned as URLs only (no image bytes), whether services can fail independently, or anything about latency/rate limits from external archives.

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 output and the sources with no filler. Slightly dense with survey names but each earns its place by telling the agent what's available.

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 structure needn't be explained, and the safety profile is covered by annotations. The remaining gaps are the undocumented size_arcsec parameter and no statement of what a 'cutout link' resolves to, which matters for a tool that hits several external archives.

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 it largely doesn't. It implies ra/dec via 'for a position', but the size_arcsec parameter (default 60) is never mentioned, leaving the agent with no guidance on field of view sizing.

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: image cutout links for a sky position, and enumerates the surveys/formats returned (Legacy Survey DR10, Pan-STARRS, DSS2, Aladin Lite). It's clear what the tool produces, though it doesn't contrast itself with the sibling whats_here, which also covers 'what is at this position'.

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 choose this over alternatives such as whats_here, or when the user wants images versus catalogue data. The agent must infer usage entirely from the noun phrase.

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 behavior, so the description is free to add value — and it does: result ordering (nearest first) and the exact rule behind the derived 'likely_star' flag (parallax S/N > 3 or PM > 5 mas/yr). It does not disclose any cap on the number of rows returned, which is a meaningful omission for a cone search.

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 dense, front-loaded sentence with no filler; the core operation comes before the field list. Slightly overloaded by cramming the flag definition into parentheses, 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?

An output schema exists, so the column enumeration is arguably redundant, and the real gaps — radius units, coordinate frame, and any result-size limit — go unaddressed. Adequate to call the tool, but not fully self-sufficient for a catalog cone search.

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

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

Schema coverage is 0%, so the description carries the full burden. 'Within radius' hints at the third parameter's role, but ra/dec coordinate frame (ICRS, presumably), radius units (arcsec), and the default radius of 5 are never explained, leaving the two required parameters undocumented.

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 (Gaia DR3 sources), the operation (cone search within radius), the ordering (nearest first), and enumerates the returned columns. The catalog name alone separates it from catalog siblings like simbad and vsx.

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 guidance on when to use this versus simbad, vsx, or ztf_objects_near, and no stated preconditions. Usage must be inferred purely from 'Gaia DR3 sources within radius'.

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 establish read-only/idempotent/open-world, so the description's added value is in the observability logic: Sun below -12 deg, min altitude, min moon separation, and the ranking rule (brighter, younger, longer window). This lets the agent predict both filtering and ordering. It does not mention rate limits, empty-result behavior, or cost of the computation.

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?

Dense and front-loaded: the core purpose and filter chain come first, then the use case, then the return shape. Slightly long with a parenthetical return-summary, but nearly every clause carries filter or output meaning. No filler sentences.

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, open-world query with a rich return payload, the description covers observability criteria, ranking, and the key returned fields (night window, Moon illumination, max altitude, transit, observing window, TNS link); an output schema is also present. The gap is modest: `limit` and `include_classified` semantics remain undocumented and there is no note on what happens when no targets match.

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

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

Schema description coverage is 0%, so the description must carry the load, and it covers most parameters: lat/lon units and sign convention, date format and default, max_age_days, mag_limit (explicitly TNS discovery magnitude), min_altitude, and min_moon_sep. Only `limit` and `include_classified` are left unexplained, keeping it just below a 5 given the zero schema coverage.

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

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

Opens with a specific verb-like framing ('What to observe tonight:') followed by a precisely scoped resource: recent, bright, still-UNCLASSIFIED TNS transients observable from a given site and night. The filter criteria are spelled out inline, so an agent can distinguish this from tns_search, rubin_recent, or whats_here without opening any 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?

Explicitly states the intended use case ('plan follow-up photometry or spectroscopic classification') and defines the date semantics ('local evening of `date`, default today UTC'). It does not name exclusion cases or an alternative sibling for when a stricter/looser search is wanted, 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, idempotent, and open-world access, so safety is covered. The description adds real behavioral detail beyond that: it returns data from the latest alert only, magnitudes are converted to AB from nJy flux, and cutouts are provided as links rather than pixels. It does not say what happens for an unknown ID, but that is a minor omission.

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 sentence that front-loads the resource and key, then lists the three return elements in order of importance. No filler, no restatement of the tool name.

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

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

An output schema exists, so return values need not be explained, yet the description still previews the payload shape, which helps an agent decide if this tool has what it needs. Combined with annotations covering read-only/idempotent behavior, the only gap is error/miss handling, which is minor for a one-parameter lookup.

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% for the single required parameter, dia_object_id, which has no format, example, or type guidance in the schema. The description names the concept ('by diaObjectId') and thereby ties the parameter to the Fink broker namespace, but supplies no syntax or source for obtaining an ID, so it only partially compensates.

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 (Rubin/LSST object from the Fink broker) and the exact retrieval key (diaObjectId), and enumerates what comes back: position, light curve, cutout links. That scope implicitly separates it from rubin_recent (a listing tool) and ztf_lightcurve, though no sibling is named explicitly, keeping it 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?

Usage is implied rather than stated: 'by diaObjectId' signals this is the single-object lookup, opposite rubin_recent's recency-based query. There is no explicit when-to-use, no instruction on where to obtain a diaObjectId, and no stated alternative for users who only have coordinates (a different tool, presumably).

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 and openWorld, so safety is covered. The description adds genuine behavioral context the annotations do not: the 30-day cap, brightest-first ordering, and the enumerated set of valid tags. It does not mention result-size limits or pagination, which keeps it below 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?

Two sentences, front-loaded with the core action and scope, followed by a compact tag enumeration. 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?

An output schema exists, so return values need not be explained, and the description covers the crucial tag/time-window semantics that the schemas leave undocumented. The only omissions are the parameter defaults, which the agent could otherwise assume were required.

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 it does: it enumerates the five valid tag values and states the 30-day maximum for days. It omits the default values (most_likely_sn, 3) and does not explain tag semantics, leaving a small 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?

States a specific verb+resource: recent Rubin objects from a Fink LSST tag, with the ordering and time window named. It is distinguishable from the sibling rubin_object (single-object lookup) by the word 'recent' and the 'last N days' scoping, though the distinction is implied 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?

Usage is implied by 'over the last N days (max 30), brightest first' — an agent can infer this is the discovery/listing tool for fresh candidates. However, there is no explicit when-to-use vs rubin_object or when-not guidance, and no mention that all parameters are optional with defaults.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavior by stating nearest-first ordering and listing fields, but it omits result limits, coordinate-frame assumptions, maximum radius, and error 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?

The description is a single front-loaded sentence with no filler. It is somewhat telegraphic, and the output-field list is partly redundant because an output schema exists, which keeps it below a 5.

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

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

For a simple three-parameter read-only cone search with annotations and an output schema, the description is minimally adequate. However, it leaves important input semantics and result-boundary behavior unspecified, which matters given the 0% schema description coverage.

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

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

Schema description coverage is 0%, so the description needs to compensate for three undocumented parameters. It only says 'within radius' without explaining the RA/Dec frame, radius units despite the parameter name, default radius behavior, or required inputs.

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?

It clearly identifies the resource (SIMBAD objects), the spatial scope (within radius), ordering (nearest first), and returned fields. The catalog name distinguishes it from siblings such as Gaia or ZTF, though it does not explicitly name alternatives.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no comparison to alternatives like whats_here, ztf_objects_near, or gaia. The intended use is only implied by naming SIMBAD.

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 safety profile is covered. The description adds genuine value by naming the upstream catalogs and explaining the TIC-only fallback to TIC v8.2 positions. It does not explain the angular search behavior implied by radius_arcsec or what happens when both TIC and coordinates are supplied.

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 that front-load the returned content and follow with the input/catalog caveat. No filler, though the dangling catalog citations could be folded more economically.

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-value explanation is not required, and the input modes and data sources are covered. The gap is the undocumented search-radius parameter, which materially affects results for a cone-search tool.

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

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

Schema description coverage is 0% across four parameters, so the description must compensate and largely does not. It implies tic and ra/dec are alternative input modes but never documents units, frame, or the 30-arcsec default search radius of radius_arcsec — the parameter most likely to be misused.

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 (TOIs/CTOIs from ExoFOP-TESS and TESS eclipsing binaries from Prsa et al. 2022) retrievable by TIC id and/or sky position. An agent can tell this returns known-object catalog matches rather than raw photometry or ephemerides. It does not, however, differentiate itself from conceptually overlapping siblings like whats_here or simbad.

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 says what inputs are accepted but never states when to prefer this over whats_here, simbad, or vsx, nor any exclusions or prerequisites. The only conditional statement ('with only a TIC, its position comes from TIC v8.2') is a data-provenance note, not usage 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 readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds useful context about the payload (position, type, redshift, discovery date/mag, reporting group, internal names), but says nothing about miss behavior — what happens if the name is unknown or unresolvable.

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 packs verb, resource, example inputs and return fields with no filler. Nothing here needs trimming or reordering.

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

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

For a one-parameter read-only lookup with annotations and an output schema, the description covers enough to invoke correctly (input format) and to interpret the result (field list). The only real omission is failure/not-found behavior and an explicit pointer to tns_search for partial-name cases.

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

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

Schema coverage is 0%, so the description must carry the parameter. It does so by giving two concrete accepted forms ('2026agtq' or 'AT 2026agtq'), which resolves a real ambiguity about whether the AT prefix is required — meaningful value beyond the bare 'Name' string field.

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 (look up) and resource (a Transient Name Server object) and enumerates the fields returned, so the agent knows exactly what this yields. It implicitly separates itself from tns_search by emphasizing lookup 'by name', but never names that sibling 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?

Usage is implied by the example name formats, which signal 'use this when you already have a TNS identifier.' However, there is no explicit statement of when to use this versus tns_search, and no guidance on what to do with an ambiguous or partial 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?

Goes meaningfully beyond the readOnly/idempotent/openWorld annotations by disclosing the two execution modes (live bot-authenticated API vs. cached daily public archive) and a hard rate limit of 10/min. The only missing piece is how stale the cached archive can be, which is only hinted at by 'daily'.

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 identifies the source and the query type immediately, with the operational caveats in a parenthetical. 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 need not be described, and the live/cache fallback plus rate limit cover the operational side. But for a coordinate-based tool with three undocumented parameters, the absence of coordinate units/frame guidance is a real gap an agent could stumble on.

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, and it does not: units for ra/dec (degrees vs. hours), coordinate frame, and the meaning of radius_arcsec beyond the parameter name are all left undefined. 'Cone search' gives only the loosest hint about how the three parameters 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?

Names a specific verb+resource pair: 'Transient Name Server cone search', which tells an agent this is a positional/radius query against TNS. It implicitly contrasts with the sibling tns_object (single-object lookup), though it never says so 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?

Usage is only implied by 'cone search' — an agent must infer that this is the tool for 'what transients are near these coordinates' rather than for object-name lookups or nearby-object queries (ztf_objects_near, whats_here). No explicit when-to-use or when-not-to-use guidance is given.

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 adds that results are radius-bounded and lists returned fields, but says nothing about coordinate frame, the small default radius (10 arcsec), or result limits for dense 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?

A single front-loaded line with no filler; the catalog and returned fields come first. It is terse to the point of leaving out units, but every word present 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?

An output schema exists, so return values need not be explained, and the read-only annotations cover safety. However, for a coordinate-based search tool the missing unit/frame semantics are a real completeness gap that the description never fills.

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%: ra, dec and radius_arcsec carry no titles beyond bare names and no units or frame. The description mentions 'within radius' but does not clarify degrees vs. sexagesimal for ra/dec or that radius is in arcseconds with a 10-unit default, so it fails to compensate for the schema gap.

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

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

States a specific resource and operation: a cone search returning AAVSO VSX variable stars within a radius, plus the fields returned. It is reasonably distinguishable from siblings like simbad and gaia by naming the VSX catalog and 'variable stars', though the acronym is never expanded and the verb is implied 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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as simbad or gaia for a generic cone search. The agent must infer from the catalog name alone that this is the variable-star-specific option.

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 read-only/idempotent/open-world safety, but the description adds real behavioral context beyond them: queries run 'all in parallel', partial failure is surfaced ('which sources failed'), and each hit comes with one-line evidence. That partial-failure disclosure is the key trait an agent needs to interpret a low-confidence verdict. It stops short of stating latency or rate-limit implications of the parallel fan-out.

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 decision-relevant question and the source list before the return-value detail; nearly every clause carries information. It is a single dense run-on sentence with stacked parentheticals, which makes the epoch and cutout clauses easy to skim past, but there is little true 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 4-parameter aggregate query, the definition covers the input coordinate frame, the conditional asteroid path, the full verdict precedence order, and the failure-reporting behavior; an output schema exists so the return-shape notes are supplementary rather than load-bearing. An agent can decide to call it and interpret the result without opening the schema, with only radius_arcsec left unaddressed.

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 0% schema coverage the description must carry everything: it specifies ra/dec are decimal degrees in ICRS, and gives the epoch format plus an ISO UTC example and its functional meaning (triggers SkyBoT asteroid lookup). The one clear gap is `radius_arcsec`, which is never mentioned, so its units and which sources honor it are left entirely implicit.

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 operation ('query TNS, SIMBAD, VSX, Gaia DR3, ExoFOP TOI/CTOI, ZTF (ALeRCE)' and SkyBoT) against a specific resource (a sky position), and enumerates the exact verdict taxonomy returned. This clearly distinguishes it from the single-catalog siblings (simbad, vsx, gaia, tns_object) as the aggregate cross-match 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?

The framing question 'Is it already known?' plus the source list makes the intended use obvious: a first-pass identity check on a coordinate before deeper follow-up. The conditional 'if `epoch` is given' explains when asteroid matching activates. However, it never names a sibling or states when to prefer e.g. simbad/vsx for single-catalog detail over this fan-out call.

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 safety and external-service behavior are covered. The description adds useful content context – per-band summary, magpsf and magpsf_corr detections, non-detection limit – but doesn't mention failure modes, latency, or what happens for objects with no ZTF coverage.

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

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

One compact sentence that front-loads the data source and object, then lists return components. No filler, though the parenthetical field names are slightly dense.

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 structure needn't be explained, yet the description usefully sketches its contents; annotations cover the safety profile and the single param is exemplified. Remaining gaps (behavior on empty results, oid sourcing) are minor for a read-only fetch 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?

With a single param and 0% schema coverage, the description carries the burden and does reasonably well: it explains that oid is a ZTF object identifier and gives a concrete example format. It doesn't say where to obtain the id or any validation constraints, keeping it short of a 5.

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 (ZTF light curve from ALeRCE) with a concrete oid example ('ZTF26acatcla') and enumerates the returned components. It implicitly distinguishes itself from siblings like tess_known and ztf_objects_near by being the per-object photometry fetch, but it doesn't name any sibling 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?

The example oid implies when the tool applies (an object already identified with a ZTF id), but there's no explicit when-to-use, when-not, or routing to alternatives like tess_known or ztf_objects_near. Usage is inferred 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, and openWorld, so the description adds nothing on safety or side effects. It names the upstream source (ALeRCE) but says nothing about coverage, radius limits, result caps, 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 tight sentence with the key qualifiers (ZTF, ALeRCE, radius, position) up front. It is efficient, though borderline under-specified rather than deliberately 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?

An output schema exists, so return values need not be explained. However, for a positional cross-match tool sitting among many overlapping catalog siblings, the definition leaves the agent without guidance on selection or on coordinate conventions.

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 burden for three parameters. 'Within radius of a position' at least signals that radius_arcsec controls the search extent, but there are no units or conventions for ra/dec (degrees vs hours) and no mention of the 5-arcsec default.

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 (ZTF objects via ALeRCE) and the operation (spatial cone search around a position), which is enough to separate it from ztf_lightcurve. It is a noun phrase rather than a verb, but the meaning 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 indication of when to use this versus ztf_lightcurve, simbad, tns_object, or whats_here, all of which could plausibly be queried at a position. Nothing tells the agent when this tool is the right choice.

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