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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It explains the tool's purpose and parameters but does not discuss side effects, rate limits, or authorization needs. It neither contradicts nor adds significant behavioral context beyond the functional description.

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 well-structured with a clear summary and an Args section. It is somewhat lengthy but every sentence adds value given the tool's complexity. It is front-loaded with the main purpose, making it efficient for quick scanning.

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

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

Given the tool's complexity (9 parameters, nested objects, no output schema), the description covers parameters well but omits the return format. It directs users to list_access_options() for additional context, which serves as a partial substitute for missing details.

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 explain each parameter. It does so thoroughly in the Args section, including details like expected keys for location, required source key for satellite, and constraint structure. This adds substantial meaning beyond the bare schema types.

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 it computes visibility periods between a satellite and a ground location. It provides a specific verb and resource, but does not explicitly differentiate from sibling tool compute_access_from_gp, though it implies flexibility in satellite input format.

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 advises using list_access_options() to learn about constraints and config options, which is helpful. However, it does not specify when to prefer this tool over alternatives like compute_access_from_gp, nor does it mention prerequisites or the need for a valid satellite source.

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. It explains the tool is a convenience wrapper that delegates to compute_access, and lists all parameters with meanings. It does not mention side effects or return details, but the delegation nature is transparent.

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 starts with a clear one-line summary and uses a structured parameter list. Though lengthy, every part serves a purpose. Could be slightly more concise by grouping related info, but it's well-organized.

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

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

With 12 parameters, 4 required, no output schema, the description covers all parameters, explains the typical use case, and references sibling tools. It lacks return value details (expected given no output schema), but is otherwise complete for an expert user.

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

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

Schema description coverage is 0%, but the description provides detailed explanations for each parameter, including types, defaults, and expected structure (e.g., gp_record dict, location with lon/lat). This adds significant meaning beyond the bare schema.

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

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

The description clearly states it's a convenience wrapper for creating a satellite spec from a GP record and delegating to compute_access(). It specifies the common workflow involving get_celestrak_gp() or query_spacetrack_gp(), distinguishing it from compute_access which likely requires a pre-built spec.

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 explicitly says 'This is the most common workflow' and points to the preceding GP fetch tools, providing clear context on when to use this tool vs alternatives. It lacks an explicit when-not statement but the context is strong.

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 description carries full burden. It does not explicitly state side effects, authorization needs, or idempotency. However, the verb 'compute' implies a read-only operation, and the description provides useful default values (gm, r_body, angle_format). Overall, basic transparency but lacks depth.

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 brief intro followed by parameter list. Each line adds value. Could be slightly trimmed but remains informative without unnecessary 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?

Covers input parameters thoroughly and directs to list_orbital_computations for computation details. However, without an output schema, the description lacks information about return values, error behavior, or computational limits. This leaves a gap for a tool with 9 parameters.

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

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

Schema description coverage is 0%, but the description compensates fully by explaining each parameter's meaning, units, and defaults (e.g., 'a: Semi-major axis in meters', 'state_eci: ECI state vector as comma-separated string'). This adds significant value beyond the bare schema.

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

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

The description clearly states the tool computes an orbital property using 'brahe astrodynamics functions'. It specifies the verb 'compute' and resource 'orbital property', and distinguishes from siblings by mentioning available computations via list_orbital_computations(). No ambiguity.

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

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

Explicitly advises users to first use list_orbital_computations() to see available computations and parameters. This provides clear context on how to discover valid inputs. Does not list alternatives or exclusions, but the purpose is distinct from sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It mentions case-insensitivity, default angle format, but lacks details on error handling, precision, or limits. This is sufficient for a simple conversion tool but not comprehensive.

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 efficient: one sentence for purpose, a reference to list_orbital_computations(), and a clean Args block. No extraneous 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?

Given the tool's simplicity, the description covers the essential aspects: conversion type, input parameters, and where to find valid conversions. Lack of output schema is acceptable for a numeric conversion tool.

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

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

Despite 0% schema description coverage, the Arg block explains each parameter's purpose and constraints (e.g., anomaly in angle_format, e is dimensionless). This adds significant value beyond 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?

The description clearly states it converts between orbital anomaly types (mean, eccentric, true). The name 'convert_anomaly' is self-explanatory, and it distinguishes from other convert tools like convert_epoch and convert_position.

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

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

It directs users to list_orbital_computations() to see available conversions, providing guidance on valid inputs. However, it does not explicitly state when not to use this tool or compare with alternatives.

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 convey all behavioral traits. It explains the conversion process and parameter options but lacks details on error handling, input validation, or precision limits. The behavior is generally well-described 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?

The description is well-organized with clear sections for Args and parameter details. While comprehensive, it could be slightly more concise without losing essential 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?

Given the lack of output schema and low schema coverage, the description covers inputs thoroughly but does not describe the return value format or error scenarios. It is mostly complete for practical use.

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 compensates fully. It explains each parameter with examples and allowed values, adding significant meaning beyond the schema's titles and defaults.

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

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

The description clearly states 'Convert an epoch between time representations and time systems.' It lists supported formats and time systems, making the tool's purpose distinct from sibling tools like convert_anomaly or convert_position.

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

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

The description provides examples for each parameter and lists all supported formats/time systems, aiding usage. However, it does not explicitly state when to use this tool versus alternatives or mention any prerequisites or constraints.

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

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

No annotations are provided, so the description carries the burden. It discloses that epoch is required for ECI<->ECEF and GCRF<->ITRF, and that angle_format applies to geodetic/geocentric angles. However, it does not cover error behavior or system limitations.

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 reasonably concise and front-loads the main purpose. The list of supported conversions is helpful but could be more compact. Overall, it is free of fluff and well-organized.

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

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

Given the tool complexity (multiple coordinate frames) and lack of output schema, the description covers supported conversions, parameter details, and conditional requirements. Minor gaps exist (e.g., vector unit expectations), but completeness is strong.

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 fully explain parameters. It provides an 'Args' section with clear explanations for vector, from_frame, to_frame, angle_format, and epoch, including defaults and conditional requirements (e.g., epoch needed for certain conversions).

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

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

The description clearly states that the tool converts a 3-element position vector between coordinate frames, and explicitly lists supported conversions (e.g., GEODETIC<->ECEF, GCRF<->ITRF). This distinguishes it from sibling tools like convert_anomaly or convert_epoch.

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 does not explicitly state when to use this tool versus alternatives such as convert_state or convert_relative_position. It mentions that epoch is required for certain conversions but lacks guidance on selection among coordinate conversion siblings.

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. The description discloses supported conversions, parameter details, and defaults. It is transparent about the transformation but does not mention error handling or unsupported input 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 well-structured with a summary line followed by parameter details. It is concise yet includes all necessary information, though slightly verbose with the 'Args' section.

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 and the description does not describe the return value format (e.g., output is a 3-element array in target frame). This omission reduces completeness for a conversion tool.

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

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

