IO Aerospace MCP Server

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

Annotations declare readOnlyHint=true and idempotentHint=true, confirming this is a safe mathematical operation. The description adds no behavioral context beyond what annotations provide (e.g., conversion formula, range limitations), but does not contradict them.

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?

While the three-word description is brief, it represents under-specification rather than efficient value delivery. For a trivial conversion tool the length is appropriate, but the content is tautological and fails to front-load useful context.

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 simple single-parameter conversion and complete schema coverage, the description meets minimum viability despite being empty. It omits useful context like the conversion factor or return value specification that would help confirm correct 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?

With 100% schema description coverage and only one parameter, the input schema adequately documents the arcseconds parameter. The description adds no parameter-specific guidance (e.g., valid ranges, float precision), warranting the baseline score.

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?

Tautological: description restates name/title.

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 provided on when to use this tool versus its inverse sibling degrees_to_arcseconds, or versus alternative angular conversion tools like arcseconds_to_radians available in the same toolkit.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds no behavioral context beyond what structured fields provide, such as precision details, valid input ranges, or error behaviors.

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 extremely brief (four words) and front-loaded, but the single sentence fails to earn its place as it merely duplicates the title without adding value. It is concise but under-specified.

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 simple single-parameter conversion function with complete schema annotations and readOnly/idempotent hints, the description is minimally adequate but leaves gaps regarding output format and precision expectations.

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

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

Schema description coverage is 100% with the arcseconds parameter fully documented as 'Arcseconds to convert'. The description adds no additional semantic detail about the parameter, warranting the baseline score for complete schema coverage.

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

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

Tautological: description restates name/title.

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 (e.g., when to convert to radians vs degrees, or how this differs from the inverse operation radians_to_arcseconds).

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds no additional behavioral context (e.g., precision, handling of negative inputs, or output format), but for a simple mathematical conversion with clear annotations, this is minimally 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 extremely concise at five words, with no filler or redundant content. Every word earns its place by directly stating the operation performed.

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 of this single-parameter conversion tool with full schema coverage and clear annotations, the description is sufficient for an agent to invoke it correctly. The lack of output schema is mitigated by the clear 'to meters' implication in the title and description.

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 100% schema description coverage, the schema already fully documents the single 'astronomicalUnits' parameter. The description reinforces the input/output unit semantics but does not add syntax details or constraints beyond what the schema provides, meeting the baseline expectation.

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?

Tautological: description restates name/title.

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 no guidance on when to use this tool versus alternatives. It fails to mention the inverse operation (meters_to_astronomical_units) or when this conversion is preferred over other astronomical distance units like light-years or parsecs.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety/idempotency. The description adds no behavioral context about what the conversion entails (mathematical offset calculation between time scales, precision limits, leap second handling, etc.).

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?

Extreme brevity (6 words) results in under-specification rather than efficient communication. The single sentence fails to earn its place by not conveying domain-specific information necessary for correct invocation.

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 of astronomical time scales (TDB vs TDT vs TAI) and nested parameter structure, the description inadequately prepares the agent. It omits domain context that would explain the purpose of these specific conversions.

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 100%, documenting all parameters including the nested dateTime object and enum values (TDB, UTC, etc.). The description references 'target kind' mapping to the kindTarget parameter but adds no semantic depth beyond the schema definitions, warranting baseline 3.

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 restates the tool name with minimal addition ('Converts a date time to a target kind'). While it nominally indicates the action and resources, it fails to define the critical domain term 'kind' (time scale/standard) or distinguish from the many sibling conversion tools (angle, distance, orbital element converters).

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 no guidance on when to use this versus other tools, which input 'kind' to select from the complex astronomical time standards (TDB, TDT, TAI, etc.), or prerequisites for the conversion.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, confirming this is a pure calculation. The description adds no behavioral context beyond this, such as the conversion formula (division by 15), precision limits, or that it operates on a single scalar 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?

Extremely brief (4 words) and front-loaded with the verb. While not verbose, it wastes the opportunity to provide domain context; conciseness here manifests as under-specification rather than efficient information density.

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 astronomical domain evident from siblings (equinoctial elements, state vectors, arcseconds), the omission of any astronomical context (e.g., 'for right ascension conversion') is a significant gap. No output schema exists, yet return value expectations (time hours) are not clarified.

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 100% with the 'degrees' parameter fully documented. The description mentions 'degrees' but adds no semantic value regarding valid ranges (0-360) or that this represents angular measure. With high schema coverage, baseline 3 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?

Tautological: description restates name/title.

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 no guidance on when to use this tool versus its inverse (convert_hours_to_degrees) or other angular conversion siblings. No prerequisites, domain context (astronomical calculations), or filtering criteria are mentioned.

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 indicate the operation is read-only and idempotent, but the description adds zero behavioral context beyond this. It fails to disclose what equinoctial elements represent (e.g., singularity-free orbital elements), what the state vector output format is, or any mathematical constraints/guards for the conversion.

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 single-sentence description is concise but excessively minimal. While it avoids bloat, it wastes the opportunity to provide essential domain context upfront, resulting in a structure that is technically efficient but pragmatically deficient.

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 of the nested input object (9+ fields including reference frames and centers of motion) and the specialized astrodynamics domain, the description is inadequate. It provides no conceptual framework for equinoctial elements despite the presence of an output schema that would benefit from explanatory linkage.

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?

