Satellite two-line element sets

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

With readOnlyHint/idempotentHint/openWorldHint already declared, the description still adds real value: it discloses the data source, that CelesTrak data is refreshed daily (freshness), and that no API key is required (auth). It does not describe pagination mechanics or result shape, so not a full 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?

A single well-packed sentence that front-loads the resource and then the two modes, with zero filler. Slightly dense with parenthetical provenance, but every clause (source, refresh cadence, no key) 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 6-parameter, zero-required, no-output-schema lookup tool, the description covers the two access patterns, the data origin and freshness, and the auth situation. Nothing an agent needs in order to call it correctly is missing; return format is standard TLE and need not be restated.

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

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

Schema description coverage is 100%, so every parameter (page, sort, sort_dir, page_size, satellite_id, search) is already documented in the schema, including defaults and the 'cannot be combined' constraint. The description reinforces only the satellite_id-vs-search split and the paged nature; baseline 3 is appropriate when the schema carries the 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?

Names a specific resource (two-line element sets for Earth-orbiting satellites) and enumerates its two operating modes: single satellite by NORAD catalog number, or a paged name search. It also pins the upstream provider and data lineage (tle.ivanstanojevic.me; CelesTrak, refreshed daily). It does not, however, differentiate itself from overlapping siblings such as jpl_horizons or jpl_sbdb, so a 4 rather than 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 phrase 'one satellite by NORAD catalog number, or a paged name search' implies the two usage modes, from which an agent can infer that satellite_id is for a known satellite and search is for discovery. There is no explicit when-to-use/when-not guidance and no named alternative among siblings, so usage is only 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.