Since schema has 0% description coverage, the description fully explains all 6 parameters: station format (geodetic/geocentric/ecef), vector, from_frame, to_frame, station_type, angle_format. It provides allowed values and defaults, adding significant value beyond 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?

The description clearly states the tool converts a position relative to a ground station between ECEF and topocentric frames, listing specific supported conversions. It distinguishes from sibling tools like convert_position by specifying the station-relative context.

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 does not explicitly guide when to use this tool versus alternatives like convert_position or convert_state. It lists conversions but lacks context on selection criteria or exclusions.

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

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

No annotations are provided, so the description carries full burden. It discloses supported conversions, conditional requirement for epoch, and angle format. It does not discuss errors or side effects, but for a conversion tool this is adequate. Overall transparent for its purpose.

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 well-structured with purpose first, then supported conversions, then parameter details. It is slightly verbose but avoids unnecessary repetition. Every sentence adds value. Could be tightened slightly.

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 params, 0% schema coverage, and no output schema, the description is fairly complete. It covers all parameters and conversion rules. However, it does not explicitly state the output format (presumably also a 6-element state vector). Minor 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 fully explain parameters. It does: vector format, allowed frames, angle_format default, epoch requirement. Adds meaning beyond schema names, including explicit list of frames and conversion dependencies.

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 'Convert a 6-element state vector between coordinate frames,' which is a specific verb and resource. It lists supported conversions and distinguishes from sibling tools like convert_anomaly and convert_position, which handle different data types.

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

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

The description implies use for state vector conversions but lacks explicit guidance on when to use this tool versus alternatives. It does not mention excluded cases or provide when-not-to-use advice. The name and context provide some implicit differentiation.

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

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

The description mentions returning an epoch but lists multiple output formats beyond epoch. Annotations are absent, so the description carries the burden, but it could clarify that the output depends on output_format.

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 two sentences plus a bullet list for args, front-loading the purpose and efficiently detailing options. No wasted words.

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 tool with 0 required params, the description covers the main functionality. However, it doesn't specify whether the time is server-side or client-side, and 'epoch' could be ambiguous without clarification of base (e.g., Unix epoch).

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%, but the description lists valid values for both parameters (output_format and output_time_system), adding meaning beyond the schema's type and title.

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

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

The description clearly states the tool returns the current time, distinguishing it from time conversion tools like convert_epoch. The verb 'Return' and resource 'current time' are specific.

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

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

No explicit when-to-use or when-not-to-use guidance. However, the tool's simplicity makes usage obvious; it's the go-to for getting current times in various formats.

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 description must disclose behavioral traits. It explains the parameters but does not mention error behavior if multiple identifiers are provided, response format, rate limits, or data freshness. The 'limit' parameter implies multiple records but no details on pagination.

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?

Description is concise with a clear, front-loaded purpose statement and well-structured Args list. Each sentence adds value, though the Args section is a bit verbose but necessary given zero schema descriptions.

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

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

Covers purpose, constraints, and parameter meanings. However, without an output schema, it lacks description of the return value structure or behavior (e.g., single vs. multiple records, limit semantics). Siblings are many, but only one alternative is referenced.

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

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

Schema has 0% description coverage, so description fully compensates by providing explicit examples for each parameter (e.g., catnr: NORAD catalog number (e.g. 25544 for ISS), group: Satellite group name (e.g. 'stations', 'active')). Also clarifies that exactly one identifier is required.

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

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

Description clearly states the tool looks up GP ephemeris records from CelesTrak, specifying the resource and source. It also emphasizes that exactly one identifier should be used, distinguishing it from listing 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?

Explicitly states to provide exactly one identifier and recommends using list_celestrak_options() to see available groups. However, it does not explicitly differentiate from other query tools among the siblings (e.g., get_celestrak_satcat).

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 must convey behavioral traits. It only states the lookup action and parameter filtering. It does not disclose output format, data freshness, rate limits, error behavior, or side effects. The requirement for at least one filter is a positive, but overall it lacks transparency.

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 concise with a brief summary, a constraint line, and a parameter list. It uses a structured format (docstring) without extraneous content. Minor improvement could be front-loading the constraint.

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

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

Given the tool has 5 parameters, no output schema, and many siblings, the description is minimally adequate. It lacks guidance on return format, sorting, pagination, and differentiation from similar tools (e.g., get_gcat_satcat). More context about what records include would improve 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%, but the description lists all 5 parameters with clear explanations (e.g., 'Filter to active objects only'), adding substantial meaning beyond the plain schema types and names.

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 'Look up satellite catalog (SATCAT) records from CelesTrak,' specifying the verb, resource, and source. Among siblings like get_gcat_satcat and get_spacetrack_satcat, this distinguishes by source and catalog type.

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 provides a key constraint: 'At least one filter parameter must be provided.' However, it does not advise when to use this tool over alternatives like get_celestrak_gp or get_spacetrack_satcat, nor does it mention prerequisites or context.

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

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

No annotations provided. Description does not disclose any behavioral traits such as data freshness, rate limits, pagination, or error handling, leaving agents unaware of important operational characteristics.

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?

Extremely concise: one-line summary, one-line context, then Args section. No redundant information, front-loaded, easy to parse.

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?

Adequate for a simple lookup tool: explains purpose and parameters. However, lacks description of return format or error conditions; with no output schema, more detail would improve 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?

Description adds meaningful details beyond schema: source is case-insensitive with examples, limit is max records. With 0% schema coverage, this compensation is good, though not exhaustive (e.g., no default limit behavior).

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

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

Description clearly states 'Look up supplemental GP records from CelesTrak by source' and differentiates from standard GP by explaining supplemental data are operator-provided ephemerides, which distinguishes it from sibling tool get_celestrak_gp.

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?

Description implies use for supplemental ephemerides and gives example sources, but does not explicitly state when to use versus other tools like get_celestrak_gp or query_celestrak, nor provides 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?

With no annotations, the description discloses case-insensitivity but does not mention error behavior (e.g., what if constant not found). Adequate but not thorough.

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

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

Two sentences, no wasted words. Efficiently communicates purpose and parameter usage.

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

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

For a simple tool with one required parameter and no output schema, the description covers all necessary context: what it retrieves, the parameter, and examples.

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 explains the single parameter 'name' with examples like 'R_EARTH' or 'gm_earth', adding value over the bare schema.

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

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