While the schema contains many undescribed fields (f, g, h, k, p, l0, frame, centerOfMotion), the context signal indicates 100% schema description coverage, establishing a baseline of 3. The description adds no additional semantic meaning for these domain-specific 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?

The description 'Converts equinoctial elements to state vector' is a tautology that restates the tool name/title without adding specificity. It does not distinguish from sibling converters like 'convert_keplerian_elements_to_state_vector' or clarify what distinguishes equinoctial elements from other orbital parameterizations.

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 no guidance on when to use this tool versus alternatives (e.g., Keplerian conversions) or when to prefer the inverse conversion sibling 'convert_state_vector_to_equinoctial_elements'. No prerequisites or contextual triggers are specified.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds no behavioral context beyond these annotations—no validation rules, precision limits, or handling of negative values. It merely repeats the conversion direction already evident in the name.

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

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

While brief and front-loaded, the three-word description constitutes underspecification rather than efficient conciseness. It wastes no words but also provides zero informational value beyond the tool name itself.

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

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

For a single-parameter conversion tool with full schema coverage, the description is minimally functional but incomplete. Given the astronomical context evident from siblings (equinoctial elements, state vectors, arcseconds), the description should clarify this is for celestial coordinate conversion, which would help the LLM distinguish it from time-based operations.

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 100% schema description coverage (the 'hours' parameter is documented as 'Hours to convert'), the baseline is 3. The description does not augment the schema with semantic details (e.g., clarifying these are hour angles, not clock time, or valid ranges 0-24).

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?

Tautological: description restates name/title.

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 provided on when to use this versus its inverse sibling convert_degrees_to_hours or other angular conversion tools. The description does not indicate typical astronomical use cases (converting RA from hours to degrees) or valid input ranges.

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?

While annotations correctly indicate the operation is read-only and idempotent, the description adds no behavioral context beyond this, such as output units (meters vs kilometers, m/s vs km/s), reference frame transformations, two-body orbit assumptions, or the structure of the returned state vector (position/velocity components).

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 six-word sentence merely restates the tool title and name ('Convert Keplerian elements to state vector' vs 'convert_keplerian_elements_to_state_vector'), constituting under-specification rather than efficient information delivery; it fails to earn its place by adding no new 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 complex nested schema with extensive astronomical enums (frames, celestial bodies) and existence of an output schema, the description is inadequate for this specialized astrodynamics domain. It omits critical context such as expected units, coordinate system conventions, and whether the state vector includes velocity components.

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 100% schema coverage per context signals, the detailed input schema adequately documents nested parameters including 'keplerianElements', 'epoch', and orbital parameters. The description provides baseline value by confirming the conversion subject but adds no semantic clarification beyond what the schema already provides.

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

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

The description states 'Converts keplerian elements to state vector' which provides a specific verb and resource type, matching the tool's function. However, it fails to distinguish directionality from the sibling tool `convert_state_vector_to_keplerian_elements` (the inverse operation) or clarify that this performs orbital mechanics calculations.

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 its inverse `convert_state_vector_to_keplerian_elements` or related conversion tools like `convert_equinoctial_elements_to_state_vector`. The agent must infer from parameter names alone which direction the conversion flows.

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?

While annotations declare readOnlyHint=true and idempotentHint=true, the description adds no behavioral context about the conversion process, precision, or what determines the output frame. It does not explain whether this is a simple coordinate rotation or requires ephemeris data.

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 single sentence is brief but fails to earn its place—it provides no information beyond the tool name itself. This is under-specification rather than effective conciseness.

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 domain complexity (astrodynamics with 100+ frame enums) and presence of an output schema, the description should clarify the specific coordinate representation (spherical? cartesian?) and reference system. It does not.

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 100% description coverage with detailed documentation of the nested stateVector structure (epoch, frame, position, velocity, centerOfMotion). With schema coverage this high, the baseline is 3; the description neither adds nor subtracts value regarding 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?

The description 'Converts a state vector to Equatorial coordinates' is a tautology that restates the tool name. It fails to distinguish from siblings like convert_state_vector_to_keplerian_elements or convert_state_vector_to_equinoctial_elements, and does not specify what 'Equatorial coordinates' means in this context (e.g., right ascension/declination).

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 provided on when to use this tool versus the multiple sibling conversion tools (keplerian, equinoctial, frame conversion). No mention of prerequisites or valid input ranges.

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 declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds no behavioral context beyond the annotations (e.g., numerical stability, units of output elements, handling of degenerate cases), but does not contradict the annotations.

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

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

The single sentence is efficient in structure but insufficient in content. While it wastes no words, it fails to earn its place by providing material value beyond the tool name, landing at mediocre rather than excellent conciseness.

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 specialized astrodynamics conversion tool with complex nested inputs and available output schema, the description is inadequate. It lacks domain-specific context (e.g., what Equinoctial elements represent, reference to the inverse operation) needed to help an agent select this tool correctly from numerous conversion siblings.

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?

