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

With no annotations, the description carries the full behavioral burden and does so richly: metadata search needs no auth, FITS download works only for data_rights=Public (Restricted needs proposal rights), obscore contains only calibrated products, name matching auto-absorbs spelling variants, and with_products appends datalink URLs (top 3) as clickable content links.

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, protocol, and a query example are front-loaded before args and caveats. It is dense rather than padded, though the multi-paragraph layout with a long Args block is somewhat heavier than strictly necessary for an agent.

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

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

For a 9-parameter, no-annotation, no-output-schema tool, the description covers purpose, all parameters, auth/permission boundaries, zero-result handling, and the with_products enrichment path. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate and it does for all 9 parameters: object_name examples, ra/dec pairing for cone search, radius default 0.3, band 1–10 with frequency mapping (3≈100GHz, 6≈230GHz, 7≈345GHz), product_type enum meanings (cube/image/visibility/all), public_only, with_products, and limit default 8 / max 20.

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 (ALMA 観測データ / ALMA Science Archive 観測メタデータ) and even identifies the access protocol (IVOA TAP, ADQL). It distinguishes ALMA from infrared/optical telescopes by noting mm/submm radio capability, which separates it from siblings like cadc_observations or jaxa_dataset_search.

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 concrete query examples (M100, HL Tau band 7, cube data) and clarifies the object_name-vs-ra/dec alternative for coordinate cone search. It also defines the 0-result fallback (present candidate names, do not guess). It stops short of explicitly naming when to prefer a different archive sibling, so not a full 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?

No annotations are provided, so the description carries the full burden. It usefully discloses a prerequisite (NASA_API_KEY が必要), which is real behavioral context, but says nothing about rate limits, error behavior, or response shape for a network-backed read.

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

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

Two short sentences, front-loaded with the core purpose and followed by the auth prerequisite. No filler.

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

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

For a single-parameter read tool this is nearly sufficient, but with no output schema and no annotations, the missing date format and any hint about what the response contains (image URL, title, explanation) leave a small but real gap.

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

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