The description clearly states 'Get a single brahe constant by name' and adds case-insensitivity, distinguishing it from list_constants which lists all constants.

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 the argument name and examples, but does not explicitly state when to use this tool vs alternatives like list_constants.

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 description must carry behavioral info. It states the tool is for lookup and returns mission-level data, but does not disclose error handling, authentication needs, or rate limits. It mentions default limit but is otherwise sparse.

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 well-structured with a clear header, usage note, content description, and argument list. It is concise but includes necessary details, though some redundancy exists (e.g., repeating 'by identifier' in two places).

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 should explain return values. It describes the record content (program, result, etc.) and references a sibling for field details. However, it does not specify output format, pagination, or error behavior, leaving gaps.

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 description must compensate. It explains jcat and name as alternative search keys with examples, and describes limit. This adds meaning beyond the schema, though it does not specify validation constraints or full format details.

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

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

The description clearly states that the tool looks up GCAT PSATCAT records by identifier, with specific examples (jcat or name). It distinguishes from siblings via name, but does not explicitly differentiate from query_gcat_psatcat, which could be ambiguous.

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 instructs to provide exactly one of jcat or name, and explains the limit parameter. However, it does not provide guidance on when to use this tool over sibling tools like query_gcat_psatcat.

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?

Description implies read-only operation ('Look up'), mentions limit and default return count, but does not disclose auth needs, rate limits, output format, or any side effects. Without annotations, transparency is adequate but not thorough.

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?

Starts with clear purpose and constraints, followed by an args list. Slightly verbose but well-structured. Front-loaded with the essential query rule.

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 could explain the return format or typical record structure. It refers to list_gcat_options() for field meanings but does not set expectations for the tool's output. Adequate but not fully self-contained.

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

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

Schema description coverage is 0%, but the description adds detailed meaning for all parameters: explains jcat, satcat_num, name (with case-insensitive note), and limit default. Fully compensates for lack of schema documentation.

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?

Clearly states it looks up GCAT SATCAT records by identifier with specific arguments (jcat, satcat_num, name). However, it does not distinguish from sibling 'query_gcat_satcat' which might perform broader queries.

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

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

Explicitly states to provide exactly one of three identifiers and suggests using list_gcat_options() for field descriptions. Lacks guidance on when not to use this tool or alternatives.

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 description carries full burden. It discloses case-insensitive provider matching, default behavior (all stations if omitted), and limit parameter. This is adequate for a simple retrieval 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?

The description is concise, uses a structured format (Args), and every sentence is valuable. No superfluous text.

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

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

Given the simplicity (2 optional params, no output schema), the description is complete. It could optionally mention return type, but not required. Overall adequate.

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%, but description fully explains both parameters: provider (case-insensitive, reference to list_groundstation_options) and limit (maximum number). This adds all necessary meaning.

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 it loads groundstation locations, optionally filtered by provider. It distinguishes from siblings like list_groundstation_options (which lists providers) and query_groundstations (different purpose).

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 explicitly advises using list_groundstation_options() to see available providers, guiding when to use that sibling. It does not explicitly state when not to use this tool, but the context is clear.

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

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

Without annotations, the description discloses that the tool returns raw CDM records as dicts and requires environment variables. It does not mention rate limits or error behavior, but the core behavior is adequately conveyed.

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 concise, using a docstring format with clear Args. Every sentence serves a purpose, and the total length is appropriate for the tool's complexity.

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?

The description covers key aspects: data type (dicts), filtering requirement, environment variables, and parameter constraints. Without an output schema, it still provides useful return info. Minor missing details like pagination or error handling, but overall complete enough.

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?

Each parameter is explained: norad_cat_id as NORAD catalog number for SAT_1_ID/SAT_2_ID, epoch_range as ISO datetime range with TCA filtering, limit as max records. This adds meaning beyond the schema's null types, especially given 0% schema description coverage.

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

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

The description clearly states 'Query conjunction data messages (CDM) from SpaceTrack,' providing a specific verb and resource. It distinguishes from sibling tools like get_spacetrack_gp and query_spacetrack by targeting CDM.

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 explicitly requires at least one filter parameter and mentions needed environment variables. However, it does not specify when to use this tool over alternatives like query_spacetrack, though the CDM focus implies differentiation.

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 description carries full burden. Discloses that it returns raw decay records as dicts and requires environment variables. Lacks information on rate limits, pagination, 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?

Compact description with clear structure: purpose, condition, return type, auth requirement, and parameter documentation. Every sentence is informative and 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?

Covers all essential aspects for a 3-parameter tool without output schema: parameter descriptions, mandatory filter condition, auth requirements. Lacks detailed return format, but sufficient for basic usage.

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%, but the description provides detailed semantics for all three parameters: norad_cat_id (NORAD catalog number), epoch_range (ISO format with example), and limit (maximum records). Adds significant value beyond 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?

Description clearly states 'Query decay predictions from SpaceTrack', specifying the verb and resource. It differentiates from sibling tools like get_spacetrack_gp by focusing on decay predictions.

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

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

Explicitly states 'At least one filter parameter must be provided', giving a usage condition. Does not explicitly mention when not to use or list alternatives, but the tool name and context provide differentiation.

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, and the description only mentions basic requirements (env vars, at least one filter). It does not disclose read-only nature, rate limits, pagination, or side effects.

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 clear and structured with parameter list, but somewhat verbose. It could be more concise but is well-organized.

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

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

Without output schema, the description fails to explain what the tool returns (e.g., fields of GP records). It also doesn't specify if it returns one or many records, leaving the agent underinformed.

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

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

With 0% schema description coverage, the description adds meaningful details for each parameter, including examples and format (e.g., epoch_range 'start--end'). It compensates well for the schema's lack of descriptions.

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 'Query GP (General Perturbations) records from SpaceTrack', using a specific verb and resource. It distinguishes from siblings like get_spacetrack_cdm and get_spacetrack_decay by specifying GP records.

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 notes that at least one filter parameter must be provided and requires environment variables, but does not guide when to use this tool over alternatives like query_spacetrack or get_spacetrack_gp_history.

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

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

With no annotations, the description fully discloses behavioral traits: returns all historical element sets, requires environment variables, warns about large result sets, and recommends decimation. It does not cover rate limits or return format details, but the provided context is strong.

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 well-structured: starts with purpose, then usage notes, requirements, and parameter list. It is clear and informative, though slightly lengthy; 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?

Given no output schema, the description does not specify the return format or fields. It mentions 'returns all historical element sets' but lacks details on what each record contains. For a complex tool with many siblings, this is a 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?

All five parameters are explained with descriptions and examples, including format for epoch_range and decimation. Since schema description coverage is 0%, the description fully compensates, adding meaning beyond 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?