Input schema has 100% description coverage with detailed descriptions for epoch, frame, position, velocity, and centerOfMotion. The description adds no parameter-specific guidance (e.g., valid frame combinations, required units for position/velocity), warranting the baseline score of 3 for high schema coverage.

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

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

The description 'Converts a state vector to Equinoctial elements' is a tautology that merely restates the tool's name and title. It does not explain what Equinoctial elements are, nor does it distinguish this tool from siblings like 'convert_state_vector_to_keplerian_elements' or the inverse 'convert_equinoctial_elements_to_state_vector'.

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 no guidance on when to use Equinoctial elements versus Keplerian elements or other orbital parameter sets. It fails to mention the existence of inverse conversion tools or typical use cases in astrodynamics (e.g., avoiding singularities for equatorial or circular orbits).

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?

While annotations correctly indicate readOnlyHint=true and idempotentHint=true, the description adds no behavioral context beyond what annotations provide. It does not mention that this is a deterministic mathematical calculation, potential precision limitations, or that invalid orbital states (e.g., parabolic/hyperbolic trajectories) might produce errors.

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 six-word sentence, achieving brevity. However, conciseness requires that every sentence earns its place; this sentence merely restates the tool name without adding value equivalent to its structural position as the primary description.

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 complex orbital mechanics tool with nested object parameters and a rich domain-specific vocabulary (multiple reference frames, barycenters, time standards), the description is inadequate. It fails to explain what constitutes Keplerian elements (semi-major axis, eccentricity, inclination, etc.), the physical assumptions (two-body problem), or prerequisites for the input state vector.

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 100% description coverage with detailed descriptions for epoch, frame, position, velocity, and centerOfMotion. Since the schema comprehensively documents all parameters, the baseline score of 3 is appropriate. The description itself adds no parameter-specific guidance beyond implicitly referencing the stateVector parameter.

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 'Converts a state vector to Keplerian elements' is a tautology that restates the tool name/title with only minor grammatical changes. While it technically describes the operation, it fails to distinguish this tool from its inverse sibling (convert_keplerian_elements_to_state_vector) or explain what distinguishes a state vector from Keplerian elements.

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 no guidance on when to use this tool versus alternatives. Given the existence of the inverse conversion tool (convert_keplerian_elements_to_state_vector) and frame transformation tools in the sibling list, the description should explicitly state this is for converting Cartesian position/velocity to orbital elements, but it does not.

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?

While annotations correctly declare readOnlyHint=true and idempotentHint=true, the description adds no behavioral context whatsoever—no mention of transformation accuracy, frame compatibility constraints, or whether the operation is purely mathematical vs. lookup-based.

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?

Although brief (4 words), the description suffers from under-specification rather than effective conciseness. For a tool with 200+ enum values and complex nested objects, this length is inappropriately terse and fails to front-load critical domain context.

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?

Despite the presence of an output schema and complete input schema documentation, the description fails to address the domain complexity (astronomical reference frames, state vector components, center of motion requirements) necessary for an agent to use this specialized tool effectively.

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 100% schema description coverage, the baseline is 3. The description mentions 'state vector' and 'frame' but adds no clarifying details (e.g., that the state vector must include epoch, position, and velocity) beyond what the schema already documents extensively.

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 'Converts state vector to the given frame' is a direct tautology of the tool name, restating it without adding specificity, scope, or distinguishing characteristics from the numerous sibling conversion 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 provides no guidance on when to use this tool versus alternatives like 'convert_state_vector_to_equatorial_coordinates' or 'convert_state_vector_to_keplerian_elements', nor does it mention prerequisites or expected input formats beyond the raw schema.

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 'UTC' mention adds timezone context beyond the annotations. However, given readOnlyHint=true and idempotentHint=true in annotations, the description provides minimal additional behavioral detail (e.g., precision, caching, or time source) that would help an agent understand execution 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?

The description is brief (7 words), but since it exactly duplicates the title, it fails to earn its place as additional descriptive text. Front-loaded structure is adequate but content is redundant.

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

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

Given the presence of an output schema and the tool's simplicity (no parameters), the description adequately covers the core function by specifying UTC. However, it misses contextual details relevant to the astronomy/conversion-heavy sibling toolset, such as noting this retrieves system time rather than converting existing timestamps.

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?

Tool has zero parameters; baseline score applies per rubric. No additional parameter context is required or provided.

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?

Tautological: description restates name/title.

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 provided on when to use this tool versus the 'convert_date_time' sibling or other alternatives. No prerequisites or contextual triggers are mentioned.

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

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

Annotations already establish readOnlyHint=true and idempotentHint=true. Description adds no behavioral context beyond annotations—fails to disclose conversion factor (3600x), numeric limits, precision handling, or return format despite absence of output 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?

Extremely brief (4 words), appropriately sized for a simple tool, but wastes potential to add value. Not verbose, yet suffers from under-specification rather than efficient precision.

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?

