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?

アノテーションが無く説明が全責任を負うが、「ローカル蓄積ストアに保存」「外部送信しない」「フローティング日時で保存」など副作用と永続化の挙動を明示している。返り値や必要権限には触れておらず、その点は未開示。

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?

目的→挙動→Args の順で前段に要点が来ており構造は明快。Args の記述は 0% カバレッジを考えれば正当化されるが、やや冗長な面もある。

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?

アノテーションも出力スキーマも無い変更系ツールで 6 パラメータを持つが、保存先・外部送信の有無・日時の扱い・各パラメータを説明しており、呼び出しに必要な情報はほぼ揃う。応答内容やエラー時の挙動には触れていない。

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?

スキーマの説明カバレッジが 0% だが、Args セクションで 6 個すべてのパラメータを書式・例付きで説明している（date の複数書式、time 省略で終日、repeat の列挙値など）。スキーマを十分に補完している。

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?

前段で「カレンダーに自分の予定を追加する」と具体的な動詞＋リソースを明示し、さらに「ローカルの蓄積ストアに保存。外部へは送信しません」とスコープを限定している。calendar_events（一覧）や calendar_event_remove（削除）といった兄弟ツールと容易に区別できる。

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?

追加した予定が space_calendar や calendar_events に現れること、フローティング日時で保存されるため place を変えても日付が動かないこと、海外予定は note に現地時刻を書くことなど、利用時の文脈が明確。ただし削除ツールなど代替手段を明示的に挙げてはいない。

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 idempotent behavior on missing/already-deleted events (returns '該当なし' instead of erroring) and the safety rule of refusing to guess-delete on ambiguous matches. It omits auth/permission requirements (implied only by '自分の') and any rate-limit or return-shape detail.

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

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

Three short sentences, front-loaded with the core action, followed by the two edge-case behaviors. No filler, every sentence earns its place.

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

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

For a mutation tool with no annotations and no output schema, the definition covers the critical behavioral contract (idempotency, ambiguity refusal) and the no-match return. Auth requirements and the exact success return are not described, but nothing essential for correct invocation 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%, so the description must compensate, and it does add meaning for id vs title[+date] usage. However, it does not explain date format, whether id and title are mutually exclusive, or what happens if neither is supplied — the three nullable parameters remain only partially characterized.

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 ('カレンダーの自分の予定を削除する') and immediately names the two accepted identification schemes (id or title[+date]). It is clearly distinguishable from the sibling calendar_event_add and calendar_events without opening any schema.

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

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

Gives concrete guidance on how to target the event (id preferred, or title with optional date) and what happens in the ambiguous case (multiple title matches → do not delete, present candidates). It does not explicitly name a sibling alternative, but the selection rules between id and title are well covered.

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 declares the light path (no diagram, no external API), the retention/auto-deletion behavior applied at call time, and that freshness is exposed via structuredContent.sources. It stops short of describing pagination, ordering, or size of the returned list.

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 and scope in the first line, then layers store composition, retention, usage trigger, freshness, and args in a scannable order. Every sentence adds distinct information 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?

No output schema exists, so the description must cover returns — it identifies the list nature and points to structuredContent.sources for freshness, plus explains retention effects. It leaves the exact return shape (fields per event, ordering) underspecified, but for a read-only listing tool this is close to sufficient.

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

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

Schema description coverage is 0%, so the description must compensate fully — and it does, documenting all four parameters including the defaulting rule for year/month (based on base place), place as the timezone-determining locality with default Tokyo, and the complete kinds vocabulary (user/launch/sky/neo/fireball/public/holiday, comma-separated, 'all').

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 ('蓄積済みのイベント一覧を返す') and narrows scope precisely to the accumulation store, explicitly noting it does not draw a map or call external APIs. It distinguishes itself from the data-producing siblings (space_calendar, calendar_event_add) by describing the store it reads, though it never names a sibling as the alternative for a different need.

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 an explicit trigger ('まず一覧だけ見たいときに使ってください') with concrete example queries, and discloses an important prerequisite: neo/fireball records appear only if neo_close_approach / fireball_reports were previously called. No explicit when-not-to-use or alternative routing is stated, 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?

With no annotations, the description carries the full burden and does so well: it discloses no-auth operation, that results carry raw per-catalog column names and units, that unknown catalog names return a candidate list and stop, radius rounding behavior, and the 57 MB payload risk if catalog is omitted. It still omits return volume/pagination behavior and whether the operation is guaranteed side-effect free, which keeps it short of 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-loaded with purpose and context before the Args block and caveat, and nearly every sentence adds operational value (catalog name list, unit rounding, 57 MB warning). It is somewhat long, but for a 6-parameter tool with zero schema coverage the length is largely earned.

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, no output schema, and 0% schema coverage, the description supplies purpose, usage examples, all six parameter semantics, return-shape expectations (raw columns plus units), and failure behavior for unknown catalogs. An agent has everything needed 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?

Schema description coverage is 0%, so the description must carry everything, and it does: it explains object_name resolution via Sesame/CDS, ra/dec in degrees and their mutual dependency, the full catalog name enumeration plus raw VizieR table names, radius_arcmin range/units/rounding quirk, and max_rows default and cap. 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?