The description clearly states the tool queries historical GP records from SpaceTrack and explicitly distinguishes it from get_spacetrack_gp by noting the latter returns only the latest element set. This provides a specific verb+resource with 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 states when to use ('useful for tracking orbital evolution over time'), requires at least one filter parameter, strongly recommends an epoch_range, and suggests decimation for large queries. It lacks explicit when-not-to-use guidance but implies alternatives via sibling context.

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

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

No annotations are provided, so the description must fully convey behavioral traits. It mentions the input requirement and env vars but does not disclose if the operation is read-only, has rate limits, or what the output structure looks like. For a query tool, read-only behavior could be inferred but is 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?

The description is very concise: a one-sentence purpose, a brief requirement note, and a bulleted parameter list. Every sentence adds value, and the structure front-loads the key 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?

Given no output schema and no annotations, the description covers the tool's purpose, essential parameters, and prerequisites. However, it lacks details on output format, pagination, or error conditions. For a query tool with five parameters, it is adequate but not 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%, but the description includes a clear 'Args:' section with explanations for each parameter, adding meaning beyond the bare schema. For example, it notes that 'name' is a substring search and 'object_type' has example values. This is valuable, though it could be more detailed (e.g., allowed values for object_type).

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?

Clearly states it queries SATCAT records from SpaceTrack. Among siblings like get_celestrak_satcat and get_gcat_satcat, the name and description indicate the source is SpaceTrack, distinguishing it. However, the description does not explicitly differentiate it from similar sibling 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?

Provides important context: at least one filter must be provided and environment variables are required. However, it does not specify when not to use this tool or suggest alternatives among the many sibling tools that also query satellite catalogs.

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 must convey behavior. It describes the tool as listing options, implying a read-only, non-destructive operation. This is sufficient for a simple listing tool, though it could explicitly state that no state changes occur.

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, direct sentences. No extraneous information. The key information is front-loaded in the first sentence.

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

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

The description explains the tool's purpose and how to use it with related compute functions. However, it does not describe the output format or structure beyond listing 'options, constraint types, and input formats.' Given no output schema, slightly more detail on the return value would improve completeness, but the current level is acceptable for a discovery tool.

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

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

There are zero parameters, so schema coverage is trivially 100%. The description does not need to add parameter details. It correctly focuses on the tool's purpose rather than nonexistent parameters.

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

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

Description clearly states the tool lists 'available access computation options, constraint types, and input formats.' The verb 'list' and specific resource categories make the purpose precise. It distinguishes from sibling tools like compute_access which perform computations.

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

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

Explicitly says 'Use this to discover how to call compute_access() and compute_access_from_gp().' This provides direct guidance on when to use the tool. It does not list when not to use or alternatives, but the context of discovery is clear.

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. The description indicates a read-only informational tool but does not disclose whether it requires network access, caches results, or has rate limits. For a zero-parameter tool, more behavioral context is needed.

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 two sentences, no wasted words. It is front-loaded with the verb and resource, then enumerates contents efficiently.

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 no parameters and no output schema, the description sufficiently lists what it returns. However, it could mention that results are dynamic or require internet access.

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 has no parameters, so schema coverage is 100%. The baseline for 0 parameters is 4, and the description adds value by explaining what discovery information is returned.

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

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

The description clearly states the verb 'List' and the resource: available CelesTrak lookup methods, groups, supplemental sources, and filter options. It enumerates the specific discovery information returned, distinguishing it from sibling list tools by domain.

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 implies usage to discover CelesTrak options but provides no explicit guidance on when to use this tool versus alternatives like list_access_options or list_constants. No when-not-to-use instructions are given.

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

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

No annotations are present, so the description carries the burden of behavioral disclosure. It states that constants are listed and organized by category, which is clear, but does not mention pagination, performance, or if the list is 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?

The description is a single sentence that is direct and free of extraneous information. Every word contributes to understanding the tool's purpose.

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?

Having an output schema reduces the need for description completeness. The description is adequate for a simple list tool, but misses guidance on how to use the output with related tools like get_constant.

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?

There are no parameters, and schema description coverage is 100%. The description adds no parameter-level value, but this is acceptable as no parameters exist, achieving the baseline for zero-parameter tools.

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

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

The description clearly states the tool lists all available brahe astrodynamics constants organized by category. It uses a specific verb-resource combination and is distinct from sibling list tools like list_access_options and get_constant.

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

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

No usage guidance is provided. The description does not indicate when to use this tool versus alternatives such as get_constant for fetching a specific constant, nor does it mention prerequisites or context.

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

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

No annotations provided. Description discloses return structure but no info on side effects or access requirements. Adequate for a read-only listing 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?

Two efficient sentences, front-loaded with key information. No wasted words.

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, but describes return groups and conversion pairs. Could mention data limits or pagination, but not critical for this tool.

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

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

Zero parameters so schema provides no constraints. Description adds value by explaining output categories and conversion pairs.

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?

Clearly states it lists supported coordinate frames, components, and valid conversions. Distinguishes from siblings like convert_position which perform actual conversions.

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?

Implied usage for discovery before performing conversions. Does not explicitly state when to use or alternatives, but context with sibling tools makes it clear.

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

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

No annotations are provided, so the description carries full burden. It describes the return as 'comprehensive discovery information' and implies a safe read operation. It adds value by explaining the purpose but does not disclose rate limits or side effects beyond stating it is for discovery.

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

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

Two sentences, front-loaded with the main action. Every sentence provides necessary information without redundancy. Efficient and clear.

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, the description explains that it returns 'catalog types, detailed field descriptions with enumeration code meanings, and available filters.' This is sufficient for a discovery tool with no parameters.

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 has zero parameters, so the description does not need to add parameter meaning. Baseline score of 4 is appropriate as it fulfills the requirement without lacking.

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 it 'List available GCAT catalog types, field descriptions, enumeration values, and filter options.' It distinguishes itself from sibling query or computation tools by being a discovery tool, with a specific verb and resource.

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 explicitly advises to 'Call this first to understand what fields and codes mean before querying GCAT data,' providing clear context for when to use it. However, it does not explicitly mention when not to use it or list alternatives among the many sibling tools.

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

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

With no annotations, the description implies a read-only discovery tool. It lists what it returns (providers and field descriptions) but does not explicitly state it is safe or non-destructive.

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

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

Two sentences, front-loaded with the action, and no wasted words. Very concise and well-structured.

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 parameterless discovery tool, the description covers what it returns. It could mention it is a prerequisite for querying groundstations, but overall it is adequate.

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?

There are zero parameters, so the description does not need to add parameter info. The baseline score 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?