Lacking output schema, the description omits critical information about what the tool returns (numeric value in arcseconds). For a conversion utility, failing to describe the return value or range constraints leaves significant gaps despite single-parameter simplicity.

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 100% coverage with 'Degrees to convert'. Description adds no additional semantic meaning (syntax, valid ranges, examples) but meets baseline since schema is fully descriptive.

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?

Tautological: description restates name/title.

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 no guidance on when to use this tool versus its inverse (arcseconds_to_degrees) or other angular conversion siblings. No mention of prerequisites or selection 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?

While annotations correctly identify readOnlyHint=true and idempotentHint=true, the description adds no behavioral context beyond these annotations. It fails to disclose expected precision, valid input ranges (e.g., whether negative degrees or values >360 are accepted), or the mathematical operation performed (degrees × π/180).

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 extremely brief (four words) and lacks structural elements like front-loading of key constraints. While not verbose, it suffers from under-specification rather than purposeful conciseness—every word is necessary but collectively insufficient for agent decision-making.

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

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

For a single-parameter mathematical conversion with complete schema coverage and safety annotations, the description is minimally adequate. However, it lacks information about return value format, unit validation, or domain-specific considerations (e.g., handling of angular wrap-around) that would make it 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?

Input schema has 100% description coverage ('Degrees to convert'), which adequately documents the single parameter. The description adds no additional semantic information (e.g., expected value ranges, whether floating-point is required), but baseline score is 3 given complete schema coverage.

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

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

The description 'Convert degrees to radians' is a straightforward tautology that restates the tool name (degrees_to_radians). While technically accurate, it fails to distinguish this tool from its sibling radians_to_degrees or clarify the specific use case within the astronomical/astrodynamics domain evident from other 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 provides no guidance on when to use this tool versus alternatives like radians_to_degrees or degrees_to_arcseconds, nor does it indicate typical usage contexts (e.g., preparing angles for trigonometric calculations). There are no explicit when/when-not conditions mentioned.

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 annotations already declare readOnlyHint=true and idempotentHint=true, covering the operation's safety and repeatability profile. The description adds no behavioral context beyond these annotations regarding precision, valid input ranges (e.g., negative feet), or error handling, but meets the lower bar expected when annotations are present.

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

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

The description consists of a single four-word sentence with no extraneous information, appropriate for a simple single-purpose utility. It efficiently conveys the core operation without unnecessary verbosity, though it offers no structural hooks for complex parsing.

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 unit conversion with one numeric parameter and an obvious output (meters), the description is minimally sufficient given the supporting annotations. However, it omits mention of floating-point precision behavior, negative number handling, or the specific return value format, leaving minor gaps for a scientific computing 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 100%, with the 'feet' parameter adequately described in the schema itself. The description adds no additional parameter guidance regarding expected precision, validation rules, or constraints, warranting the baseline score for well-documented schemas.

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?

Tautological: description restates name/title.

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 prefer this tool over its inverse 'meters_to_feet' or other unit conversion siblings. There are no prerequisites, contextual requirements, or exclusions mentioned to help the agent select this tool appropriately.

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?

While annotations declare readOnlyHint and idempotentHint, the description adds no behavioral context—such as whether windows are returned as intervals or discrete instants, what happens when no solution exists, or computational cost relative to search window size.

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 single sentence is technically brief, but it wastes the description field by merely repeating the title verbatim. No information is front-loaded; the structure provides zero progressive disclosure.

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 complex astronomical tool with 10 required parameters, nested datetime objects, and high-cardinality celestial body enums, the description is inadequate. It omits domain context (ephemeris/SPICE), constraint examples (e.g., 'when altitude > 30 degrees'), and relationship to sibling constraint-finders.

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 100% schema description coverage and extensive enum documentation in the schema, the baseline is 3. The description adds no additional semantic context (e.g., explaining that 'adjustValue' represents a tolerance window, or that 'aberrationCorrection' affects light-time calculations), but the schema carries the full burden adequately.

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?

Tautological: description restates name/title.

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 provided on when to use this tool versus the sibling find_distance_constraint or find_occulting_constraint tools, nor any mention of required prerequisites like valid ephemeris data or observer/target frame compatibility.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, establishing safety. The description adds minimal behavioral context—it implies a search over a time window but does not disclose whether results are inclusive/exclusive of endpoints, behavior when no windows match, or computational cost relative to other constraint searches.

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 single-sentence description is extremely concise with no redundant words. However, it is arguably too terse for the tool's complexity; it lacks structural elements like clause separation or parenthetical context that could improve scannability without sacrificing brevity.

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?

Despite having a rich input schema (100% coverage, multiple enums, nested objects) and an output schema, the description underserves the tool's complexity. It fails to clarify the conceptual model (e.g., distance between observer and target), how aberration corrections affect the calculation, or what the returned datetime windows represent.

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 100% schema description coverage, the schema adequately documents all six parameters (observerName, targetName, relationalOperator, value, aberrationCorrection, searchWindow). The description adds no additional parameter-specific context (e.g., explaining aberration correction options or that value represents distance in kilometers), warranting the baseline score.

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?