Schema description coverage is 0%, so the description must compensate. It conveys that the date is optional and defaults to today's picture ('今日（または指定日）'), adding genuine semantics, but it omits the expected date format (e.g. YYYY-MM-DD), which is the key detail an agent needs.

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 ('返す' / returns) and a specific resource (NASA's Astronomy Picture of the Day), plus the scope (today or a specified date). It is clearly distinguishable from siblings like astronomy_news or search_space_images, though it does not explicitly name any sibling to route against.

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 '今日（または指定日）' implies that the date parameter is optional and that the tool is the right choice when you want the APOD for a particular day, but there is no explicit when-to-use/when-not guidance or named alternative.

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 zero annotations the description carries the full burden, and it delivers substantive behavioural detail: multi-source fallback order (Sky & Telescope RSS → Universe Today / NASA / Phys.org), the fact that no authentication is required, and the dual return shape (display summary in content, JSON in structuredContent). Freshness, caching, and failure behaviour when all feeds fail are not stated.

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

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

Purpose is front-loaded in the first sentence, followed by examples, fallback behaviour, return format, and a compact argument list. Every element is relevant, though the parenthetical asides make it slightly denser than strictly necessary.

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

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

For a two-parameter, read-only retrieval tool with no annotations and no output schema, the description covers what is fetched, from where, the fallback chain, the no-auth requirement, the return shape, and both parameters. Only edge behaviours (feed exhaustion, limit bounds handling) remain 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?

Schema description coverage is 0% and no enums are declared, so the description must supply all parameter meaning. It documents limit (default 8, maximum 15) and section with the allowed values all/observing/news, which the schema does not encode. It adds clear value but omits e.g. what happens for out-of-range limits.

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

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

States a specific verb and resource ('天文ニュース・観測ガイドを返す') and enumerates concrete content types (daily news, weekly sky guide, planetary observing highlights), so an agent knows exactly what it retrieves. It does not explicitly distinguish itself from near-neighbours like apod, astronomy_weather, or sky_map_with_satellites, which keeps 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?

The example phrasings ('今日の天文ニュース', '今週の星空ガイド', '惑星観測の見どころ') imply when the tool is appropriate, and the section parameter hints at query routing. However, no explicit when-not condition or named alternative sibling is given, so usage is only implied.

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

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

With no annotations, the description carries the full burden and does well: it discloses no authentication needed, global coverage, advice-style output, the rain-imagery attachment behavior, the failure fallback, and the instruction to preserve structuredContent.figure.notes and image links. It does not mention rate limits or explicitly state read-only behavior, but the forecast nature makes this mostly implicit.

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

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

The description is front-loaded with the core purpose, followed by examples and then a structured Args list. It is longer than minimal, but the extra detail, especially the rain-image handling notes, is operationally useful rather than filler. The organization keeps it readable.

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

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

For a tool with six parameters and no output schema, the description covers location specification, parameter semantics, output behavior, and edge cases such as failed image retrieval. It does not explain the exact output format beyond 'AI advice' and optional image links, and it avoids discussion of timezone handling or validation errors, but the agent has enough to invoke it correctly.

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

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

The schema provides no property descriptions, but the description compensates thoroughly by documenting all six parameters: latitude, longitude, place precedence over coordinates, days range with default, max_cloud threshold meaning, and include_rain behavior plus fallback. This adds substantial meaning beyond the bare schema.

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

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

The description states a clear purpose: forecasting the best time windows for astronomical observation based on nighttime, low cloud, and good visibility. It names the data source (Open-Meteo), authentication requirement, and global scope, and the examples (e.g., 'Can I stargaze in Tokyo tonight?') make the resource and intent 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?

The description gives concrete usage context through examples, explains how to specify location via coordinates or place name, and documents parameter ranges and precedence rules. It does not explicitly compare this tool to any sibling tool or state when not to use it, so there is a slight gap in exclusion 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 behavioral burden and does well: it discloses that lookup is unauthenticated for public metadata but partially restricted for image download, that unresolved names are resolved via SIMBAD/NED (Sesame) with Japanese-name expansion and no guessing, and that results are capped (limit default 8, max 20). It does not describe the returned record structure or pagination, so it is strong but not exhaustive.

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

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

Front-loaded with purpose, then scope, then examples, then per-argument semantics, so an agent can stop reading at any level. It is slightly long-winded in the object_name entry, where five example names plus the SIMBAD explanation could be trimmed, but every block still carries usable information.

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

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

For a six-parameter tool with no annotations and no output schema, the description covers selection logic, auth requirements, resolution behavior, and result caps. The only real gap is what a returned observation record contains, though with no output schema that gap is not fully avoidable.

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: every one of the six parameters is defined with units (degrees), defaults (radius 0.5, limit 8), a max (20), value examples ('HST', 'Gemini-North', 'TESS'), and a precedence rule between object_name and ra/dec. This is exactly the semantic detail the bare schema lacks.

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

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

States a specific verb and resource ('CADCの観測データを検索する') and scopes it to concrete holdings (HST, Gemini, NEOSSat metadata) retrieved via ADQL by object name or coordinates. The example queries ('ハッブルが撮ったNGC 300', 'オリオン星雲の観測データ') make the intended use unmistakable and clearly separate it from generic image search siblings like search_space_images.

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

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

Gives clear operational conditions: object_name takes precedence over coordinates, and ra/dec are only used together when object_name is omitted. Auth context ('パブリックメタデータは認証不要。画像ダウンロードは一部要認証') tells the agent when the tool works unauthenticated. It stops short of explicitly naming an alternative (e.g. alma_search or eso_seeing) for overlapping archive queries.

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

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

With no annotations provided, the description carries the full burden and does disclose key traits: it names the upstream source (Launch Library 2 with search=China), states auth is not required, and explains the dual return channels (content summary vs structuredContent JSON). It omits error/rate-limit behavior, but the essential behavioral context is present.

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 is front-loaded in the first line, followed by data source, output format, and args. Slightly verbose with the upstream-source explanation, but each block serves a purpose and nothing is 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 2-parameter tool with no output schema and no annotations, the description covers what it does, the source, the return structure, and both parameters' behavior. An agent has what it needs to call it correctly, though it could note the global-scope alternative for completeness.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it documents limit (default 8, max 15) and status with example values ('Go for Launch', 'To Be Determined') plus the omit-for-all behavior. The max-15 cap and status examples are meaning the schema itself does not convey.

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 ('returns Chinese rocket launch schedule') and scopes it precisely to China, naming the Long March series and private firms (LandSpace). This clearly distinguishes it from siblings like upcoming_launches and russia_launches without the agent needing to open a 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?

The China-only scope implicitly differentiates it from upcoming_launches and russia_launches, and the status filter use is explained. However, it never explicitly names an alternative or states when to prefer this over the global launch tool, leaving routing 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?

No annotations, so the description carries the full burden. It discloses the return shape (display summary + JSON) and the meaningful boundary that no downloads/account are involved, but says nothing about authentication needs, failure behavior when the portal is unreachable, or rate limits.

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

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

Front-loads the core purpose, then examples, then the account/download caveat, then the return note. Information is well ordered, though the Japanese wording is slightly verbose for what is a no-argument status check.

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 status tool with no output schema, the description covers what it does, when to reach for it, the download limitation, and the return format. Nothing essential is missing, though it remains silent on error behavior.

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 has nothing to document and there is no parameter semantics to compensate for; the baseline of 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 (the French CNES Earth observation portal, THEIA/GEODES) and a specific verb (returns reachability status and overview). An agent can distinguish it from the sibling cnsa_status (Chinese agency) and from satellite_status 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?

Gives example trigger phrases ("French CNES satellite data", "THEIA portal") and implicitly draws a boundary by noting that image downloading requires a CNES account and that this tool only checks portal status and data overview. It does not name an explicit alternative tool, so it falls 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?

With no annotations, the description must carry the full behavioral burden. It discloses that the tool reports portal reachability, provides data overviews, and notes that downloading images requires account registration while the tool itself focuses on status and auth-free alternatives. This is useful context, but it doesn't specify return format details beyond 'summary + JSON' or any rate limits.

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

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

The description is front-loaded with the core purpose, followed by examples and a note about account requirements. It is reasonably concise, though the parenthetical listing of agencies is slightly dense and the 'Returns' block is boilerplate.

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 no output schema and no annotations, the description covers the essential aspects: what the tool does, what it returns broadly (summary + JSON), and important context about account requirements and auth-free alternatives. It is nearly complete, missing only explicit routing to sibling tools or detailed output structure.

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

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

The tool takes zero parameters (parameter count 0, required 0), so the baseline is 4. The description correctly implies that no input is needed—it is a status-checking tool—and adds no misleading parameter information.

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

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

The description states a specific purpose: returning the reachability status and overview of three Chinese satellite data portals (FY/NSMC, GF/CNSA-GEO, CBERS/CRESDA). It also provides example queries that reflect the intended use. It is clear, though its distinction from siblings like cnes_status, jaxa_datasets, or copernicus_collections relies on the national/agency scope rather than explicit differentiation.

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

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

Usage is implied through examples ('中国の衛星データ', etc.) and the note about needing portal accounts for image downloads. However, it does not explicitly state when to use this tool versus alternatives, nor does it name a sibling tool for cross-portal search.

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 a decent job: it discloses local computation via NASA JPL ephemeris + Skyfield, that no authentication is needed, and that omitting time_utc defaults to 'now'. It does not discuss response format or numeric precision/frame, but the key operational traits are covered.

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 summary, then a concrete query example, then an Args block — well organized with no filler. The example sentence and the ephemeris note each earn their place.

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

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

For a 4-parameter read/compute tool with no output schema, the description names the returned quantities (altitude, azimuth, constellation) and the input semantics fully. It could say slightly more about the return structure, but nothing required to call it correctly is missing.

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

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

Schema coverage is 0%, yet the description documents all four parameters — latitude/longitude with a Tokyo example, place as a known-name lookup, and time_utc with its format and default. It even states the precedence rule that place overrides latitude/longitude, adding meaning absent from the schema.

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

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

States a specific verb (返す) and precise resource — altitude, azimuth, and constellation of Sun/Moon/planets for a given site and time. It is distinguishable from most siblings, though it does not explicitly contrast itself with the nearby solar_system_now 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 '「今夜東京で見える惑星は?」' example gives a concrete use case, which implies when to reach for it. However, there is no explicit when-not guidance and no routing to alternatives such as solar_system_now, leaving comparison to inference.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses that no authentication is needed, that content holds a display summary while structuredContent holds JSON, and that the limit caps at 100. It does not mention pagination or rate limits, but the key behavioral traits for a read-only listing tool are covered.

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 entry is compact and front-loads the core purpose before examples, return-format notes, and the limit argument. Every sentence contributes information; only the example phrases feel slightly redundant.

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

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

For a simple list tool with no output schema, the description covers purpose, auth requirements, return shape (content summary plus structuredContent JSON), and the single argument's bounds. Nothing essential for correct invocation appears to be missing.

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

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

Schema description coverage is 0% and only one parameter exists, so the description must carry meaning. It explains that limit is the number of items to return, with a default of 20 and a maximum of 100 — the max is not present anywhere in the schema, so this adds genuine value.

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

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

The description states a specific verb and resource: it returns a list of available ESA Copernicus satellite data collections. This distinguishes it functionally from sibling tools like copernicus_search (which presumably searches within collections), though it does not name that sibling explicitly. Clear but lacks sibling differentiation.

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

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

The description notes it requires no authentication and gives example query phrasings (e.g. 'Copernicus satellite data', 'Sentinel collections'), which implies when to use it. However, it never explicitly states when to prefer this over copernicus_search or other collection-listing siblings, leaving the choice to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses that search and preview-URL retrieval need no authentication, while downloading images requires a CDSE OAuth2 account. It also states the return payload shape (content summary, structuredContent JSON with id/datetime/bbox/cloud cover/preview URL). It doesn't mention rate limits or failure modes, but the auth and return-format disclosure 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?

Well front-loaded: one-line purpose, auth caveat, return shape, then an Args block per parameter. Every section earns its place. The natural-language example lines are slightly redundant given the Args block, but they aid intent matching, so the size is justified.

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 5-parameter STAC search with no annotations, no output schema, and 0% schema coverage, the description supplies everything needed: purpose, auth behavior, return payload contents, and per-parameter formats with examples. Nothing critical is missing 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 coverage is 0% and there are 5 parameters, so the description must compensate fully — and it does. Every parameter gets meaning: collection ID with default and cross-reference to copernicus_collections, bbox format 'lon_min,lat_min,lon_max,lat_max' with a Tokyo example, datetime format 'YYYY-MM-DD' or 'start/end' with a concrete range, max_cloud_cover in percent and its applicability condition, and limit default 5 / max 10.

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

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

States a specific verb (search/検索) and resource (ESA Copernicus satellite imagery via STAC) and gives concrete examples (東京のSentinel-2画像). The sibling copernicus_collections is explicitly named as the way to discover collection IDs, distinguishing the two tools.

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

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

Clearly explains when this tool applies (searching Sentinel imagery), notes that search requires no auth, and points to the sibling copernicus_collections for valid IDs. Also gives examples of natural-language intents it serves. It does not, however, contrast with stac_search or uk_stac_search, so the agent must infer which STAC endpoint to choose.

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

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

No annotations are provided, so the description carries the full burden; it usefully discloses that no authentication is required and describes the return shape (display summary in content, JSON with ID/title/summary/license/URL in structuredContent). It omits pagination behavior beyond limit and any rate-limit notes, but for a read-only public search endpoint this is solid disclosure.

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 purpose, then examples, then return format, then args. Reasonably tight, though the example-query block and Args listing add some repetition that could be trimmed.

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 2-parameter, no-annotation, no-output-schema tool, the description covers purpose, auth, parameters, defaults, limits, and return structure. An agent has enough to call it correctly; only explicit sibling routing is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It documents both parameters: query's meaning and example terms plus the omission behavior (returns leading datasets), and limit's default of 10 with a maximum of 20 — the max is not in the schema, so this adds real value.

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

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

States a specific verb and resource ('search datasets' on the CSA open data portal) plus example queries, which is clearer than a bare name. However, with ~40 sibling search tools it never names or contrasts an alternative (e.g. jaxa_dataset_search, copernicus_search), so differentiation relies on the reader noticing the agency 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?

Gives example queries and notes 認証不要 (no auth needed), which implies the usage context. It does not say when to prefer this over the many other dataset-search siblings or state any exclusion conditions.

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

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

With no annotations provided, the description carries the full burden and usefully discloses no-auth access, output format split between content and structuredContent, and the default/maximum limit. It still does not describe rate limits, result ordering, or pagination behavior beyond the limit cap.

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, followed by output behavior, examples, filter values, and parameter semantics. Every section adds useful information for invocation, with no redundant filler.

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

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

Given four optional parameters, no annotations, and no output schema, the description is mostly complete: it covers purpose, auth, output channels, filtering, and parameter limits. It could further describe the shape of the returned structuredContent JSON or the semantics of combining multiple themes.

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

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

Schema description coverage is 0%, so the description must explain all parameters, and it does. It documents themes with examples and comma-separated multi-value support, agency with examples, keyword matching against title and description, and limit with default and maximum values.

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

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

The description clearly states a specific verb and resource: searching EO Dashboard earth observation datasets jointly provided by NASA, ESA, and JAXA. It also gives scale and domain context (173 datasets across atmosphere, ocean, land, etc.). However, it does not explicitly differentiate this collection-search tool from the sibling eodashboard_detail 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?

It gives clear usage context through example queries and theme-based filtering, and notes that authentication is not required. It does not state when not to use this tool or explicitly direct the agent to a preferred alternative such as eodashboard_detail.

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 transparently discloses output format (content with summary + inline thumbnail, structuredContent JSON), the always-emitted fallback link for non-image harnesses, that show_image controls inline rendering, and that identifier accepts rough names. This is rich behavioral context beyond the schema.

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

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

The description is organized as purpose → examples → output behavior → args. Each sentence adds needed information; the link-handling instruction is verbose but critical because it directly instructs the agent on response presentation. No fluff.

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

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

Given the tool's simplicity (2 simple params), the description covers invocation, parameter semantics, and output handling, including a specific field name (structuredContent.image_url). It would benefit from stating error behavior or a structuredContent schema, but for an agent deciding to call, it is sufficient.

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

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

Schema has 0% description coverage, so the description's Args section is essential. It explains identifier as collection ID or name with examples ('N1_NO2', 'sea_ice') and notes fuzzy matching ('大まかな名前でも探す'), and defines show_image's default and role. This fully compensates for the empty 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?

Description states 'EO Dashboard の1つのデータセットの詳細（衛星・センサー・説明・参照リンク・画像）を返す' – a specific verb (返す) and resource (one dataset's details). This clearly distinguishes from collection-listing siblings like eodashboard_collections.

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?

Provides concrete example queries ('NO2データセットの詳細', 'EO Dashboardの海面水温の情報') that signal when to invoke, and scopes itself to a single dataset with '1つの'. It lacks explicit exclusion of alternatives (e.g., eodashboard_collections for lists), so it stops short of full when-not guidance.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose notable behavior: no authentication required, real-time observational data, and the specific fields returned (seeing arcsec, PWV, temp, humidity, wind). It omits data cadence, rate limits, and error behavior, but the auth and return-value context is genuinely useful.

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

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

Front-loaded purpose followed by example queries, auth/return summary, and an Args block — well structured and free of padding. Slightly longer than strictly needed but every section carries information.

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

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

For a two-parameter, no-output-schema, no-annotation tool, the description covers purpose, invocation examples, authentication, return fields, and both parameter constraints. An agent has enough to call it correctly; only field enumeration and freshness/cadence details are missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: hours is described as lookback window with default 12 and max 48, and fields as a comma-separated list where omission means the main fields. It stops short of enumerating valid field names beyond the schema's default string.

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

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

States a concrete verb and resource: returns real-time atmospheric/seeing observation data from ESO Paranal (Chile, VLT). The observatory/instrument scoping makes it distinguishable from the generic sibling astronomy_weather, though it never explicitly names that sibling.

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 three example queries (Paranal seeing, VLT conditions, IR water vapor) imply the user intents this tool serves, giving implied usage rather than explicit when/when-not guidance. With 40+ siblings including astronomy_weather, it should say which queries belong to those tools instead.

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

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

With no annotations, the description carries the full burden and does disclose two valuable behaviors: authentication is not required, and output is split between a display summary in content and JSON in structuredContent. It still omits read-only confirmation, response size/pagination behavior, and error conditions, which for a no-annotation tool is a meaningful gap.

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 purpose line, then return-format note, then the arg doc; every sentence is short and functional. The 'Args:' formatting is slightly boilerplate but not wasteful.

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

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

No output schema exists, so the description correctly fills that gap by explaining that content holds a summary and structuredContent holds JSON. For a single-parameter list tool this is nearly complete; only pagination and result-size expectations are 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?

Schema coverage is 0% and the schema exposes only a default of 30, but the description supplies the upper bound (max 100) that the schema lacks. This is exactly the compensation the low-coverage case requires, though it says nothing about offset/paging semantics.

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

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

States a specific verb (returns a list) and resource (Brazilian INPE satellite data collections), and the parenthetical 'no auth required' plus the CBERS example make the resource identifiable. It does not explicitly name the sibling inpe_search as the contrasting tool, so sibling differentiation relies on the agent's inference.

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 query examples ('Brazil satellite data', 'CBERS collections') imply when this tool is useful, and the no-auth note is a useful precondition. However, there is no explicit statement of when to use this instead of inpe_search or copernicus_collections, so guidance is only implied.

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

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

With no annotations, the description carries the full burden and does well: it discloses no auth requirement, the return shape (display summary in content, JSON with id/日時/bbox/雲量 in structuredContent), the default limit 5 with max 10, that omitted datetime means latest, and that max_cloud_cover only applies when eo:cloud_cover exists. It omits error/pagination/rate-limit behavior, so not a 5.

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

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

Front-loads purpose and the no-auth constraint, follows with two illustrative examples and the return-shape note, then a compact Args block. Every sentence carries information about routing, format, or defaults; nothing is 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 5-param, no-output-schema, no-annotation tool the description is nearly self-sufficient: params, defaults, return shape, and auth are covered. The remaining gap is routing against the numerous other STAC/imagery siblings, which is only implicitly handled via the INPE framing.

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 documents all five parameters with format and defaults — bbox as "lon_min,lat_min,lon_max,lat_max", datetime as "YYYY-MM-DD" or "start/end" with latest fallback, collection default with a pointer to inpe_collections, max_cloud_cover as % conditional on the field, and limit default/max.

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

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

States a specific verb (検索) and a specific resource (ブラジルINPEの衛星画像 via STAC), and names the concrete satellite families (CBERS, Amazonia-1, GOES). This clearly separates it from the many other STAC/imagery siblings such as copernicus_search, uk_stac_search, and generic stac_search.

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

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

Gives concrete example queries ("ブラジルのCBERS衛星画像", "サンパウロ周辺の最近の衛星画像"), states that no authentication is required, and routes the agent to inpe_collections for valid collection IDs. It lacks explicit when-not-to-use guidance against neighboring search tools, so it falls 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that no authentication is needed and that results arrive as a display summary in content plus JSON in structuredContent. It does not state that the operation is read-only, nor anything about rate limits, pagination behavior beyond the limit cap, or error handling.

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

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

Front-loads the core purpose and authentication fact, then organizes parameters in a clean Args block. Slightly padded by the redundant Japanese example topics line that repeats information implied by the kind values.

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 3-optional-parameter read tool with no output schema and no annotations, the definition covers purpose, auth, return channels, and every parameter's semantics and defaults. Only the absence of any read-only assurance and richer return-shape detail keeps it from being fully complete.

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

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

Schema description coverage is 0%, so the description must do all the work, and it does: it enumerates all four allowed kind values with the default, explains query as a partial-match term with examples and the omit-for-all behavior, and gives limit's default (20) and maximum (100).

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

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

States a specific verb and resource: returns official ISRO (Indian Space Research Organisation) data, with concrete example queries (satellites, rockets, centres). The name plus description cleanly separates it from agency siblings like jaxa_datasets, cnsa_status, and inpe_search.

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

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

Gives clear context for use (ISRO-specific data, no authentication required) and enumeration of the four data kinds, which tells the agent when this tool applies. However, it names no alternative sibling and gives no when-not guidance, so it stops short of explicit 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the response shape (content = summary + Google Maps link, structuredContent = JSON lat/long), which compensates for the absent output schema, but says nothing about data source, freshness/latency of a 'now' reading, or caching — meaningful gaps for a positional 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?

Purpose is front-loaded, followed by example queries and return-format notes in a logical order. The trailing 'Returns: CallToolResult: ISS の現在位置情報' largely restates the opening sentence, a minor redundancy.

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

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

With no output schema, the description steps in to explain the return payload (display summary + map link in content, JSON coordinates in structuredContent), which is the main thing an agent needs. It is adequate for a zero-param read tool, though source/freshness details remain 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?

The tool takes zero parameters, so per the rubric 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 verb and resource: returns the ISS's current position and generates a Google Maps URL. The resource (ISS) is inherently distinct from siblings like tiangong_now or sat_ground_track, though the description never names an alternative to route against. Clear but without explicit sibling differentiation.

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

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

The two example utterances ('Where is the ISS now?') imply when the tool applies, giving an agent intent-matching cues. However, there is no explicit when-not guidance and no mention of the closest alternative (tiangong_now for the Chinese station, satellite_status for general tracking), so usage is only implied.

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

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

With no annotations provided, the description carries the full burden and does add real behavioral context: 認証不要 (no authentication required) and the return shape (content holds a display summary, structuredContent holds JSON). It does not mention rate limits or pagination behavior for large result sets, so it stops short of full disclosure.

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 compact and front-loaded: purpose first, then example queries, then the return contract, then the single argument. Every line earns its place with no repetition.

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

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

For a single-optional-parameter listing tool with no output schema and no annotations, the description covers purpose, auth, return channels, and the argument's range. The main missing piece is how it relates to the sibling jaxa_dataset_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% (the schema documents only the default of 30), so the description must compensate, and it does: it explains limit is the number of datasets returned, with a default of 30 and a maximum of 100. The max value is information the schema entirely lacks.

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

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

States a specific verb+resource (returns a list of JAXA Earth observation datasets) and names concrete examples (ALOS/GSMaP/GCOM), which makes the scope unambiguous. It does not, however, distinguish itself from the sibling jaxa_dataset_search, which an agent must choose 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?

The sample queries (「JAXAの地球観測データ」「GSMaP降雨データセット」) imply when the tool is appropriate, giving implied usage guidance. But there is no explicit statement of when to use this list tool versus the sibling jaxa_dataset_search, nor any 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that authentication is not required and describes the return structure (content summary plus structuredContent JSON), but omits pagination, rate limits, 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 front-loaded with purpose, followed by example queries, return format, and an Args section. Every sentence adds useful information without 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?

For a simple no-auth search tool with no output schema, the description covers purpose, parameters, and return format well. It lacks only sibling differentiation and pagination behavior, which are minor gaps for calling the tool correctly.

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

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

Schema description coverage is 0%, so the description must document parameters. It does so fully: query is explained with domain-specific examples, and limit is documented with its default (10) and maximum (100), adding constraints not present 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?

States a specific verb ('キーワード検索') and resource ('JAXA Earth のデータセット'), plus notes authentication is not required. It does not explicitly differentiate this from the sibling jaxa_datasets or other dataset search tools.

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

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

Usage is implied through query examples ('GSMaP', 'ALOS', 'GCOM') and the no-auth note. No explicit when-to-use versus alternatives or when-not-to-use guidance is provided.

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

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

With no annotations, the description must carry the full behavioral burden, and it does disclose meaningful traits: auth-free access, the fact that only MSL/Curiosity currently has a working weather feed, and that the Photos API is deprecated so photos are not retrieved. It does not describe the return format or rate limits, leaving a small gap.

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, followed by usage examples and then a tidy Args block separated from the body. It is efficient overall, though the leading 'photos' claim adds a misleading line that a leaner description would have dropped.

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

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

With no output schema and no annotations, the description covers what is needed to call the tool and even enumerates returned weather fields (temperature, pressure, wind, sol, Earth date, season). The deprecated-parameter explanation closes the main ambiguity, leaving only minor gaps around response format.

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 fully: 'rover' is explained with its default ('curiosity') and the caveat that 'perseverance' weather is unavailable, and 'show_photos' is explained as a deprecated compatibility no-op. This adds substantial meaning beyond the bare schema titles and defaults.

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

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

The opening sentence gives a specific verb and resource ('NASA Mars rover current status/weather/photos'), which clearly separates it from location-oriented siblings like planetary_rover_location_map. However, the headline promises 'latest photos' while the Args section states photos are no longer fetched, so the stated purpose is partially self-contradictory.

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?

Concrete trigger examples are provided ('Curiosity current status', 'Perseverance weather'), which give clear context for invocation. It also notes no authentication is required. It stops short of naming an alternative tool or stating when not to use it, so exclusions are absent.

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

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

No annotations are provided, so the description carries full responsibility. It thoroughly discloses no-auth local calculation, self-verification via figure.verify, local-time handling based on UTC offset, output image saving, the always-present file link, and structuredContent.image_path. This is rich behavioral disclosure.

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

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

The description is long but well-structured: purpose and examples first, then behavioral notes, then an Args list. Every sentence carries operational value; the clear organization makes the length manageable for an agent.

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 no annotations and no output schema, the description covers outputs, side effects, defaults, parameter precedence, and harness-specific fallback behavior. An agent has everything necessary to invoke the tool correctly.

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

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

Schema description coverage is 0%, yet the description documents every parameter: date formats and default, place with examples and precedence rules, lat/lon behavior, layout values, and days constraints (3–12, default 8, ignored in calendar). It fully compensates for the empty schema.

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

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

The description clearly states that the tool returns a moon age map (月齢マップ) with one month of lunar phases arranged in a figure, and provides concrete example queries. It identifies the resource and action well, but does not explicitly contrast itself with sibling map tools beyond referencing shared geometry with solar_eclipse_series.

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

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

The description gives concrete example prompts and clearly explains when to use layout='calendar' versus layout='lunation', including that 'days' is ignored in calendar mode. It provides clear usage context but does not explicitly state when to choose this tool over alternatives or list 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?

No annotations are provided, so the description carries the burden; it usefully discloses that a NASA_API_KEY credential is required, which is real behavioral context. However, it says nothing about rate limits, caching, failure modes, or the shape of the returned data, leaving significant gaps for a tool with zero annotation 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?

Two short, front-loaded sentences with zero waste: the first states what is returned, the second states the prerequisite. Nothing is padded or 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?

For a zero-parameter, read-only lookup with no output schema, the description covers the essential facts: what it returns, the temporal window, and the credential requirement. It could say slightly more about the return content, but it is adequate to call the tool correctly.

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

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

The tool takes zero parameters, which is the baseline-4 case. The description correctly implies there is nothing to configure, so no parameter explanation is needed or missing.

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

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

States a specific verb and resource ('returns asteroids (NEO) approaching Earth today'), which is unambiguous and distinct from nearby siblings like solar_system_now or sky_map_with_satellites. It does not explicitly name an alternative sibling, but the scope is narrow enough that confusion is unlikely.

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 word 'today' implies the temporal scope, but there is no guidance on when to pick this over related tools (e.g. sky_map_with_satellites, planetary_orbiter_track) or any stated exclusions. 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?

With no annotations, the description carries the full transparency burden and does so thoroughly. It discloses the underlying computation (JPL Horizons state vectors, IAU rotation model, NASA Trek map), output storage path, structuredContent.image_path and impact_site fields, the always-prepended image link for non-rendering harnesses, authentication-free access, and the fact that flag positions are not available. This is unusually complete behavioral disclosure for a tool with no annotations.

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

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

The description is long but appropriately so for a tool with nine parameters, zero schema descriptions, and no annotations. It is front-loaded with purpose and examples before diving into technical details, and the per-parameter explanations are scannable and information-dense. Every major sentence adds usable guidance for an agent.

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

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

Given the tool's complexity, nine parameters, no output schema, and no annotations, the description is complete enough for correct selection and invocation. It covers what the tool returns, how to use each mode, examples of valid queries, defaults, constraints, authentication expectations, file output behavior, and structuredContent fields. An agent can invoke this tool correctly without additional context.

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

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

Schema description coverage is 0%, so the description must fully compensate. It does: every parameter (body, orbiter, when, minutes, step, zoom, span_deg, out_px, sites) receives an explanation including defaults, ranges, accepted values, valid aliases, and conditional behavior. This goes far beyond what the bare input schema provides.

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

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

The description clearly states that it returns an image plotting the current position and trajectory of a spacecraft orbiting a celestial body on that body's map, using concrete verbs and resources. It includes multiple example queries (LRO, MRO, Kaguya, Apollo) that make the tool's scope and output unmistakable, and the "sites" mode and past-probe impact-point behavior further define its exact function.

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

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

The description gives strong usage context via examples and parameter modes: it explains when to use past-probe impact-point handling, when the "sites" marker mode applies, and how zoom/span_deg behavior changes. It does not explicitly compare this tool to siblings like sat_ground_track or planetary_rover_location_map, so exclusion guidance is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that no auth is required, the underlying data source (NASA MMGIS / Mars), the rendering pipeline (NASA Trek equirectangular tiles with orange path line, red current-position dot, blue landing-site dot), the fact that a file is written to disk (a side effect), and the structuredContent.image_path return. It even explains the fallback behavior for harnesses that cannot render inline images.

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, followed by examples, then a behavior/render block and an Args block — a logical structure. The final paragraph about inline-image linking is somewhat verbose and repeated in intent, but it documents genuinely necessary fallback behavior rather than 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?

For a 5-parameter tool with no output schema and no annotations, the description covers what the tool produces (an image plus structuredContent.image_path), how it renders, all parameter semantics, and environment constraints. There is no output schema, so the description rightly explains the return artifact itself.

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 fully documents all five parameters with defaults and semantics: body (default mars, bounded by planetary_map bodies), rover (perseverance default, curiosity), zoom (defaults to the body maximum, Mars=7, higher is more detailed), span_deg (longitude width in degrees, default 0.5, larger = wider but lower resolution), and out_px (default 1000, max 2000).

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

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

The description states a specific verb and resource: it returns a rendered map image showing a rover's current position on an arbitrary celestial body. The purpose is unambiguous, though it never explicitly distinguishes itself from the sibling 'mars_rover_status' (data vs. rendered map), leaving that disambiguation to inference.

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?

Two example queries ("Perseverance's current location on a Mars map", "where is Curiosity now") make the intended use case concrete. However, there is no explicit when-not guidance nor a direct comparison to the alternative 'mars_rover_status' tool, so the routing signal is contextual rather than explicit.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that no authentication is required and that data is typically several days to months old and returned as a period average, but omits rate limits, error conditions, and response format details.

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

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

The description is front-loaded with purpose, then examples, then parameter details. It is appropriately sized and structured for a data-retrieval tool, with each section serving a clear purpose, though the Japanese prose is slightly repetitive.

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 no output schema and no annotations, the description covers the main invocation needs: purpose, authentication, data latency, averaging behavior, and all parameters. It does not describe the exact return fields or units, but is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0% for all five parameters, so the description must compensate. It documents every parameter: latitude and longitude with examples, start/end as YYYY-MM-DD with defaults, and parameters as a comma-separated list with a default set, adding substantial meaning beyond the bare schema.

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

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

The description clearly states the verb (returns) and resource (past climate/solar energy statistics) and specifies the source API (NASA POWER) and no authentication. It distinguishes the tool from space-focused siblings by describing climate/solar data for arbitrary points, but does not explicitly name or contrast with any sibling tool.

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

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

Usage is implied through examples such as “Tokyo’s solar irradiance over the past year” and “temperature data for Hawaii,” and the data scope is described as period averages of past daily data. There is no explicit guidance on when to use this tool versus alternatives or when not to use it.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: no authentication required (stated twice), real-time retrieval, and the default observing site when lat/lon are omitted. It still omits return format, latency/freshness of the catalog, and any rate limits, which is a real gap for an unannotated data 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?

Front-loads the one-line answer before elaboration, then an examples block, then an Args block that maps cleanly to the parameters. Slightly repetitive ('認証不要' appears twice) but every sentence carries content, so only minor trimming is possible.

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 is the only source of truth. It names the source categories returned but never describes the response shape (fields, ordering, units), leaving the agent guessing about what comes back from this data-returning 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%, but the description compensates fully: lat/lon (degrees, default TART site -45.87/170.60), alt (meters, default 100), elevation (minimum elevation above horizon, default 10, higher excludes near-horizon sources), and limit (default 15, max 50). The max-50 cap and the semantic effect of elevation are information not present anywhere 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?

States a specific verb and resource: it returns radio sources currently observable by the TART open radio telescope, with the source types (GNSS, geostationary satellites) named explicitly. An agent can distinguish this from siblings like sat_tle or sky_map_with_satellites because the scope (real-time over-the-horizon sources from the TART catalog) is stated up front.

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

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

Gives example queries ('what's overhead now?', 'satellites Dunedin's telescope sees') and frames it as educational/research use, which implies when it fits. However, it never names an alternative tool or an explicit when-not-to-use condition, so routing versus sat_tle, iss_now, or sky_map_with_satellites is left to inference.

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

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

With no annotations, the description must carry the full behavioral burden. It discloses the Wikidata source, that launch_date=True sorts by launch date while False lists objects, and that country_qid takes priority over country. However, it omits read-only nature, permissions, rate limits, error behavior, and return structure.

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

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

The description is front-loaded with purpose, then examples, then an Args block. Every part earns its place: the examples illustrate usage and the Args block compensates for the zero schema description coverage.

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 7-parameter lookup with no annotations and no output schema, the description covers all inputs and key behavioral details. It is nearly complete, but it does not describe the return shape or what fields the Wikidata results contain, which matters because no output schema is provided.

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

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

Schema description coverage is 0%, so the description must explain all parameters. It does: category with examples, launch_date sorting vs listing, country with example values and auto Q-id resolution, country_qid priority, limit default, order asc/desc meaning, and language for labels.

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+resource: reverse-looking up first/record space objects from Wikidata filtered by category and country, with concrete examples. It is clear what the tool does, though it does not explicitly differentiate itself from the many sibling search/lookup tools.

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

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

The examples ('米国で最初に打ち上げた宇宙望遠鏡は?' → category/country) clearly establish when to use the tool for historical 'first/record' queries. It gives no explicit exclusions or named alternatives among siblings, but the context is clear enough.

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?

Without annotations, the description carries the full burden. It discloses the data source (Launch Library 2 with search=Roscosmos), that authentication is not required, and the return format (content summary plus structuredContent JSON). It lacks rate-limit or error-handling details, but covers key behavioral traits well.

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

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

Front-loads the purpose, then provides source/auth/output context, then a compact Args section. Every sentence contributes useful information, though the justification for using the aggregator API is slightly verbose and could be tightened.

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 tool with two optional parameters and no output schema, the description covers purpose, data source, authentication, return format, and parameter behavior. Minor gaps like error handling or pagination are unlikely to impede 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 compensate. It documents both parameters: limit (default 8, maximum 15) and status (filter by state, example "Go for Launch", omitted returns all states). This adds meaningful constraints and semantics beyond the bare schema.

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

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

States a specific verb (returns) and resource (Russian/Roscosmos rocket launch schedule), naming example vehicles (Soyuz, Proton, Angara) and the data source. An agent can immediately tell this is the Russia-focused launch tool, distinct from global or other national launch siblings.

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

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

Usage is implied by the country scope: use this for Russian/Roscosmos launches. However, it never explicitly states when to use it versus siblings like upcoming_launches or china_launches, nor does it provide exclusions. The note about no direct Russian API explains the source choice but is 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 provided, the description fully carries the behavioral disclosure burden. It discloses the full-catalog scan (~1,000 entries), match ordering for queries, the ~40-second first-call latency, disk caching, 24-hour refresh behavior, and the content vs. structuredContent return split.

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

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

The description is front-loaded with purpose and structured with examples, behavioral notes, and an Args section. Although long, every sentence provides actionable information for correct invocation, especially the performance caveat and matching behavior.

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

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

Given no output schema and no annotations, the description is remarkably complete: it explains return formats, query semantics, parameter constraints, performance expectations, and edge-case reporting such as unmatched pages. An agent has enough context to invoke the tool correctly and interpret its results.

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: query is explained with matching rules and Japanese-to-English expansion, agency is given with concrete examples, and limit is fully specified with default and maximum values.

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 ('返す' / returns), a clear resource (WMO OSCAR satellite catalog), and a distinct domain (weather and Earth observation satellite operational status). It includes concrete examples and differentiates itself from sibling tools focused on TLE, positions, or imagery.

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

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

The description gives clear context for when to use the tool: when querying operational status, orbit, or launch dates of WMO OSCAR catalog satellitesтное. It provides example queries and parameter usage, though it does not explicitly name alternative tools or state when not to use it.

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 delivers: it names the data source (CelesTrak TLE), the propagation method (Skyfield/SGP4), states no authentication is required, explains longitude ±180 trail splitting and subpoint accuracy, and discloses the file output path plus the mandatory link behavior in content and structuredContent.image_path.

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?

Content is front-loaded — purpose first, then examples, then mechanism, accuracy notes, and finally per-argument documentation — so the reader can stop early. It is somewhat long and the accuracy paragraph is dense, but almost every sentence adds actionable detail rather than 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?

Although there is no output schema, the description explains the return surface thoroughly (generated image, its saved file path, structuredContent.image_path, and the inline link for harnesses that cannot render images). Combined with documented parameter behavior, an agent has everything needed to call and present the result.

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

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

Schema coverage is 0% and the description fully compensates, documenting all six parameters with defaults, ranges, and precedence: norad_id takes priority over name, name accepts abbreviations and falls back to a TLE search, when is ISO8601 with 'now' as default, minutes defaults to 45 with a 1440 cap, step default 1 / min 0.5, out_px default 1200 / max 2048.

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 gives a specific verb and resource — plots any satellite's current position plus ground track onto an Earth map image, which implicitly separates it from narrower siblings like iss_now or satellite_status. It never explicitly names or contrasts a sibling tool, so it stops short of full differentiation.

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

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

Concrete example queries ('ISSの現在位置を地球地図で', 'ハッブルの軌道') make the intended use obvious, and it adds situational guidance such as using minutes≈720 to see QZSS' figure-eight orbit. It offers no explicit when-not-to-use guidance or named alternatives among the many sibling tracking tools.

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

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

With no annotations, the description carries the full burden and does well: it discloses the data source (CelesTrak/NORAD), that no auth is needed, the return shape (content summary plus structuredContent JSON), name-resolution behavior for Japanese names, and that unresolved names stop with suggestions. It omits rate-limit/error nuances but is substantially more informative than typical.

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 and examples are front-loaded, and the return-format line precedes the parameter docs. The example list is slightly redundant with the parameter examples, but overall it is efficient and well-organized.

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

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

For a read-only lookup with no output schema, the description explains the return structure, the data source, the no-auth posture, and the failure behavior on unresolved names. Nothing an agent needs to invoke it correctly appears to be missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does fully: name (with examples and Japanese-name auto-resolution), norad_id (with 25544=ISS example and explicit precedence over name), group (CelesTrak groups), and limit (default 5, max 20). Every parameter's meaning and constraints are supplied.

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

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

States a specific verb and resource: returns TLE orbital elements for arbitrary satellites, with concrete examples (ISS, Hubble, weather sats, Chinese station). The TLE-specific scope distinguishes it from siblings like satellite_status or sat_ground_track without needing to name them.

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

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

Usage is conveyed only implicitly through example queries ("ISSの軌道要素", "ハッブルのTLE"), and it notes no authentication is required. There is no explicit when-to-use vs. when-not guidance or reference to the competing sibling tools, leaving the agent to infer selection.

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

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

With no annotations provided, the description carries the full burden and does disclose behavior beyond structured data: it explains that content returns a display summary while structuredContent returns JSON with title/play-URL/type/duration, and it specifies how result links are rendered for non-inline harnesses. Auth requirements, rate limits, and failure/empty-result behavior are still unstated, which keeps it out of the top band.

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 shape are front-loaded, and the parameter guidance is grouped under an explicit Args section. It is longer than strictly necessary because the icon-link formatting instruction and the three examples partially restate the kind guidance, but every block remains actionable.

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 correctly takes on the job of explaining return values (content summary plus structuredContent fields) and the link format. What is missing is guidance on empty or failed searches and on upstream source coverage, which would matter for an agent deciding whether a miss means 'no results' or 'wrong tool'.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: query is illustrated with concrete example terms, limit is documented as default 3 / max 10 (a bound absent from the schema), and kind's three accepted values and their meanings are spelled out despite no enum being defined.

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

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

The opening sentence states a specific verb (検索) and resource (宇宙関連の音声) plus the concrete output (再生可能な音声URL). This clearly separates it from siblings such as search_space_images and search_space_videos, which cover other media types.

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 concrete routing rules for the internal modes — kind="sound_effect" for short sounds, kind="podcast" for long talks, and kind="auto" to search both — reinforced by three worked examples. It does not, however, say when to prefer this tool over sibling media search tools, so it stops short of full alternative coverage.

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 behavioral burden and does so well: it discloses the dual return channels (structuredContent JSON fields vs. content summary with inline images), the bandwidth-driven inline default, the max values not present in the schema, and the exact icon-prefixed link format so it renders even on CLI/Android harnesses.

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

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

Front-loads purpose, then return-shape, then examples, then args — a logical order. It is slightly verbose with some restatement of the inline/link behavior, but every section carries information an agent needs to call and present results correctly.

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 tool with no annotations and no output schema, the definition is complete: it explains fetch behavior, both return surfaces, per-field output content, and the presentation contract for downstream harnesses. Nothing needed to invoke or relay results is missing.

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

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

Schema coverage is 0% and the schema holds only defaults, yet the description documents all four parameters including constraints absent from the schema (limit max 10, inline_max max 5) and the practical hint that English queries are more reliable. This is meaningfully more than the structured fields provide.

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

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

States a specific verb (検索し表示する) and resource (惑星・人工衛星・宇宙ミッションの画像) sourced from the NASA Image & Video Library, and the example queries make the target media unambiguous. It is readily distinguishable from siblings search_space_audio and search_space_videos.

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?

Provides concrete example queries (火星の画像, ハッブルの写真, アポロの画像) that show when to reach for this tool, and implicitly positions it as the image counterpart to the audio/video siblings. It never names an alternative explicitly or states exclusions, so it falls 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?

With no annotations, the description carries the full burden and does well: it distinguishes content (summary + inline poster) from structuredContent (JSON with title/play URLs/resolution URLs/subtitles), warns that the video is too large to base64-embed and must be streamed from URL, and specifies how links render in CLI/Android harnesses. Auth, rate limits, and error behavior remain unstated, keeping it from 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?

Content is front-loaded: purpose and return shape come first, then args, then link-rendering detail. The format guidance is somewhat verbose and the link-format paragraph could be tightened, but every block serves the caller.

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 exists, yet the description explains both return channels (content vs structuredContent), the poster behavior, and that playback happens via URL rather than embedded data. An agent has everything needed to call and render the result 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 and it does: query is documented with a recommendation to use English, limit is given both default (3) and max (10), and show_poster states its default and meaning. This adds meaning well beyond the bare typed schema.

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

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

States a specific verb (検索) and resource (宇宙関連の動画 – 打ち上げ・ミッション映像・解説) plus the return type (再生用MP4 URL). The topic clearly separates it from siblings like search_space_images and search_space_audio, though no sibling is named 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?

Provides concrete triggering examples (「火星の動画」「ロケット打ち上げ映像」「ハッブルの映像」) that map intent to the tool, giving clear context for use. It does not state when NOT to use it or explicitly route to the image/audio siblings, 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?

No annotations, so the description carries the burden. It discloses computed data sources (JPL de421 + Skyfield, CelesTrak TLE + SGP4), no-auth requirement, inline base64 output, temp file path, and the link behavior for harnesses that can't render images. Lacks error handling or rate-limit notes.

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

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

Front-loaded core purpose, but the body is long and mixes Japanese and English, with duplication around engine behavior and the link generation. Some content could be trimmed.

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

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

Covers all parameters, default behavior, output format, and fallback link for non-rendering harnesses. Missing an output schema means the description must explain return values, which it does partially (base64 inline, structuredContent JSON).

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 lists all five parameters with meaning, allowed values for engine, default for place and when, and precedence rules (lat/lon over place, place ignored when lat/lon given).

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 (returns a diagram) and resource (sky map overlaying solar-system planets and satellites), with a concrete example list. It clearly distinguishes itself from siblings like iss_now and solar_system_now by combining both in one rendered image.

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

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

Gives example queries and recommends the Pillow engine for students/observation, but doesn't explicitly say when NOT to use this versus iss_now or solar_system_now for a specific need.

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 fully carries the burden of behavioral disclosure. It reveals the JPL DE421 + Skyfield calculation basis, the 1400-day search window, the visibility constraint, the behavior when a total eclipse is below the horizon, and the exact file/link output behavior. Nothing seems hidden or contradictory.

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

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

The description is front-loaded with purpose and examples barrier to understanding, and every section serves an operational need. It is long and includes some implementation rationale, such as why 1400 days are used instead of 800, but this extra detail is still useful for setting expectations.

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 no output schema and no annotations, the description covers input semantics, automatic search behavior, visibility edge cases, image generation modes, file save paths, and how the agent should present the result. An agent has enough information to invoke it correctly and interpret the response.

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

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

Schema description coverage is 0%, but the description compensates by explaining every parameter: date formats, place examples, lat/lon precedence over place, defaults, and the effect of max_magnitude. This is far richer than the bare JSON 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 opening sentence names a specific verb and resource: it returns time-series panel images of solar eclipses, with the Sun being obscured by the Moon. Concrete example queries further clarify scope, and the domain is clearly distinct from the generic image/space tools among siblings.

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

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

The description gives operational guidance: date omission triggers an automatic next-eclipse search, max_magnitude=True selects a single-image mode, and visibility is restricted to periods when the Sun is above the horizon. It does not compare against sibling tools by name, but provides clear context for when and how to use the tool.

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