The description clearly states it lists groundstation providers and query options, and returns discovery information. It distinguishes from sibling list_* tools by specifying 'groundstation' context, but could be more explicit about what 'query options' entails.

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

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

No guidance on when to use this tool versus siblings like get_groundstations or query_groundstations. It does not indicate that this tool provides metadata for querying groundstations.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns names, descriptions, and parameter requirements, which is adequate for a listing tool but does not mention any behavioral traits like safety 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?

The description is two sentences, front-loaded with the primary action, and every sentence adds value. No wasted words.

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 listing tool with no parameters and no output schema, the description fully covers what the tool does and what it returns. It is self-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?

There are no parameters, so the schema itself provides no information. The description adds value by explaining what the output contains (names, descriptions, parameter requirements), which compensates for the lack of parameter details.

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 it lists all available orbital property computations and anomaly conversions, specifying the returned content (names, descriptions, parameter requirements). This distinguishes it from siblings like list_access_options and compute_orbital_property.

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 implies usage for browsing available computations but lacks explicit guidance on when to use this tool versus siblings or any when-not scenarios. No alternatives are named.

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

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

No annotations are provided, so the description carries the burden. It states the tool lists options but does not disclose any behavioral traits like performance, data sources, or side effects. However, for a simple listing tool with no parameters, the description is adequate.

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 two sentences with no wasted words. The first sentence front-loads the purpose, and the second provides usage guidance.

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 tool with no parameters and no output schema, the description sufficiently explains its purpose and usage context. It covers what the tool does and when to use it.

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?

There are zero parameters in the input schema, so baseline is 4. The description does not need to add parameter details because there are none; it clearly explains what the tool returns.

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 it lists available plotting tools, plot types, and their parameters. It uses specific verb+resource and distinguishes itself from sibling tools that perform actual plotting.

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 explicitly says 'Use this to discover which plotting tool to use and what inputs are required.' This provides clear guidance on when to use the tool, though it does not mention when not to use or alternatives.

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 must convey behavioral traits. It accurately describes a read-only listing operation, but lacks detail on potential side effects or access requirements, which are minimal for a list 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?

The description is two concise sentences, front-loaded with the core action. Every sentence adds value, with no 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?

Given no parameters and no output schema, the description fully specifies the tool's purpose. It sufficiently informs the agent for its intended role as a discovery tool.

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

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

There are zero parameters, and schema coverage is 100% (none missing). The description does not add parameter-level details, but none are needed; baseline score of 4 is appropriate.

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 explicitly states it lists 'propagator types, output frames, force model presets, and their options', clearly identifying the specific verb and resource. It distinguishes from sibling propagation tools by focusing on discovery.

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 advises 'Use this to discover which propagation tool to use', providing clear context for when to invoke. It does not explicitly state when not to use or list alternatives, but the guidance is sufficient.

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 full behavioral burden. It discloses that the tool is safe (no auth needed, static reference data), which implies read-only, non-destructive operation. No contradictions.

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 three sentences that are front-loaded with the verb and resource. Every sentence adds value: what it lists, that it returns discovery info, and that it requires no auth. No fluff.

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

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

Given zero parameters, no output schema, and the tool's simplicity, the description fully covers what an agent needs: what the tool does, what it returns, and its behavior (static, no auth). Complete for its complexity.

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?

There are no parameters, so schema coverage is 100%. Baseline for 0 parameters is 4. The description adds no parameter details, but none are needed.

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

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

The description clearly states the tool lists 'available SpaceTrack tools, request classes, filter fields, and operators' and 'returns discovery information.' This specific verb and resource combination distinguishes it from sibling list_* tools that cover different data sources (Celestrak, GCAT, etc.).

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 provides useful context: 'No authentication required' and 'returns static reference data.' This helps agents decide when to use this tool (for quick, safe exploration). However, it does not explicitly mention alternatives or when not to use it, though sibling names imply differentiation.

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

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

No annotations are provided, so the description carries full burden. It states 'list,' which suggests a read-only operation, but it does not confirm safety, disclose any side effects, or mention any behavioral traits beyond the obvious.

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

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

The description is a single sentence that is front-loaded with the verb and resource. Every word is purposeful, with no extraneous content.

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 parameterless list tool, the description is complete: it states what is listed and the context (epoch conversion). No output schema exists, but the description does not need to explain return values as it is straightforward.

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 has zero parameters and schema coverage is 100%. The description adds no param details, which is acceptable as there are none to explain. Baseline for 0 parameters is 4.

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 uses the specific verb 'list' and clearly identifies the resource: 'all supported time systems for epoch conversion.' This distinguishes it from sibling tools like list_constants or list_coordinate_systems.

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 implies usage when one needs to know available time systems before epoch conversion, but it does not provide explicit guidance on when not to use this tool or mention alternatives.

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 description carries full burden. It states it computes and plots, implying read-only behavior. However, it does not disclose any side effects, permissions, or output format beyond the schema.

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

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

Two concise sentences followed by a bulleted Args list. Every sentence adds value; no redundancy. Front-loaded with the core purpose.

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

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

Covers main purpose and all parameters adequately. With an output schema present, not explaining return values is acceptable. Could briefly mention output type (e.g., plot object) but fine for context.

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

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

Schema description coverage is 0%, but the description's Args section adds meaningful details for all 8 parameters, including expected dict structures, string formats, and default values. Compensates well for missing schema descriptions.

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?

Describes a specific action (plot) on a specific resource (access geometry). Differentiates from sibling 'plot_access_geometry_from_gp' by not mentioning GP records, and from 'compute_access' by adding plotting.

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

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

Implies use when plotting is needed, but lacks explicit guidance on when to choose this over compute_access or plot_access_geometry_from_gp. No when-not-to-use or alternative mentions.

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 must carry the burden. It describes the tool as a plotting wrapper that delegates, implying read-only behavior. However, it does not specify if the plot is displayed, saved, or requires network, nor does it mention side effects like state changes. Adequate but lacking explicit details.

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

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

The description is concise with a clear summary line followed by a structured Args section. Every sentence adds value, and the format is front-loaded and easy to scan. No wasted words.

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

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

Given the tool's complexity (9 parameters, nested objects) and that an output schema exists, the description covers the purpose, all parameters with defaults, and the wrapper functionality. It lacks details on constraints structure and output behavior, but overall it is fairly complete for a plotting tool.

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

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