Tautological: description restates name/title.

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 no guidance on when to use this tool versus its siblings, nor does it mention prerequisites such as requiring valid ephemeris data or specific observer/target combinations. It lacks explicit when-to-use or when-not-to-use conditions.

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

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

While annotations declare readOnlyHint and idempotentHint, the description adds no behavioral context such as computational complexity, expected result format (window intervals), or handling of cases where no occultation occurs.

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 consists of a single concise sentence with no verbosity. However, it is redundant with the title and fails to front-load additional value, making it minimally sufficient but not 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?

Given the complexity of the domain (6 parameters including nested celestial body enums and aberration corrections), the description is incomplete. It fails to explain the relationships between observer/occulted/occulting bodies or clarify astronomical concepts, relying entirely on the schema and output schema.

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 100% schema description coverage, the parameter definitions are adequately handled by the schema itself. The description adds no additional parameter guidance, meeting the baseline expectation for high-coverage schemas.

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?

Tautological: description restates name/title.

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 no guidance on when to use this tool versus siblings like find_coordinate_constraint or find_distance_constraint, nor does it mention any prerequisites such as required ephemeris data or valid time ranges.

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?

While annotations indicate read-only and idempotent behavior, the description adds no details about what specific geophysical properties are returned (mass, radius, density), data sources, or whether values are averaged or time-dependent.

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 single sentence is efficient and front-loaded with no redundant words, though arguably underspecified given the tool's extensive enum values and output 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?

Minimum viable for invocation given the presence of an output schema and well-defined single parameter, but lacks richness expected for a data retrieval tool with hundreds of enum values and no indication of return value structure.

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

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

With 100% schema description coverage for the single parameter and an explicit enum of 200+ valid celestial body names, the schema is self-documenting. The description adds no additional parameter semantics, warranting the baseline score.

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 identifies the action ('Gets') and resource ('geophysical properties of a celestial body'), distinguishing it from siblings that retrieve orbital state vectors, coordinates, or perform unit 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?

No guidance provided on when to use this tool versus alternatives like get_ephemeris_as_state_vectors or get_horizontal_coordinates that also retrieve celestial body data, or when body properties are needed versus ephemeris data.

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

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

Annotations declare readOnly and idempotent. Description adds valuable behavioral context not in annotations: specifically that coordinates are returned in radians (latitude/longitude) and meters (altitude). No mention of error behavior for invalid DSS selection, though the enum constrains input.

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 with zero waste. Front-loaded action (Get), immediate resource identification, followed by precise unit specification. 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?

Adequate for a single-parameter lookup tool. Leverages the existence of output schema by not over-explaining return structure, while adding crucial semantic context (units) that may not be explicit in the schema. Could improve by noting the specific planetary body (Earth) 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 has 100% description coverage ('The deep space station'). Description adds no parameter-specific guidance, but baseline of 3 is appropriate given complete schema documentation. Does not elaborate on the enum values (DSS_13, DSS_14, etc.).

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?

Clear verb ('Get') and specific resource ('planetodetic coordinates of a deep space station'), with explicit unit definitions. Distinguishes from coordinate conversion siblings by specifying 'planetodetic' (lat/lon/alt) rather than state vectors or horizontal coordinates. Docked one point for not explicitly differentiating from sibling 'get_deep_space_station_state_vector'.

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 implied usage through output specification (use when you need lat/lon/alt in radians/meters), but lacks explicit guidance on when to use this versus 'get_deep_space_station_state_vector' or other DSS coordinate tools, and does not mention that DSS IDs must be selected from the enum.

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 declare readOnlyHint=true and idempotentHint=true. The description adds meaningful context about the observation geometry ('observed from a celestial body in a given frame and time') which clarifies the relativistic nature of the computation. However, it does not explain what the state vector contains (position/velocity), aberration correction specifics, or error behaviors.

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?

Single sentence, 17 words. Every word earns its place with no redundancy or filler. The description is immediately scannable and front-loaded with the essential operation.

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 presence of an output schema and complete parameter definitions, the description provides sufficient context for invocation. It could be improved by briefly explaining that state vectors contain position/velocity data or noting the domain-specific nature of aberration corrections, but it is adequate for the complexity level.

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 reported as 100%. The description reinforces the relationships between observer, frame, and datetime parameters by describing them as 'observed from... in... time'. With high schema coverage, this baseline score reflects that the schema carries the primary semantic load, though the description provides useful integration.

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 provides a specific verb (Get), resource (state vector of a DSS), and scope (observed from a celestial body in a given frame and time). It clearly distinguishes from siblings like get_deep_space_station_planetodetic_coordinates by specifying 'state vector' rather than other coordinate 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 provides no guidance on when to use this tool versus alternatives like get_deep_space_station_planetodetic_coordinates or get_dss_frame. It does not mention prerequisites, typical use cases, or selection 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?

Annotations declare readOnlyHint=true and idempotentHint=true, covering safety aspects. However, the description adds no behavioral context about what the frame represents (e.g., FK5, ITRF), what format it returns, or how it relates to the convert_state_vector_to_the_given_frame sibling. With annotations present, the description should still clarify the domain-specific meaning of 'frame'.

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?