States a specific verb (cone search) and resource (VizieR/CDS observational catalogs) plus that it is a positional lookup, which cleanly separates it from siblings like mast_observations, alma_search, and object_lookup. The concrete examples ('2MASS around M31', 'Gaia DR3 for Sirius') pin the scope precisely.

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?

Examples make the intended use cases clear, and the caveat about ASU scanning all catalogs makes the catalog argument effectively required. However, it never names a sibling or an explicit when-not-to-use condition, so the agent must infer routing on its own.

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 present, the description carries the full behavioral burden and does real work: it discloses that no authentication is needed and specifies the return shape (display summary in content, JSON with id/description/license in structuredContent). These are traits an agent needs and cannot get from the bare schema. It omits pagination/error behavior, keeping it below 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-loaded with purpose, then examples, then return format, then the argument spec — a logical progression with no filler. Slightly repetitive in listing both content and structuredContent, but every sentence 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 single-parameter, read-only listing tool with no annotations and no output schema, the description is largely sufficient: it covers purpose, auth, return payload contents, and parameter bounds. It would be fully complete with a note on ordering/pagination and how it differs from the DLR search sibling.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it documents limit as item count with default 40 and max 100, exceeding the schema which only shows a default and no bound or description. The single remaining gap is that fewer/more-items semantics or ordering are not described.

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 the list of DLR (German Aerospace Center) EOC Earth observation collections, with a scope qualifier (no authentication required). It is distinguishable from the many sibling *_collections tools by naming the provider (DLR). It does not explicitly route to the closest sibling (dlr_search), so it stops short of a 5.

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

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

The two example queries ("German Earth observation data", "DLR Sentinel-2 collection") imply the intended browsing use case, but there is no explicit when-to-use guidance and no mention of the alternative dlr_search for actual data retrieval vs collection listing. Usage 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?

No annotations provided, so the description carries full burden and does so well: it discloses the crucial API quirks (sortby is ignored so use datetime for new-first ordering; max_cloud_cover is filtered client-side because server-side filtering returns 400, and items without cloud info are excluded). This is exactly the behavioral context an agent needs.

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-structured with a clear header, usage examples, return format explanation, and a bulleted Args section. Every sentence adds value, and warnings are clearly marked with the caution symbol.

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 5 parameters, no annotations, no output schema, and 0% schema coverage, the description is remarkably complete: it explains authentication, return format (content vs structuredContent), all parameter semantics, and critical API workarounds. Nothing an agent needs to invoke 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 fully compensate. It does: collection default and where to verify it, bbox format string, datetime formats including the sortby caveat, max_cloud_cover client-side filtering behavior with item exclusion, and limit default and maximum. Every parameter is meaningfully documented.

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), resource (DLR German Earth observation data), and format (STAC), and explicitly distinguishes itself from sibling search tools by naming the provider DLR. The examples ('German Sentinel-2 imagery', 'Berlin EnMAP data') make the 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 clear context: search DLR German EO data, no authentication required, use dlr_collections to verify collection IDs. It implies when to use it (DLR-specific searches) but does not explicitly name alternative tools like stac_search or copernicus_search for non-DLR data.

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 and does so well: it discloses that content carries a display summary plus inline thumbnail, that structuredContent holds the JSON, and that an icon-prefixed image link is always emitted for non-rendering harnesses and must be surfaced verbatim. It stops short of describing error behavior for an unknown identifier or any auth requirement.

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

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

Purpose is front-loaded in the first line, followed by examples and then output-shape notes. The harness/image-link paragraph is somewhat verbose but each sentence carries operational value, so little is wasted.

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

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

For a 2-parameter detail tool with no output schema and 0% schema coverage, the description covers both inputs and explains the return shape (content summary, structuredContent JSON, image_url). Only failure modes for missing identifiers 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%, so the description must compensate, and it does: identifier is documented as a collection ID or name with concrete examples ("N1_NO2", "NO2_daily", "sea_ice") and fuzzy matching, and show_image is explained as the inline-thumbnail toggle with default True.

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 the details (satellite, sensor, description, reference links, image) of a single EO Dashboard dataset. It implies a singular-detail tool versus the sibling eodashboard_collections listing, but never names or contrasts that sibling explicitly.

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

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

Usage is only implied through query examples (「NO2データセットの詳細」), which show the shape of a request but not when to prefer this tool over eodashboard_collections or a search tool. No exclusions or prerequisites are 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?

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 well: it declares no auth required, states that a 0-result query stops and offers host-name candidates rather than guessing, notes that invalid numeric args silently fall back to defaults, and caps limit at 50. It does not mention rate limits or explicitly confirm the operation is read-only (implied by 'search').

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

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

Front-loads purpose and return fields before examples, then Args, then edge-case behavior and the source citation. The structure is clean and nearly every sentence earns its place; the example list is slightly verbose but directly aids tool selection.

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

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