With 0% schema description coverage, the description compensates by explaining each parameter's purpose and format (e.g., 'location: Ground location dict with lon, lat, optional altitude_m/name'). However, for parameters like 'constraints', it is vague ('List of constraint spec dicts') without specifying the expected keys, leaving some ambiguity.

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 'Plot access geometry from a GP record' and explains it is a convenience wrapper that delegates to plot_access_geometry(). This distinguishes it from siblings like compute_access_from_gp (compute vs plot) and plot_access_geometry (takes satellite spec instead of GP record).

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 indicates this tool is for plotting when you have a GP record from celestrak/spacetrack tools, serving as a convenience wrapper. While it implies when to use, it does not explicitly state when not to use or list alternatives, but the context and sibling names provide enough 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 adequately describes the propagation and conversion process, and notes the satellite spec must include a 'source' key. However, it does not disclose assumptions, error conditions, or how the plot is handled (e.g., displayed or returned).

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 concise, with a clear introductory sentence followed by a structured parameter list. Every sentence adds value, and the format is front-loaded with the primary purpose.

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 output schema exists and parameter count, the description covers the main purpose and parameter semantics. It is missing details on how the plot is returned or displayed, but the output schema may fill that gap. Overall, it is complete for most usage scenarios.

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 compensates with clear parameter explanations. It defines satellite (referencing compute_access format and required source key), provides defaults for step_seconds, and explains start/end epochs. This adds significant meaning beyond the bare schema.

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

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

The description clearly states the tool plots satellite altitude versus time, specifying the WGS84 ellipsoid. It is specific and distinguishes from siblings by referencing orbit propagation and conversion, but does not explicitly differentiate from other plot tools.

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

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

The description mentions use cases like visualizing orbital decay and maneuver effects, but does not provide explicit when-to-use vs alternatives or when not to use. The usage context is implied but not fully directive.

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. It discloses that it creates a satellite spec from a GP record and delegates to plot_altitude(). It does not detail error handling or side effects, but the core behavior is transparent. A mention of plot generation or potential failures would enhance transparency.

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 succinct: a one-sentence purpose, a brief note on being a wrapper, then a clean Args list. No unnecessary words; every sentence adds value. It is front-loaded with the core function.

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

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

Given the tool's complexity (6 parameters, nested object, output schema exists), the description covers the essentials. It explains parameters and the delegation pattern. The output is not described, but the output schema presumably covers return values. Could mention that the function generates a plot, but overall sufficient for an agent.

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 identifies all 6 parameters and adds meaning: gp_record as a dict from celestrak/spacetrack tools, start_epoch as ISO string, end_epoch as ISO string, propagator_type with two explicit choices, step_seconds with default 60, and title as optional. This fully bridges the gap.

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

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

The description clearly states the tool's purpose: 'Plot satellite altitude versus time from a GP record.' It uses a specific verb (Plot) and resource (satellite altitude vs time), and distinguishes it from sibling 'plot_altitude' by noting it is a convenience wrapper for GP records.

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 indicates it's a wrapper that delegates to plot_altitude(), implying use when you have a GP record dict. While it doesn't explicitly state when not to use or list alternatives, the context of being a wrapper provides clear guidance. It would be stronger with an explicit reference to plot_altitude as an alternative for satellite specs.

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

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

No annotations are provided, so the description carries the burden. It discloses that each GP record becomes a point on the diagram, but does not mention side effects, permissions, computational cost, or the output type. The existence of an output schema mitigates this slightly, but the description could be more transparent about what happens when the tool is invoked.

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 concise, front-loaded with the core purpose, and includes only necessary information. Each sentence adds value without 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?

Given the tool has 4 parameters and an output schema, the description adequately covers the input requirements and usage context. It does not detail the output format, but the presence of an output schema likely fulfills that role. It could mention prerequisites or error conditions, but is largely complete for its complexity.

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

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

With 0% schema description coverage, the description adds meaning beyond the schema by explaining the 'gp_records' parameter as 'List of GP record dicts from celestrak/spacetrack tools' and specifying units for altitude and period. It also documents the optional title parameter. This provides meaningful guidance for parameter selection.

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

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

The description clearly states that the tool plots a Gabbard diagram (apogee/perigee altitude vs orbital period) and explains its utility for visualizing debris clouds or constellation distributions. It distinguishes itself from sibling plotting tools by specifying the exact type of diagram.

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 provides a clear use case ('useful for visualizing debris clouds or constellation distributions') but does not explicitly state when to avoid using this tool or suggest alternatives. The context is sufficient for an informed agent, but lacks exclusionary 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 burden. It explains that it visualizes changes over time, accepts two data sources, and allows selecting specific elements. However, it does not mention potential issues like network dependency, rate limits, or error handling for SpaceTrack fetches.

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 well-structured with a clear summary first, then general explanation, and a detailed Args section. It is not overly verbose given the need to explain parameters, though the Args list could be slightly condensed.

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?

The description is largely complete, covering both input modes, element selection, and plot title. However, it does not mention the need for SpaceTrack credentials or network access when using norad_cat_id, and assumes the user knows how to obtain gp_records. The output schema covers return values, so that is not a 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?

The description compensates for 0% schema coverage by providing detailed parameter documentation. It explains each parameter's purpose, valid values for `elements`, and the source options for data. This adds significant meaning beyond the schema's type-only 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 clearly states the tool plots orbital element trends from GP history records. It specifies the resource (GP history) and action (plotting trends). While it distinguishes from siblings like `plot_orbit_elements` by focusing on historical changes, it does not explicitly differentiate from similar tools like `plot_orbit_elements_from_gp`.

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 provides guidance on two input modes: pre-fetched gp_records or auto-fetch via norad_cat_id. However, it does not specify when to use this tool over other plotting tools (e.g., `plot_altitude`, `plot_orbit_elements`) or mention any prerequisites like SpaceTrack authentication.

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. Description lacks details on side effects, permissions, or whether plot is displayed vs returned. Does not mention return value.

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

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

Concise docstring format with clear first sentence. Args block is structured but could be trimmed slightly.

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?

Output schema exists but not described. Missing details on return type, error cases, and prerequisites for satellite spec.

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%, but description includes an Args block that explains each parameter's purpose and format, adding value beyond the schema titles.

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

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

Clearly states 'Plot satellite ground track on a world map' and explains propagation. However, does not explicitly differentiate from sibling 'plot_ground_track_from_gp'.

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

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

No guidance on when to use this tool vs alternatives. Does not mention prerequisites or exclusions.

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

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

No annotations are provided, so the description must fully disclose behavior. It states the tool plots but does not mention side effects (e.g., whether it displays or saves the plot), authorization needs, or other traits. This leaves important behavioral aspects unspecified.

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 succinct and well-structured: a one-line summary, a brief explanation of the wrapper, then a clear Args list. Every sentence serves a purpose, with no redundancy or fluff.

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

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