At five words, the description is appropriately concise and front-loaded. While extremely brief, it is not verbose and avoids extraneous information. The brevity becomes a liability for other dimensions but satisfies conciseness.

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 single enumerated parameter, existing output schema, and comprehensive annotations, the infrastructure compensates for the sparse description. However, the failure to define 'frame' or contrast with other DSS accessors leaves a gap in contextual completeness for a domain-specific 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 100% schema description coverage ('The deep space station'), the baseline is 3. The description mentions 'Deep space station' which aligns with the parameter name, but adds no additional semantics about the enum values (e.g., that DSS_43 is Canberra, etc.) or input format requirements beyond what the schema already provides.

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

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

The description 'Find Deep space station frame' essentially restates the title with a synonym ('Find' vs 'Get'), qualifying as tautology. It fails to specify what 'frame' means in this astronomical context (coordinate reference frame vs. image frame) and does not distinguish from sibling tools like get_deep_space_station_state_vector or get_deep_space_station_planetodetic_coordinates.

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 provided on when to use this tool versus alternatives. Given siblings that retrieve state vectors, planetodetic coordinates, and other DSS properties, the description should clarify that this retrieves the reference frame identifier, not positional data.

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

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

Annotations declare readOnlyHint=true and idempotentHint=true; description aligns with these ('Gets'). Adds context that state vectors represent relative positions ('observed from another celestial body') and temporal extent ('time range'), but omits behavioral details like computational cost, precision limits, or aberration correction 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?

Single efficient sentence of 18 words. Zero redundancy. Front-loaded with operation ('Gets the state vectors') followed by parameter context. No filler phrases.

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?

Appropriate for a complex 7-parameter astronomical tool with complete input schema and existing output schema. Covers primary operation and key parameters. Minor gap: does not explicitly indicate this returns a time-series/sequence of vectors (implied by 'time range' and 'timeStep' parameter but not stated in description).

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 100% with all 7 parameters documented. Description provides conceptual grouping (linking observer/target to 'observed from another', frame/time to 'given frame and time range'), but does not explain complex enum concepts like aberrationCorrection codes (LT, LTS, etc.) or specific frame semantics beyond what the schema enums show.

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?

Clear specific verb ('Gets') and resource ('state vectors'), with scope defined by observer/target relationship, frame, and time range. Distinguishes from unit conversion siblings via 'Gets' vs 'Convert', but does not explicitly differentiate from get_deep_space_station_state_vector or guide selection among state vector 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?

No explicit guidance on when to use versus alternatives like get_deep_space_station_state_vector or the various convert_state_vector_to_* tools. No prerequisites or exclusions mentioned despite complex domain-specific parameters (aberration correction, reference frames).

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 annotations already declare readOnlyHint=true and idempotentHint=true, establishing safety and determinism. The description adds the 'epoch' constraint which contextualizes the temporal calculation. However, it fails to disclose what 'horizontal coordinates' specifically returns (angular values? range?), whether it handles below-horizon cases, or the specific reference frame used.

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, efficient sentence with no redundant words. Every element—action, target resource, origin point, and time parameter—is essential and front-loaded. Zero fluff or tautology.

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 presence of an output schema and 100% parameter coverage, the description adequately covers the basic invocation contract. However, for a specialized domain tool with complex enums (184 celestial bodies, 17 DSS stations), it could provide domain context such as clarifying that horizontal coordinates refer to local azimuth/elevation or mentioning typical use cases (antenna pointing, observation planning).

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 100% schema description coverage, the schema fully documents all four parameters including the datetime format requirements and aberration correction options. The description mentions 'at given epoch' which loosely maps to the datetime parameter but does not add semantic meaning beyond the schema's technical specifications. Baseline 3 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 clearly states the specific operation (get horizontal coordinates), the reference point (deep space station/DSS), and the temporal aspect (at given epoch). It implicitly distinguishes from siblings like 'get_deep_space_station_state_vector' by targeting celestial bodies and specifying 'horizontal' coordinates, though it could explicitly clarify what 'horizontal' means (e.g., azimuth/elevation) to fully separate from equatorial or other 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?

No guidance is provided on when to use this tool versus alternatives like coordinate conversion utilities (e.g., convert_state_vector_to_equatorial_coordinates) or when horizontal coordinates are preferred over state vectors. There are no prerequisites, constraints, or selection criteria mentioned.

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 adds no behavioral context beyond what the annotations provide (readOnlyHint and idempotentHint correctly establish the calculation is safe and repeatable), but it does not contradict these annotations.

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

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

The four-word description is appropriately brief for a trivial unit-conversion operation and front-loads the core action, though it redundantly duplicates the title.

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 low complexity, complete input schema coverage, and presence of safety annotations, the minimal description suffices for correct invocation despite lacking output format 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?

With 100% schema description coverage for the single required parameter, the schema fully documents inputs; the description adds no supplementary parameter semantics, meeting the baseline threshold for high-coverage schemas.

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?

Tautological: description restates name/title.

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 select this tool versus its inverse 'meters_to_kilometers' or other length-conversion utilities in the extensive sibling list.

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?