No output schema exists, so the description enumerates the returned fields (period, semi-major axis, radius, mass, equilibrium temp, stellar flux, host type, distance, TIC/Gaia IDs). All 6 undocumented parameters are covered, edge cases are described, and the data source is cited — an agent needs nothing more.

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 entirely and it does: every parameter is explained with semantics beyond its name — partial-match behavior and Japanese-name expansion for object_name, applicable strings/Aliases for discovery_method, parsec units for max_distance_pc, disc_year lower bound for since_year, exact physical criteria (0.5–2.0 Earth radii, 200–320 K) for earth_like, and default/max for limit.

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: searching for exoplanets from NASA Exoplanet Archive, and pins down the exact source table (pscomppars confirmed catalog) plus the fields returned. This is far more specific than the vague sibling names like object_lookup or catalog_search, though it never explicitly names an alternative tool to differentiate 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?

Four concrete example queries ("TRAPPIST-1 planets?", Earth-temperature worlds, nearby planets since 2020, transit-discovered planets) make the intended use context clear without inference. There are no explicit exclusions or 'use X instead' routing, 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?

With no annotations, the description carries the full burden and does so well: no auth/API key required, output split between content summary and structuredContent JSON, velocity frequently missing, unlocated records flagged as 'location unknown', and lat/lon/altitude given at peak brightness rather than landing site. These are exactly the behavioral caveats an agent needs.

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 core purpose and well organized into purpose, examples, output, args, and caveats. Slightly verbose — the 'does not estimate debris/landing sites' caveat is repeated twice — but every section earns its place.

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

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

No output schema exists, so the description explains the return fields (radiant energy J, impact energy kt, entry altitude, lat/lon, velocity) and the content/structuredContent split. For a 4-param, no-annotation tool, 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 coverage is 0%, so the description must compensate, and it fully does: days (1-1825, default 30, UTC filtering), min_impact_energy_kt (kt TNT units, example 0.5, omitted = all), limit (1-50, default 10, newest-first ordering), and require_location (True = only records with lat/lon). Every parameter is given meaning and units.

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 (JPL CNEOS fireball/atmospheric-entry observation records) and explicitly distinguishes it from meteorite-recovery data. An agent can tell exactly what this tool produces 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?

Provides concrete example intents (recent fireballs, big fireballs this month, where observed, did a meteorite fall) and an explicit exclusion (does not estimate debris/landing sites). It doesn't name a sibling tool to use instead, but the scope boundaries are clearly 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 load and does well: it discloses that no authentication is required, that listings are sorted newest-first, that circular_id suppresses the list and returns author/observation-time/body, and that Notices are unavailable here. Rate limits and exact return shape are not covered, keeping it below 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-loaded with the core action, then scope, then args, then caveats – a sensible order with no filler. The background sentence about GCN's role is slightly expendable but supports query formation, so it largely earns its place.

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

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

No output schema and no annotations exist, yet the description covers modes, all four parameters with defaults and bounds, auth posture, ordering, and the Notices/Kafka exclusion. An agent has everything needed to invoke it correctly; only rate-limit and pagination nuance is absent.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: days (1-60, default 7, UTC date filtering), query (with example keywords like GRB/GW/neutrino, defaults to all), circular_id (example '45640', returns one body, no list), and limit (25 default, 100 max) are all documented with constraints 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?

States a specific verb and resource: returns NASA GCN Circulars (transient alerts) and, when circular_id is given, the full body of one Circular. It also carves out scope by declaring machine-readable Notices (Kafka) explicitly out of scope, so the agent can separate it from other astronomy-alert-style 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?

Gives concrete when-to-use examples (last week's GRB, today's GCN, GW follow-ups, EP alerts) and explains the two operating modes: list vs single-item retrieval when circular_id is set. It does not explicitly compare against sibling tools such as astronomy_news or space_weather, so it lands just short of the top.

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: no auth/API key needed, probabilities are estimates that fall as observations accumulate and are removed at zero, they are not confirmed impact forecasts, and the return is split between a display summary (content) and JSON (structuredContent). This is rich behavioral context, not a restatement of the name.

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 summary before the caveats, and the bolded warnings earn their space. It is on the long side with some restated points (the no-key note and the source attribution line), so it is efficient but not maximally tight.

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?

Read-only, three optional parameters, no output schema. The description compensates for the missing output schema by describing what content vs structuredContent contain, covers all three params, and flags the calendar-placement restriction. Nothing an agent needs to call or interpret it 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 fully: designation is given with format examples and an explicit warning that common/Japanese names are rejected; min_probability is defined as the cumulative impact probability (ip) with default 0.1% and range 1e-10–1; limit is bounded 1–50 with default 10 and descending sort order.

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 JPL CNEOS Sentry future impact-risk probabilities. It explicitly differentiates from siblings by naming neo_close_approach and fireball_reports as the date-bearing counterparts, so an agent can route correctly without opening any schema.

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

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

Gives concrete query triggers ("high impact probability asteroids", "2024 YR4 impact risk") and an explicit when-not: results must not go on the calendar because Sentry probabilities span decades rather than a single date. It also names the sibling tools that should be used for dated events 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.