Given the tool's complexity (8 parameters, 3 required, nested objects) and the presence of an output schema, the description explains all parameters adequately. However, it omits details about prerequisites (e.g., network for GP records) or error handling, which would enhance 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%, but the description includes an Args section that thoroughly explains each parameter with types, defaults, and context (e.g., 'GP record dict from celestrak/spacetrack tools'). This adds critical meaning beyond the schema, fully compensating for the lack of schema descriptions.

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 'Plot satellite ground track from a GP record' and identifies it as a convenience wrapper that delegates to plot_ground_track(). This distinguishes it from siblings like 'plot_ground_track' which may require a satellite spec directly.

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

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

The description implies usage when a GP record is available (e.g., from celestrak/spacetrack tools) by mentioning it's a wrapper for those inputs. However, it does not explicitly state when not to use it or compare with alternatives like 'plot_ground_track', so it lacks 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 must fully disclose behavioral traits. It states that it uses 'brahe's plot_keplerian_trajectory' and shows element evolution, but it does not mention whether the plot is returned as an image, saved to a file, or displayed. It also omits side effects, permissions, or rate limits. For a plotting tool, the output format is a critical behavioral 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?

The description is concise and well-structured. It front-loads the purpose in the first line, then uses an 'Args:' block to clearly document parameters. Every sentence adds value 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?

While an output schema exists (not shown), the description does not explain what the tool returns—whether it outputs a plot image, a file path, or an in-memory object. For a plotting tool, this is a significant gap. The description should clarify the return type and how the plot is presented (e.g., base64 PNG).

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 description adds meaning beyond the input schema by explaining that 'satellite' follows the same format as in 'compute_access', that epochs are ISO strings, and that 'step_seconds' defaults to 60. This helps the agent understand parameter types and defaults. However, it does not fully describe the 'satellite' object structure, relying on cross-reference.

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 'Plot Keplerian orbital element evolution over a propagation arc' and specifies it shows changes of the 6 classical elements over time. This provides a specific verb+resource. However, it does not explicitly differentiate from the sibling tool 'plot_orbit_elements_from_gp', which could create confusion about which to use.

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

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

No guidance is provided on when to use this tool versus alternatives like 'plot_altitude' or 'plot_orbit_elements_from_gp'. The description lacks explicit when/when-not conditions or selection criteria, forcing the agent to infer context from the tool name alone.

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 description should disclose behavioral traits. It mentions 'plot' but doesn't specify whether it saves a file, displays, or returns the plot. Missing side-effect information.

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?

First sentence is clear, but the Args block adds verbosity. Could be more concise, e.g., integrating parameter explanations into a single paragraph.

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, description should explain plot output (e.g., axes, title). Also missing information on return value. Tool complexity and multiple siblings demand more 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?

With 0% schema coverage, description adds meaning by explaining 'gp_record' as from celestrak/spacetrack, epochs as ISO strings, and defaults for propagator_type and step_seconds. Could still clarify which orbital elements are plotted.

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

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

Description clearly states it plots Keplerian orbital element evolution from a GP record. However, it fails to differentiate from sibling 'plot_orbital_elements' which may have similar functionality.

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

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

No explicit guidance on when to use this tool versus alternatives like 'plot_orbit_elements' or 'plot_gp_history_elements'. The context of usage is not addressed.

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. It explains the internal behavior: for SGP4 it uses OMM elements directly, for others it converts to ECI state. It also lists all parameters with brief descriptions, which adds transparency. However, it does not disclose return format or any side effects, leaving some behavioral gaps.

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 a clear purpose statement and a paragraph explaining the advantage, followed by parameter listings. It is somewhat lengthy due to many parameters, but each sentence adds value. Could be slightly more concise by merging redundant statements.

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

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

Given the complexity (16 parameters, no output schema), the description covers the main purpose and parameter details but lacks any description of return values, which is critical for an agent to use the output. No examples or additional context about propagation results. This gap reduces 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. It does so by listing all 16 parameters with purpose and value hints (e.g., 'target_epoch: Single target epoch (ISO string)'). While the descriptions are terse, they add meaning beyond the schema's type-only definitions, helping the agent understand usage. Missing details like valid ranges or defaults beyond what's in schema.

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

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

The description clearly states the tool's purpose: to propagate from a GP record dict obtained from Celestrak/Spacetrack queries. It specifies the verb 'propagate' and the resource 'GP record', and distinguishes itself from siblings by explaining the advantage of using OMM elements directly to avoid TLE precision loss, which is unique among propagation tools.

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

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

The description explicitly says to use this tool when you have a GP record from get_celestrak_gp or query_spacetrack_gp, providing clear input context. It implies when to use it but lacks explicit when-not-to-use statements or comparisons with sibling propagation tools (propagate_sgp4, propagate_keplerian, propagate_numerical).

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 mentions analytical dynamics and the input/output units but does not disclose limitations, error conditions, or non-destructive nature. Lacks explicit safety or performance context.

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 well-structured with a one-sentence summary, initialization guidance, and a parameter list. It is front-loaded but slightly lengthy; could be more concise without losing clarity.

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

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

Given the complexity (10 parameters, no output schema), the description covers input options, output frames, and angle formats. It does not explain the return value shape, but otherwise provides sufficient context for correct use.

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

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

Schema description coverage is 0%, but the description provides detailed parameter explanations, including units (meters, m/s) and angle formats. It adds meaning beyond the bare schema, compensating for the lack of schema descriptions.

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 specifies 'Propagate a satellite orbit using two-body (Keplerian) analytical dynamics,' clearly stating the verb (propagate), resource (satellite orbit), and method (two-body Keplerian). This distinguishes it from sibling tools like propagate_numerical and propagate_sgp4.

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 explains initialization options (ECI state or Keplerian elements) and output choices (single epoch or range). It does not explicitly state when to use this tool versus alternatives, but the method name and sibling tools imply it's for unperturbed two-body propagation.

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 must fully disclose behavior. It outlines force models and parameters but omits critical aspects such as performance characteristics, error behavior, or output format (e.g., the structure of the propagated state).

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 and force model overview, followed by a structured Args list. However, the parameter documentation is lengthy and could be more concise without losing clarity.

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 16 parameters, no output schema, and no annotations, the description covers parameter semantics and references a related tool (list_propagation_options), but lacks explanation of output format, error scenarios, and performance considerations.

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

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