While the annotations declare readOnlyHint=true and idempotentHint=true, the description adds no behavioral context beyond these annotations. It does not disclose precision limits, floating-point behavior, or the specific nature of the return value (e.g., whether it returns a raw number or formatted string).

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 extremely concise with no wasted words. Every word earns its place in defining the conversion. However, it borders on under-specification rather than elegant conciseness given the lack of any contextual 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 single-purpose conversion utility with one required parameter and provided annotations, the description is minimally adequate. However, given the lack of output schema, it could benefit from mentioning that it returns the equivalent distance in meters or noting the relationship to its inverse sibling.

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

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

With 100% schema description coverage ('Light years to convert'), the schema adequately documents the single parameter. The description adds no additional semantic information (such as valid ranges or that negative values may be physically meaningless), warranting the baseline score for high-coverage schemas.

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?

Tautological: description restates name/title.

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 no guidance on when to use this tool versus alternatives. It does not mention the directional nature of the conversion or clarify that this converts TO meters (as opposed to FROM meters using the sibling 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?

Annotations declare readOnlyHint=true and idempotentHint=true, indicating safe, repeatable computation. However, the description adds no behavioral context beyond annotations—no mention of precision, handling of negative inputs, or return value 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 extremely brief (six words), creating a tautology rather than efficient information delivery. While appropriately sized in length, it wastes the opportunity to add value beyond the tool name.

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

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

Given the presence of 50+ sibling conversion tools, the description fails to provide necessary disambiguation (e.g., clarifying this converts to AU for solar system scale distances). Relies entirely on schema/annotations without adding domain 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?

With 100% schema description coverage, the parameter 'meters' is fully documented in the schema itself. The description adds no additional semantic information (e.g., expected magnitude for astronomical contexts), meeting the baseline for high-coverage schemas.

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?

Tautological: description restates name/title.

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 provided on when to use this tool versus alternatives (e.g., when to use meters-to-AU versus meters-to-light-years or the inverse astronomical_units_to_meters). No mention of appropriate input ranges or use cases.

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?

While annotations correctly declare readOnlyHint=true and idempotentHint=true, the description adds zero behavioral context beyond the name. It omits the conversion factor, precision behavior, or whether this uses standard or nautical definitions given the aerospace 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 extremely brief (three words), but it fails to earn its place—it conveys no information not already present in the tool name. It is not front-loaded with value.

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 single-parameter conversion tool with good safety annotations, the description is minimally adequate. However, it lacks any mention of output format, precision, or the specific conversion constant used, which would be helpful given the scientific 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 100% (the 'meters' parameter is documented in the schema). The description adds no additional semantic information about the parameter, meeting the baseline expectation when schema coverage is complete.

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?

Tautological: description restates name/title.

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 provided on when to use this specific direction of conversion versus the inverse 'feet_to_meters', nor any mention of precision requirements or astronomical context implied by the 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 declare readOnlyHint=true and idempotentHint=true, covering the safety profile. However, the description adds zero behavioral context—omitting the conversion factor (division by 1000), return type, precision, or output format that would help the agent understand the computation.

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

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

Extremely concise (3 words), but this constitutes under-specification rather than efficient information density. No redundant sentences, yet the single sentence merely duplicates the title without front-loading unique value.

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?

Simple single-parameter tool with good schema coverage, but lacking output schema. Description fails to specify what the function returns (kilometers as a number, object structure, etc.), leaving the agent to infer the output format.

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

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

Input schema has 100% description coverage ('Meters to convert'), establishing baseline score of 3. The description implies the input unit but adds no syntax clarification, validation constraints, or examples beyond what the schema provides.

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

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

Tautological: description restates name/title.

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 provided on when to use this tool versus its inverse 'kilometers_to_meters' or other unit conversion siblings. No explanation of appropriate input ranges or use cases.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, establishing this as a safe calculation. The description adds no behavioral context regarding floating-point precision, rounding behavior, or what occurs with edge case inputs (zero/negative meters).

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?

While extremely brief (4 words), the description wastes its single sentence on tautology rather than front-loading useful constraints or relationships. It appropriately matches the tool's simplicity but fails to earn its place with informative 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 conversion tool amidst numerous astronomical unit siblings, the description omits critical context: the inverse relationship to light_years_to_meters, expected output format, and precision limits. With no output schema provided, the description should compensate but does not.

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 100% with the 'meters' parameter already described as 'Meters to convert'. The description adds no additional semantic context (e.g., expected scale, units clarification), warranting the baseline score for high-coverage schemas.

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?

Tautological: description restates name/title.

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 provided on when to use this tool versus its inverse (light_years_to_meters) or other distance conversion siblings like meters_to_parsec. No mention of input validation (e.g., negative values) or typical use cases.

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 annotations declaring readOnlyHint and idempotentHint, the safety profile is covered. However, the description adds no behavioral context regarding precision, rounding behavior, handling of negative inputs, or the structure of the 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?

The description is extremely brief (four words) and contains no redundant or wasted text. However, it is so minimal that it borders on under-specification rather than demonstrating efficient information density.

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 an output schema, the description should indicate what the tool returns (converted value in miles). It fails to do so, leaving the output format undocumented despite the tool's functional simplicity.

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 100% with the parameter 'meters' adequately described in the schema as 'Meters to convert'. The description adds no additional semantic details about the parameter, meeting the baseline expectation when schema documentation is complete.

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?

Tautological: description restates name/title.

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 no guidance on when to use this tool versus alternatives such as miles_to_meters (the inverse) or other unit converters, nor does it mention prerequisites or input 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?

Annotations cover read-only and idempotent safety properties, but the description adds zero behavioral context regarding precision, floating-point handling, or the return value format. With no output schema, the omission of what the tool returns (parsecs) is significant.

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 brief at four words, but earns minimal credit because it merely duplicates the title without adding informational value. No structural issues, but fails the 'every sentence earns its place' standard.

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 single-parameter conversion tool, the description remains incomplete due to the missing output schema. It fails to state that the return value represents the equivalent distance in parsecs, leaving the agent uncertain about the result format.

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

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

With 100% schema description coverage ('Meters to convert'), the schema fully documents the single parameter. The description adds no additional semantics about valid ranges or input constraints, warranting the baseline score of 3.

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?

Tautological: description restates name/title.

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 provided on when to select this tool versus its inverse sibling 'parsec_to_meters' or other distance conversion tools. The agent must infer usage solely from parameter names without explicit directional 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?

The description adds no behavioral context beyond the annotations. While the annotations correctly declare readOnlyHint and idempotentHint, the description does not disclose error handling (e.g., negative inputs), precision/rounding behavior, or the expected return format. No contradiction with annotations.

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

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

The description is extremely brief (three words) and front-loaded. While not wasteful, its extreme minimalism renders it barely informative. For a simple conversion tool this brevity is acceptable, though it borders on under-specification.

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 (single parameter, no nested objects) and strong annotation coverage, the description is minimally adequate. However, it lacks mention of the output unit (meters) format or any caveats that would complete the agent's understanding of the conversion behavior.

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

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

With 100% schema coverage where the parameter is described as 'Miles to convert', the description meets the baseline. However, it adds no additional semantic value—such as valid ranges, expected precision, or whether floating-point values are accepted—beyond what the schema already provides.

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

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

Tautological: description restates name/title.

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 the inverse converter 'meters_to_miles' or other length conversion tools in the sibling list, nor does it mention precision requirements or valid input ranges.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety and determinism profile. The description adds no information about precision, valid input ranges, or error behavior for invalid inputs, offering minimal value beyond the structured annotations.

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

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

The description is extremely terse (four words), which prevents verbosity, but it is not front-loaded with valuable information—it merely repeats the title. It neither wastes space nor provides structured value.

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 mathematical conversion with one required parameter and good annotations, the description is functionally minimal. However, given the presence of numerous sibling conversion tools spanning different unit domains (terrestrial vs. astronomical), it should specify that this handles astronomical distance units to aid tool selection.

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 100% schema description coverage, the parameter semantics are already well-documented in the schema ('Parsec to convert'). The description adds no additional context about typical values, constraints, or astronomical meaning of a parsec, meeting the baseline expectation when the schema does the heavy lifting.

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?

Tautological: description restates name/title.

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 no guidance on when to use this tool versus alternatives like light_years_to_meters or astronomical_units_to_meters, nor does it indicate the typical scale of values (astronomical distances) for which parsecs are appropriate.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, establishing safe read-only behavior. The description adds minimal behavioral context beyond this, failing to mention the conversion factor, precision limits, or that it operates as a pure mathematical function, though it correctly implies a computational transformation.

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, efficient sentence with no wasted words or redundant information. It is appropriately front-loaded with the operation verb. However, extreme brevity leaves room for additional context (e.g., return type) without sacrificing conciseness.

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

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

For a single-parameter unit conversion tool with complete annotations and 100% parameter coverage, the description provides the essential minimum. While it lacks an output schema or explicit return value description, the tool's straightforward mathematical nature makes this omission less critical, though still 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?

With 100% schema description coverage, the parameter 'radians' is fully documented in the schema itself. The description implicitly references the input parameter but does not add syntax details, validation constraints, or semantic context beyond what the schema already provides, meriting the baseline score.

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?

Tautological: description restates name/title.

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 no guidance on when to use this tool versus alternatives like radians_to_degrees or degrees_to_arcseconds, nor does it explain why one might need arcseconds specifically. It only states the conversion operation without contextual usage hints.

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?

While annotations declare readOnlyHint and idempotentHint, the description adds no behavioral context (e.g., precision, error handling, return format) beyond what the structured fields already provide.

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 single sentence is appropriately brief for a simple conversion tool, though it fails to earn its place by duplicating the title without adding value.

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 single-parameter mathematical conversion, though it lacks domain context (astronomy/space) implied by sibling tool names that would help situate its 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?

With 100% schema description coverage for the single 'radians' parameter, the description meets the baseline expectation even though it adds no parameter-specific guidance.

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?

Tautological: description restates name/title.

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 no guidance on when to use this tool versus alternatives like degrees_to_radians or radians_to_arcseconds, or any other context for selecting this conversion.

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