With 0% schema description coverage, the description compensates by providing an Args section that explains each parameter's purpose and format (e.g., 'epoch: Initial epoch (ISO string)'), though some descriptions are minimal (e.g., 'Override solar radiation pressure toggle').

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 specifies 'Propagate a satellite orbit using high-fidelity numerical integration' and lists configurable force models, clearly distinguishing it from sibling tools like propagate_keplerian and propagate_sgp4 by emphasizing numerical integration with customizable models.

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 mentions 'Use list_propagation_options() to see available force model presets and overrides,' implying the context for force model selection, but lacks explicit guidance on when to use this tool versus alternatives or exclusion criteria.

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 must disclose behavior. It states the model and parameter usage but does not mention that the tool is read-only/non-destructive, what the return format is, or any error conditions. Propagation is inherently non-destructive, but the lack of explicit safety confirmation is a 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?

The description is relatively concise, using a short paragraph followed by a bullet-like list for arguments. It front-loads the purpose. However, it could be more structured with separate sections for usage and arguments.

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 8 parameters, no output schema, and no annotations, the description covers parameter semantics well but lacks information about output format, error handling, and whether it modifies state. The model mention helps differentiate from siblings, but return value 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 adds meaning beyond the schema. It explains each parameter, provides example ISO strings for epochs, lists output frame options, and notes defaults like step_seconds=60 and angle_format='degrees'.

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

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

The description clearly states the tool propagates a satellite orbit using SGP4/SDP4 from TLE data, specifying the verb, resource, and model. It also differentiates from siblings like propagate_keplerian and propagate_numerical by naming the model.

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 explains the two usage modes (single epoch or range) and lists parameters with types. However, it does not explicitly state when to use this tool versus alternatives like propagate_from_gp_record or propagate_keplerian, though the model mention implicitly guides.

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

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

No annotations are provided, so the description carries full burden. It explains the tool's behavior (builds and executes queries with client-side filtering and ordering) but does not disclose return format, error handling, rate limits, or whether it is read-only. The parameter list is detailed but behavioral context is lacking.

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 well-structured as a docstring with a clear summary line followed by a parameter list. However, it is somewhat lengthy (15+ lines) and could be more concise while retaining clarity. The front-loaded summary is effective.

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

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

Given the tool has 13 parameters, no output schema, and no annotations, the description covers parameter semantics and purpose well. It does not mention output format or error handling, but the complexity of the tool is high and the description adequately addresses the main aspects for an advanced query tool.

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

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

Schema description coverage is 0%, so the description must fully compensate. It provides detailed explanations for all 13 parameters, including valid values for query_type, usage notes for filters (with example), and sorting parameters. This adds significant meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: to build and execute an advanced CelesTrak query with filtering and sorting. It explicitly distinguishes itself from simpler sibling tools by mentioning features they don't expose (client-side filtering and ordering).

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 contrasts this tool with simpler alternatives by noting it provides full access to the query builder including filtering and ordering that simpler tools lack. This implies when to use it (for advanced queries) but does not explicitly state when not to use it or name specific sibling tools.

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

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

Annotations are absent, so the description bears full burden. It describes filter chaining and requirements but does not disclose return format, error behavior, or performance implications. It mentions the default limit but lacks a complete behavioral profile.

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 concise, with a clear opening sentence and structured Args. It is front-loaded with purpose and important constraints. Minor redundancy in 'advanced chainable filters' and 'Filters are applied sequentially,' but overall efficient.

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?

The description lacks information about return values (no output schema) and does not clarify how results differ from sibling `get_gcat_psatcat`. Given the number of parameters and complexity, additional context on output format or usage with other tools would improve 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?

The input schema has 0% description coverage, but the description's Args section explains each parameter (name, category, object_class, etc.) with examples and context, adding substantial meaning beyond the schema's titles and types.

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 'Query GCAT PSATCAT with advanced chainable filters,' using a specific verb and resource. It distinguishes from sibling tools like `get_gcat_psatcat` (which likely fetches without filters) and `query_gcat_satcat` (different catalog).

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 explicitly requires at least one filter parameter ('At least one filter parameter must be provided') and explains sequential application. It suggests using `list_gcat_options()` for full code details, providing context for usage. It does not explicitly state when not to use, but the guidance is clear.

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 must carry full burden. It mentions sequential filtering and the requirement of at least one filter but omits details on rate limits, pagination, and response format, which are relevant for a query 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?

The description is structured with an Args section and key usage notes up front. It is clear but somewhat lengthy due to the parameter list; no extra sentences.

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

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

While parameters are well covered, the description lacks details on return format, pagination, and typical use cases. For a tool with 12 parameters and no output schema, more contextual information would be beneficial.

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 compensates by explaining each parameter's meaning (e.g., case-insensitive substring search, object type prefixes). However, the limit parameter description is minimal, and some codes are left to another tool.

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

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

The description clearly states the tool queries GCAT SATCAT with chainable filters, distinguishing it from sibling tools like get_gcat_satcat by specifying filtering capability.

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 explicitly requires at least one filter parameter and references list_gcat_options() for valid enumeration codes, guiding correct usage. However, it lacks explicit exclusions for when not to use this tool.

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 description must cover behavioral traits. It explains filter combination and requirement but does not disclose if the operation is read-only, pagination, or result limit default 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?

Well-structured with a clear header and bulleted Args section. Slightly verbose but every sentence adds value; no redundant 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?

Input is well-described, but no output schema exists and the description does not mention the return format or any result structure, leaving uncertainty about what the agent receives.

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%, but the description provides meaningful descriptions for all 8 parameters including case-insensitivity and units, fully compensating for the lack of schema descriptions.

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

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

The description clearly states the tool queries groundstations with geographic and attribute filters. It distinguishes from siblings like 'get_groundstations' by emphasizing filter and AND logic.

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

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

Explicitly states that at least one filter parameter must be provided and all filters use AND logic. However, it does not explicitly exclude cases where no filtering is needed, implying alternative tools may exist.

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 description carries the burden. It discloses authentication requirements via environment variables but does not mention rate limits, error handling, or side effects. Essential behavioral traits are partially 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 description is relatively concise with a clear first-line purpose and structured Args. A minor point is that the env var requirement could be integrated more succinctly, but overall efficient.

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?

The description thoroughly covers parameters and constraints but lacks any mention of the output format or return value, which is critical for an agent to process results. With no output schema, this gap reduces 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?

The Args section explains each parameter in detail, specifying request_class values (e.g., gp, satcat), filters structure, sorting options, and pagination. This adds significant meaning beyond the schema, which lacks descriptions and enums.

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 'Build and execute an advanced SpaceTrack query with full control' and explains that it provides direct access to the query builder with arbitrary filters, sorting, and pagination, distinguishing it from simpler retrieval tools like get_spacetrack_gp.

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 mentions required environment variables but does not explicitly guide on when to use this tool versus siblings. It implies advanced control but lacks explicit when-to-use/when-not-to-use instructions.

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