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

With no annotations, the description carries the full behavioral burden. It usefully discloses the batching intent (one round trip) and the safety boundary around irreversible commands, but says nothing about ordering, partial-failure behavior, atomicity, or whether results come back per command.

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, zero filler, with the batch rationale front-loaded and the safety constraint second. Nothing to trim.

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

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

No annotations, no output schema, no parameter documentation, and no enumeration of the safe commands that may be batched. For a tool whose entire surface is a free-form command list, the description leaves the core question an agent must answer before calling it unanswered.

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

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

Schema description coverage is 0% and the single parameter is an opaque array of objects with free-form 'command' and 'args' fields (additionalProperties: true). The description gives no indication of valid command identifiers or args shape, so the schema is essentially undiscoverable from the definition.

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

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

States a specific verb+resource (batch-send KSP commands over one bridge round trip) and the motivation (reduce latency), so it is distinguishable from the single-purpose siblings. It does not explain what a 'command' string actually is, but the overall purpose is unambiguous.

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

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

Explicitly states the exclusion: irreversible launch/abort/recovery commands must use dedicated tools, which routes the agent to ksp_editor_launch, ksp_flight_abort, and ksp_flight_recover. It does not state the positive trigger (e.g. 'use when issuing 2+ independent safe commands') as concretely, so it falls just short of a full when/when-not/alternatives treatment.

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

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

With no annotations provided, the description carries the full behavioral burden but delivers almost none: it does not say whether the editor scene must be active, whether the part is persisted to the craft, what happens on invalid part ids, or how the added part interacts with staging/action groups. Only the 'one real part' phrasing vaguely implies validation.

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

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

A single well-formed sentence with the core action front-loaded and no filler. It is concise, though the brevity is partly under-specification rather than disciplined editing.

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

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

For a mutation tool with 11 parameters, no annotations, no output schema, and a nested object parameter, the description is far too thin. An agent lacks the information needed to supply the required id/part correctly or to understand attachment semantics.

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

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

Schema description coverage is 0% across 11 parameters, including a nested object (action_groups) and required id/part, yet the description explains none of them. It only gestures at parent attachment, leaving stage, variant, position, rotation, attach_node, snap_to_node, and parent_attach_node completely undocumented in both schema and description.

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

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

States a specific verb (add) and resource (KSP part) scoped to the current editor craft, which is enough for an agent to identify the operation. However, it does not distinguish itself from the sibling ksp_editor_attach_part, so an agent cannot tell from the description alone which one to pick when the intent is attachment.

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

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

The phrase 'optionally attached to an existing part' hints at the parent-child case but never states when to use this tool versus ksp_editor_attach_part or ksp_editor_update_part. No prerequisites (e.g., must be in the editor scene) or exclusion conditions are given.

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

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

No annotations are supplied, so the description carries the full burden. 'Analyze' implies a read-only computation, but the description says nothing about side effects, whether it mutates the craft, cost/latency, or whether it requires a craft to be present in the editor. It adds essentially no behavioral context beyond 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?

A single dense sentence that front-loads the verb and lists the analysis outputs with no filler. Appropriately sized, though the unqualified list slightly blurs what is actually returned.

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

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

No output schema and no annotations, so the description is the only source of information. It defines the scope of the analysis well, but leaves the return shape (approximate metrics? warnings? raw parts?) and the lone parameter unexplained — adequate but with clear gaps for a tool with zero structured support.

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

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

Schema description coverage is 0% and there is one parameter (include_parts) whose meaning is documented nowhere. The description never mentions the parameter, its default, or what including parts changes in the output, so it fails to compensate for the coverage gap.

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

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

States a specific verb (Analyze) and enumerates the concrete analyses it performs (mass, TWR, staging delta-v, CoM/CoT geometry, launch-risk warnings), which separates it from siblings like ksp_editor_validate or ksp_parts_list. It stops short of explicitly naming which sibling to prefer, so it is clear but not fully differentiated.

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?

There is no statement of when to run this analysis versus ksp_editor_validate, ksp_editor_get_craft, or ksp_editor_launch, nor any precondition (craft loaded/edited) or exclusion. Usage is only implied by the verb.

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

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

No annotations are provided, so the description carries the full burden. 'Replace the editor' hints that existing editor content is overwritten, which is the one useful disclosure, but there is nothing about async job behavior, permissions, live vs. non-live semantics, or whether the operation is reversible. For a bulk mutation tool this is a significant gap.

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

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

Two sentences, front-loaded with the core action and no filler. Efficient, though the second sentence is thin enough that the brevity reads partly as under-specification rather than economy.

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 a nested craft schema, 6 parameters, no annotations, and no output schema, the description is far too sparse. It leaves the interaction between `live`, `pace`, `wait_for_completion`, and `require_connected` unexplained, and says nothing about what happens to the current editor contents beyond the word 'replace'.

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 only 17% (just `pace`), and the description adds nothing about any of the 6 parameters. The phrase 'complete craft document' gives faint meaning to the required `craft` payload, but `live`, `require_connected`, `wait_for_completion`, and `parts_per_frame` remain undocumented. Low coverage and no compensating detail.

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

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

States a specific verb and resource ('replace the editor with a complete craft document') and adds scope ('built from zero', 'main bulk-building tool'). This implicitly separates it from incremental siblings like ksp_editor_add_part/attach_part, though it never names them. Clear enough that an agent knows what the tool does.

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

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

The phrase 'main bulk-building tool' implies a when-to-use condition (bulk construction vs. piecewise editing), but there is no explicit guidance about when to prefer ksp_editor_new, ksp_editor_load, or ksp_editor_clear, nor any preconditions. Usage is implied, not stated.

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

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

With no annotations, the description carries full behavioral burden. It implies a mutation (attaching/reconnecting a part) but does not disclose side effects, required editor scene, permissions, reversibility, or what happens if nodes are invalid. Only 'using explicit KSP attachment nodes' hints at parameter intent.

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

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

A single front-loaded sentence with no wasted words. It is structurally clean, though extremely terse for the tool's complexity.

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

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

For a mutation tool with no annotations, no output schema, and zero schema descriptions, the description leaves critical gaps: parameter meanings, prerequisites, side effects, and attachment semantics. It is not complete enough to reliably invoke.

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

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

Schema coverage is 0% and 5 parameters are fully undocumented. The phrase 'explicit KSP attachment nodes' vaguely relates to attach_node and parent_attach_node, but id, parent_id, and snap_to_node are not explained, leaving required inputs ambiguous.

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

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

States a specific verb ('Reconnect') and resource ('existing editor part to a parent') and references KSP attachment nodes. It distinguishes itself from sibling add_part by specifying 'existing', though it does not explicitly route to alternatives.

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

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

Usage is implied by 'existing editor part' and 'reconnect', suggesting a part already in the editor that needs reattachment. However, there is no explicit when-to-use, when-not-to-use, or comparison to siblings like ksp_editor_add_part or ksp_editor_update_part.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the side effect that partially generated parts are retained rather than discarded, but says nothing about what happens if the job is already finished, whether the call is idempotent, or any authentication/error behavior.

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

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

One sentence, front-loaded with the action and with zero padding. Slightly dense jargon ('frame-sliced editor build') but no wasted words.

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

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

For a single-parameter mutation with no annotations and no output schema, the description covers the key outcome (partial parts preserved) but omits parameter meaning and failure/return behavior. Adequate but with clear gaps.

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

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

Schema description coverage is 0% and the single parameter job_id is never mentioned in the description. The agent must infer that job_id refers to the build being cancelled and that it must be currently active.

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

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

States a specific verb ('Stop') and a specific resource ('an active frame-sliced editor build'), which separates it from the read-only sibling ksp_editor_job_status. It does not explicitly name that sibling, so the differentiation is implicit rather than stated.

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

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

The phrase 'keep the parts already generated for inspection or cleanup' implies the situation in which you would cancel rather than clear (ksp_editor_clear) or poll (ksp_editor_job_status), but no alternative is named and no explicit when/when-not condition is given.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose that the operation is bulk-destructive ('every part'), but says nothing about reversibility, undo, confirmation, whether the craft must be in an editable state, or what happens afterward. That leaves significant gaps for a destructive bulk operation.

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

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

A single short sentence with no filler, and the scope ('every part') is front-loaded. Slight awkwardness in 'the current editor craft' prevents a top mark but nothing is wasted.

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

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

For a no-parameter, no-output-schema tool, the description is minimally adequate. It identifies the action and scope but omits the destructive-operation context an agent would want before clearing an in-progress craft.

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

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

The tool takes zero parameters, so the schema has nothing to document and the description need not compensate. Baseline 4 applies since there are no parameter semantics to clarify.

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

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

States a specific verb ('clear') and resource ('every part from the current editor craft'), making the bulk-removal action unambiguous. It does not name sibling operations like ksp_editor_remove_part (which deletes one part) or ksp_editor_new, so an agent must infer the distinction from names alone.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as ksp_editor_remove_part for partial removal or ksp_editor_new/ksp_editor_load for starting fresh. The agent gets no help deciding this versus other editor-mutation siblings.

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

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

With no annotations, the description carries the full burden. It discloses the method (in-game bridge) and clarifies it's not UI automation, which is useful. But it doesn't state whether this requires specific game state, potential side effects, or what happens if already in the editor. The schema's save_folder parameter hints at title-screen handling, but the description doesn't elaborate.

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

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

A single, front-loaded sentence that conveys the core purpose without any extraneous words. It is appropriately sized for the tool's complexity.

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

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

For a tool with no annotations, no output schema, and only 33% parameter schema coverage, the description is somewhat lacking. It doesn't explain the return value, potential errors, or the effect of the timeout parameter. However, it does clarify the mechanism, which is a key piece of context. More detail would improve completeness.

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

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

Schema description coverage is 33%. The description adds no information about the timeout, editor_mode, or save_folder parameters beyond what the schema provides. The schema already documents save_folder and defines enum for editor_mode; timeout is undocumented in both. Baseline 3 is appropriate given partial schema coverage and no added parameter semantics.

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

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

The description states a specific action (enter the editor) on a specific resource (KSP VAB or SPH) and identifies the mechanism (in-game bridge, not UI automation). It distinguishes itself from sibling editor tools like ksp_editor_new or ksp_editor_apply_craft, though it doesn't explicitly name them.

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

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

The phrase 'without visual UI automation' implies this is the preferred way to enter the editor, providing some context. However, there's no explicit guidance on when to use this tool versus alternatives like ksp_editor_new, or prerequisites such as being at the title screen or in a save.

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

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

No annotations are provided, so the description carries the full burden. It signals a read by saying it 'returns' state and enumerates the returned content, but does not explicitly confirm it is side-effect free, what happens when no craft is loaded, or whether the response is additive/full-snapshot. Adequate but incomplete for a tool with zero annotation coverage.

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

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

A single front-loaded sentence listing the returned components with no filler. Appropriate size for a zero-parameter getter.

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

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

No output schema exists, so the description is responsible for conveying return content, and it does list the major components (tree, transforms, nodes, modules, resources, staging). Missing situational context such as required scene or error behavior keeps this from a 5.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond the empty schema.

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

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

States a specific verb ('Return') and enumerates the exact resource it exposes (craft tree, part transforms, nodes, modules, resources, staging). An agent can distinguish it from siblings like ksp_editor_validate or ksp_editor_analyze, though the description never explicitly contrasts them.

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

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

No guidance on when to call this versus ksp_editor_analyze, ksp_editor_validate, ksp_editor_job_status, or other editor state readers. There are no prerequisites or scene conditions stated (e.g. must be in the editor scene, craft must be loaded).

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

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

No annotations are provided, so the description carries the full burden. It does disclose one useful behavioral trait — that it returns progress rather than the whole craft tree — but says nothing about terminal states, behavior for an unknown/finished job_id, or error handling.

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

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

One tightly written sentence with the action front-loaded and zero filler. Every clause earns its place.

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

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

For a single-parameter read tool with no annotations and no output schema, the description conveys the core intent but omits the job_id origin, what the progress payload looks like, and how terminal/failed jobs are represented — modest gaps for an otherwise simple tool.

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

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

Schema description coverage is 0% for the single required job_id parameter, and the description never mentions it. The agent gets no guidance on where job_id comes from or its expected format, so the description fails to compensate for the schema gap.

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

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

States a specific verb and resource: reading the progress of an asynchronous editor build or load job. It implicitly distinguishes itself from ksp_editor_get_craft by noting it does not request the full craft tree, but it doesn't name that sibling explicitly.

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

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

The phrase 'asynchronous editor build or load job' implies this is used after kicking off a job to poll its progress, but no explicit when-to-use trigger, prerequisites, or named alternative (e.g. ksp_editor_get_craft for the full tree) is given.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses the mandatory confirm gate, the default side effect of clearing occupied launch pads via stock recovery, the opt-out flag, and the asynchronous nature (returns a request, the caller must wait for FLIGHT and verify telemetry). Missing only what happens on failure or whether the craft must be validated beforehand.

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?

Four tight sentences, each earning its place: action, requirement, default behavior with opt-out, and async return/next-step instruction. Front-loaded with the core action.

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

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

For a 2-parameter launch tool with no output schema and no annotations, the description covers the key gaps: required input, default side effect, and what an AI must do after the call (wait for FLIGHT, verify telemetry). It does not mention error handling or prerequisite validation, but the core operational picture is complete.

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

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

Schema description coverage is 0%, so the schema gives no parameter meaning. The description fully explains both parameters: confirm is a required gate, and auto_clear_launchpad defaults to true with a clear semantic (set false to leave the stock dialog open). This compensates for the schema gap.

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

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

States a specific verb (launch) and resource (the validated editor craft via KSP's native path), and implicitly distinguishes itself from editor-manipulation siblings like ksp_editor_validate. It doesn't explicitly name a sibling it replaces or is replaced by, but the action is unambiguous.

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

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

Conveys that this is the launch step after validation, and that confirm=true is mandatory, but offers no explicit when-to-use vs alternatives such as ksp_editor_enter or ksp_flight_* tools. Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden. It doesn't say what happens to the currently loaded craft, whether it requires an active editor, how 'name' vs. 'path' are resolved, whether loading overwrites unsaved changes, or what error behavior to expect. 'Real' .craft file implies filesystem access but nothing more is disclosed.

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

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

A single, front-loaded sentence with no wasted words. Appropriate length for the 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?

A load/mutation operation with no annotations, no output schema, 0% param coverage, and all-optional parameters. The description does not provide enough to call it correctly or predict its side effects. This is under-specified for the complexity involved.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions the .craft file and the editor target, but does not explain the relationship between 'name' and 'path', nor how 'editor_mode' (VAB/SPH) interacts with 'the active VAB/SPH editor'. With all three params undocumented, the gap is significant.

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

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

The description states a specific verb and resource: 'Load a real KSP .craft file into the active VAB/SPH editor.' This clearly distinguishes it from ksp_editor_apply_craft (which applies an in-memory craft) and ksp_editor_new. It's clear, but doesn't explicitly contrast with the closest sibling.

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

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

No guidance on when to use this vs. ksp_editor_new, ksp_editor_apply_craft, or ksp_game_load_save. With 0 required parameters (name, path, editor_mode all optional), an agent has no instruction on which to supply. No prerequisites or context are given.

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

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

With no annotations, the description carries the full burden, and it does disclose the key destructive behavior: the current editor craft is removed. However, it says nothing about unsaved-change loss, whether the editor scene is entered automatically, or what happens if no craft is loaded.

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?

One compact sentence with no filler, and the primary action is front-loaded ahead of the destructive side-effect. Slightly dense but not wasteful.

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

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

No annotations, no output schema, and three undocumented parameters. For a state-changing editor tool the description should explain prerequisites (e.g., must be in the editor) and the resulting state, but it omits all of that.

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

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

Schema description coverage is 0% across three parameters (name, description, editor_mode). The description only loosely touches editor_mode via 'VAB or SPH' (already in the enum) and gives no meaning for name or description, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Start a new empty VAB or SPH craft') plus the destructive side-effect of removing the current craft. It is clear what the tool does, though it does not distinguish itself from siblings like ksp_editor_clear or ksp_editor_enter.

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 indication of when to use this versus ksp_editor_clear, ksp_editor_enter, or ksp_editor_load. An agent must infer that this is the 'fresh start' path, which leaves real ambiguity among the many editor siblings.

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

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses the default destructive scope (child subtree is removed unless overridden), which is the single most important trait for a delete tool, but says nothing about reversibility, failure modes, or whether dangling references/invalid craft state can result.

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

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

A single front-loaded sentence with no filler. The default-scope clause is appended where it matters most, right after the core action.

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 two-parameter mutation with no annotations and no output schema, the description covers the key destructive nuance but leaves the id format and the include_children=false behavior to inference. Adequate but thin given the complete absence of structured documentation.

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

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

Schema description coverage is 0%, so both parameters are undocumented in structured data. The phrase 'by default' implies include_children can be turned off, but the description never names the parameter, states its default value explicitly, or clarifies whether id refers to a part name, index, or instance identifier.

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

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

States a specific verb (remove) and resource (editor part), plus the scope of what is deleted. It clearly distinguishes itself from the add_part/attach_part/update_part siblings in the editor family, though it does not name any of them explicitly.

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

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

There is no indication of when to use this instead of alternatives (e.g. update_part for modifying, clear for wiping the craft), nor any prerequisites such as being in the editor scene. The agent must infer usage entirely from the tool name.

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

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

No annotations are provided, so the description carries the full burden. 'Save as a real .craft file' hints at a persistence distinction, but it says nothing about overwrite semantics, default path/name behavior when parameters are omitted, permissions, or failure modes — significant gaps for a write operation.

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

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

A single efficient sentence with no waste, front-loading the action and target. It is appropriately short, though brevity here borders on under-specification rather than genuine 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?

A mutation/persistence tool with no annotations, no output schema, and 0% parameter coverage needs the description to compensate, and it does not — it omits default behavior, overwrite handling, and return 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?

All three parameters (name, path, overwrite) have 0% schema description coverage, and the description mentions none of them. It is especially unclear what happens when name/path are omitted, since all parameters are optional — the description adds no meaning beyond the bare schema.

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

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

States a specific verb+resource: saving the current editor craft as a real KSP .craft file. The phrase 'current editor craft' makes the operating context clear. It does not explicitly distinguish itself from siblings like ksp_editor_apply_craft or ksp_editor_new, but the save-to-disk framing is discernible.

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 when-to-use guidance, no stated prerequisites (e.g. must be in the editor scene, must have a craft loaded). The agent must infer that this is the terminal step after building a craft, with no mention of alternatives.

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

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

No annotations are provided, so the description carries the full burden. It doesn't disclose whether this requires editor mode, what happens if the part or group is invalid, whether it overwrites existing assignments, or any permission/auth requirements. For a mutation tool with zero annotation coverage, this is a significant gap.

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

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

A single, well-structured sentence that front-loads the core purpose and provides examples without waste.

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

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

With no annotations, no output schema, and 0% schema description coverage for 3 required parameters, the description is incomplete. It should explain prerequisites (e.g., editor mode), parameter semantics, and side effects, but it only names the action groups.

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

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

Schema description coverage is 0%, so the description must compensate. It only implies that 'group' takes one of the listed values but doesn't document the 'id' or 'action' parameters, their formats, or valid ranges. The description adds some meaning for 'group' but leaves the other two parameters completely undocumented.

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 (assign) and resource (a part action to a stock KSP action group) with concrete examples (SAS, RCS, Abort, Custom01, None). Distinguishable from siblings like ksp_editor_update_part, though the description doesn't explicitly differentiate.

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

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

No guidance on when to use this tool versus alternatives like ksp_editor_update_part or ksp_editor_set_stage. The description only states what the tool does, with no context or conditions for use.

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

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

No annotations are provided, so the description carries full behavioral burden. 'Set' implies mutation, but the description omits side effects, required editor scene context, whether changes are reversible, and what 'inverse/original' means operationally.

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, front-loaded sentence with no wasted words. However, the cryptic phrase 'inverse/original' slightly reduces clarity without adding compensating structure.

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

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

For a mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is too thin. It does not explain how to obtain the required id, when the editor context is required, or what happens after setting the stage.

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

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

Schema description coverage is 0% for two required parameters. The description mentions 'stage number', which loosely maps to the stage parameter, but it gives no meaning for the id parameter or the accepted format, valid ranges, or how stage relates to inverse/original staging.

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

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

The description states a specific verb and resource: setting the stage number for an editor part. It does not explicitly differentiate from siblings like ksp_editor_update_part, but the 'editor part' scope is clear enough for an agent to identify the operation.

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?

There is no guidance on when to use this tool versus alternatives such as ksp_editor_update_part or ksp_flight_stage. The description only states what it does, leaving all usage context to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says the tool mutates a part but omits whether changes are reversible, whether the part must be unlaunched/rooted, how reparenting interacts with attach_node, or what happens to fields not supplied. For a mutation tool with zero annotation coverage this is thin.

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

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

A single, front-loaded sentence that wastes no words. It is efficient, though its brevity is partly under-specification rather than disciplined editing given the 9-parameter surface.

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

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

For a 9-parameter mutation tool with nested action_groups, no annotations, and no output schema, the description is far too sparse. It gives no indication of return behavior, validation, or how the parameters combine, leaving the agent to guess at invocation semantics.

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

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

Schema description coverage is 0%, so the description must compensate. It loosely maps verbs to some parameters (move→position, rotate→rotation, reparent→parent_id, change stage→stage, action_groups→action_groups), but leaves snap_to_node, attach_node, and parent_attach_node unexplained, and gives no format details such as quaternion ordering for rotation or vector semantics for position.

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 gives a clear verb set (move, rotate, reparent, change stage, update action groups) applied to a specific resource (an editor part). However, it does not acknowledge overlap with siblings like ksp_editor_set_stage and ksp_editor_set_action_group, which appear to duplicate two of the listed capabilities. An agent cannot tell from the description alone which tool to prefer for a stage or action-group change.

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?

There is no when-to-use guidance, no prerequisites (e.g. must be in the editor scene), and no routing to alternatives. Given that dedicated siblings exist for stage and action-group updates, the absence of any disambiguation is a real gap.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the return contents (errors, warnings, cost, connectivity, part counts), which is genuine behavioral information, but it never states that this is a non-mutating check or what happens to the craft on failure, so the safety profile remains unstated.

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

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

A single sentence that front-loads the action and scope, then lists the outputs compactly. No filler, no restatement of the name, and every element carries information.

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

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

With no output schema, the description must convey return values, and it does so by enumerating errors, warnings, cost, connectivity, and part counts. What remains missing is any indication of whether validation gates the launch flow or what the errors look like, but the coverage is solid for a zero-argument check.

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

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

The tool takes zero parameters (empty properties, no required fields) and the schema coverage is 100%, so there is nothing for the description to add or compensate for. Baseline 4 applies for a parameterless tool.

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

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

States a specific verb (Validate) and resource (the current editor craft), and enumerates the validation outputs. It is clear on its own, but does not differentiate itself from the closely related sibling ksp_editor_analyze, leaving the agent to infer which of the two to pick.

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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternative. The phrase 'current editor craft' only weakly implies the editor-scene context, and nothing tells the agent when to prefer this over ksp_editor_analyze or when validation must be run before ksp_editor_launch.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Fire' implies a mutating, likely irreversible in-flight action (abort groups in KSP can decouple stages, trigger escape systems, etc.), yet the description says nothing about what happens to the craft, whether it can be undone, or what it requires. This is a significant gap for an action tool.

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

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

A single short sentence, front-loaded and free of filler. It is not padded, though it is arguably too terse given what the action does.

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

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

For a zero-parameter, no-output-schema action tool, the description needn't explain return values, but it should convey the effect and risk of the action. It omits what firing the abort group does, leaving the agent unable to judge consequences before invoking it.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; baseline 4 applies. Nothing in the description is needed to compensate for schema gaps.

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

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

States a specific verb (fire) and resource (the stock Abort action group), which is enough to distinguish it from siblings like ksp_flight_stage or ksp_flight_set_controls. It stops short of explaining what 'firing the abort group' actually does, but the action itself is unambiguous.

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

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

There is no guidance on when to fire the abort group, what preconditions apply, or which sibling to use instead for related actions. The agent must infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a mutating action ('Trigger') but does not disclose side effects, reversibility, required permissions, or what happens if both identifiers are given or omitted; this is a significant gap for an action tool.

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

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

A single, front-loaded sentence with no wasted words. It is appropriately sized for the information it conveys, even though that information is thin.

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

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

With no annotations, no output schema, and 0% schema coverage, the description is too sparse for a 3-parameter action tool. It omits parameter meaning, behavioral effects, and return expectations, leaving the agent with major unknowns before calling it.

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

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

Schema description coverage is 0%, so the description must compensate. It names part_id and flight_id as alternative identifiers, but it completely omits the 'event' parameter and does not explain valid values, precedence between the two ids, or required/optional status.

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

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

The description uses a specific verb ('Trigger') and names the resource ('part event/action'), plus the identifiers it accepts ('MCP part id or vessel flight id'). It is clear what the tool does in general terms, though it does not distinguish itself from siblings like ksp_flight_stage or ksp_flight_set_controls.

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 contains no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of required game/flight state. It only states the mechanism, leaving the agent to infer usage context entirely.

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

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

With no annotations, the description carries full burden. It does disclose the confirmation gate and the delta-v coordinate frame, which are useful behavioral facts, but omits whether the node is appended to existing nodes, whether the call is idempotent, what happens on failure, or any rate/rate-limit behavior.

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

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

Two tight sentences, action first, the coordinate convention second. No filler and nothing buried.

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

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

For a mutation tool with no annotations, no output schema, and five undocumented parameters, the description leaves real gaps: the meaning and units of 'ut', sign conventions, and whether the node is added alongside existing nodes. It covers the confirmation requirement and delta-v frame but not the full call contract.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully fixes the coordinate convention (radial-plus, normal-plus, prograde) and units (m/s) for three of the five parameters, but says nothing about 'ut' (epoch/units) or the required 'confirm' flag beyond the passing phrase 'after explicit confirmation.'

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

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

States a specific verb and resource: 'Create one native KSP patched-conic maneuver node.' This distinguishes it from ksp_flight_maneuver_nodes (list), ksp_flight_clear_maneuver_nodes (remove), and ksp_flight_maneuver_burn_start (execute), though it does not name those siblings explicitly.

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

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

The only usage constraint given is 'after explicit confirmation,' which is an operational gate rather than when-to-use guidance. Nothing says when to place a node versus using ksp_flight_transfer_plan or executing an existing burn, nor what the preconditions are.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the prerequisite that data comes 'from the running KSP instance' and the verb 'Read' establishes it as a non-mutating operation, but it says nothing about failure modes, return format, or how data is scoped.

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

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

A single front-loaded sentence beginning with the verb, with no wasted filler. The enumeration of data categories is dense but useful rather than padding.

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

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

With no output schema, no annotations, and an undocumented parameter, the description only partially compensates: it sketches the returned data categories but omits any explanation of the 'query' parameter and omits error/availability behavior.

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

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

The single 'query' parameter has 0% schema description coverage, so the description must compensate, yet it never mentions the parameter at all. The agent cannot tell what 'query' filters or its expected syntax.

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

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

States a specific verb ('Read') and resource ('celestial-body radii, gravitational parameters, atmospheres, spheres of influence, and patched-conic orbit data'), which is far more concrete than a generic 'get data'. No sibling tool covers celestial bodies, so it is effectively distinguished, though it never names an alternative explicitly.

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

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

There is no when-to-use, when-not-to-use, or alternative guidance whatsoever. The description only enumerates the data categories returned, leaving the agent to infer that this tool is for looking up body/orbit constants.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the key effect (control returns to player/KSP input), which is the important side effect for a lease-release tool. However, it does not say whether releasing a non-held lease errors, whether other flight operations must be stopped first, or the return payload.

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

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

A single, front-loaded sentence with the action and outcome stated immediately. No filler or repetition.

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

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

For a zero-parameter, no-output-schema teardown tool, the description covers the essential action and its effect. Only edge-case behavior (calling when no lease is held) is left unaddressed.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate.

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

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

States a specific verb ('Release') and a specific resource ('the MCP fly-by-wire control lease'), plus the resulting effect ('return control to KSP/player input'). It is distinguishable from siblings like ksp_flight_set_controls or ksp_flight_abort, though it never explicitly names those alternatives.

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

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

Usage is only implied: you call this when you are done with programmatic fly-by-wire control. There is no explicit when-to-use statement, no mention of where the lease is acquired (presumably ksp_flight_set_controls), and no note on how it relates to the guidance or maneuver siblings.

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

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

No annotations provided, so the description carries the burden. It discloses that removal happens only after explicit confirmation (a behavioral trait), but does not state whether removal is reversible, what happens to active burns, or what the return value is. Partial disclosure.

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

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

Extremely concise single sentence that front-loads the action, resource, and scope. No wasted words.

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

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

For a simple destructive action on one boolean parameter with no annotations and no output schema, the description covers the essential action but omits consequences (e.g., what 'native' means, irreversibility, effect on guidance). It's minimally viable but incomplete for a destructive 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?

One required boolean parameter 'confirm' with 0% schema description coverage. The description mentions 'explicit confirmation' which hints at the confirm parameter's purpose, but does not explain what setting confirm=false does or any other semantics. Minimal added meaning.

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

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

States a specific verb (Remove) and resource (all native KSP maneuver nodes) with clear scope. Distinguished from the sibling ksp_flight_maneuver_nodes (which presumably lists them) and ksp_flight_add_maneuver_node (which adds).

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

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

The phrase 'after explicit confirmation' implies a safety-related usage context, but no explicit when-to-use or when-not-to-use guidance is given, nor are alternatives named. Adequate minimum but with gaps.

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

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

Without annotations, the description carries the full burden and discloses several important behaviors: it continuously refreshes controls in KSP frames, owns the fly-by-wire lease, reports preflight/ignition/staging state, and requires confirm=true. It does not mention what happens on failure, lease conflicts, or how to stop the plan (though a sibling stop tool exists).

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

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

The description is two dense sentences that front-load the core action and key constraints. Every clause adds information; no filler.

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

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

For a 7-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It covers the main behavior and profile enum but leaves six parameters unexplained, fails to say how to stop or update the plan, and does not describe return values or state reporting format. A user cannot fully predict the tool's behavior from this description alone.

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

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

Schema description coverage is 0%, so the description must compensate. It lists the four profile enum values, but provides no meaning for confirm, auto_stage, max_seconds, target_altitude, target_apoapsis, or target_periapsis. The schema also has additionalProperties: true, and the description does not clarify whether extra parameters are accepted or how they are used.

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

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

The description states a specific verb (start) and resource (game-side closed-loop guidance plan) and names four profiles (ascent, orbit, landing, node_burn). This clearly distinguishes it from siblings like ksp_flight_guidance_status, ksp_flight_guidance_update, and ksp_flight_guidance_stop.

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

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

The description implies usage by listing profiles and noting it is controlled entirely through KSP state without screenshots, but it does not explicitly state when to use this tool versus alternatives like ksp_flight_maneuver_burn_start or ksp_flight_guidance_update. No exclusions or prerequisites are given.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether this requires an in-flight scene, whether a guidance profile must be loaded, rate limits, or whether it is purely side-effect free. Listing return fields offers a little value but is essentially restating output content rather than behavior, and no output schema exists to justify omitting return details.

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

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

A single sentence, no filler, front-loaded with the verb and resource. The laundry list of fields is somewhat dense but each item is a distinct output and earns its place given there is no output schema.

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

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

With no annotations and no output schema, the description is the only source of behavioral and return information. It covers what is returned reasonably well but omits prerequisites, scene requirements, and the distinction from the sibling update/start/stop guidance tools. Just adequate for a query tool in a complex flight-guidance family.

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

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

Zero parameters, so per the calibration baseline a 4 applies. The description correctly implies no arguments are needed by describing only outputs, matching the empty schema.

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

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

The description states a specific verb 'Read' and enumerates exactly which fields are returned — guidance profile, phase, target, control output, ignition hold, deorbit completion, preflight report, remaining time. That is a clear resource and scope. It does not explicitly distinguish itself from the sibling ksp_flight_guidance_update, but the verb 'Read' vs 'update' implies the read/query vs mutation split.

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?

There is no when-to-use guidance, no mention of alternatives like ksp_status or ksp_flight_state or ksp_flight_guidance_update, and no prerequisite context such as whether a guidance session must be active. The verb 'Read' is the only usage signal.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that MCP control is released and that the tool serves as a safety exit, which is useful context beyond the name. It does not say whether the guidance plan is discarded or resumable, whether the craft stays under manual control afterward, or how it behaves if no plan is active.

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, zero filler, with the action front-loaded and the usage conditions immediately after. Every clause earns its place.

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

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

For a zero-parameter, annotation-free stop tool, the description covers purpose, effect (control release), and trigger conditions adequately. The remaining gap is post-stop state and no-op/error behavior, which is minor here.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics for the description to add. Nothing is misstated or left ambiguous.

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

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

States a specific verb ('Stop') and resource ('the active closed-loop guidance plan') plus a second effect ('release MCP control'), so an agent knows exactly what it does and can tell it apart from ksp_flight_guidance_start. It does not, however, distinguish itself from adjacent siblings like ksp_flight_abort or ksp_flight_clear_control, which an agent might reasonably confuse it with.

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

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

Gives concrete triggering conditions: timeout, flameout, commandability loss, or explicit human takeover, framed as 'the AI safety exit'. That is real when-to-use guidance. It stops short of naming when NOT to use it or which sibling to prefer for abort/control-clear scenarios.

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

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

No annotations exist, so the description carries the full burden. It does disclose one real behavioral trait – the update is non-disruptive and preserves MCP control – but for a 9-parameter tool where every parameter is optional it never says whether omitted fields are preserved or reset, whether partial updates are permitted, or that an active plan is required. Those are the behaviors an agent most needs.

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

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

A single front-loaded sentence with no filler; the main purpose clause comes first and the secondary context second. It is efficient, though arguably too terse for the parameter surface it governs.

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

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

With no annotations, no output schema, nine undocumented parameters, and a stateful game-side guidance plan, the description is too thin. An agent cannot tell what happens to unspecified fields, what the update does to an in-progress plan, or what units the numeric parameters expect.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does not. It groups parameters into 'targets' (altitude/apoapsis/periapsis/latitude/longitude) and 'safety options' (gear, auto_stage, extend_seconds), but supplies no units, formats, or meaning for any of the nine fields.

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 gives a specific verb ('Update') and a specific resource ('targets and safety options on the active game-side guidance plan'), which distinguishes it from siblings like ksp_flight_guidance_start/stop/status. It stops short of explicitly naming those siblings or differentiating by scenario, so it lands at clear-but-not-routing.

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?

'Useful for a no-visual real-time mission loop' implies the operating context, and 'without releasing MCP control' hints that this is the in-place alternative to stopping and restarting guidance. However, no alternative tool is named and no when-not condition is given, so usage must be inferred.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the burn is 'confirmed, game-side', finite, aligns to the node burn vector, estimates duration, and exposes ignite/burn/complete phases via telemetry. However, it doesn't state side effects like fuel consumption, what happens on abort, or whether it locks controls.

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?

One dense, front-loaded sentence that efficiently packs the core operation, alignment, estimation, and telemetry phases. No wasted words.

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

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

Covers the high-level operation and telemetry phases but, lacking an output schema and annotations, it leaves behavioral details (permissions, side effects on abort, control locks) and all parameter semantics undocumented, making it only minimally complete for a 4-param mutation tool.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'confirmed' burn (likely the confirm param) but provides no explanation for throttle, node_index, or max_seconds, leaving three undocumented parameters. The schema only gives types and ranges, not meaning.

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

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

States a specific verb+resource: starting a finite-burn controller for a native KSP maneuver node, including alignment, duration estimation, and phase telemetry. It distinguishes itself from siblings like ksp_flight_guidance_start and ksp_flight_add_maneuver_node by focusing on executing a node burn, though it could more explicitly name the difference from ksp_flight_guidance_start.

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

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

The description implies usage (for a maneuver node burn) but doesn't say when to choose this over alternatives like ksp_flight_guidance_start or ksp_flight_set_controls, nor does it mention prerequisites such as requiring an existing node. No explicit when-not guidance.

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

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

No annotations are provided, so the description carries the burden, but it does signal a non-mutating read ('Read ... maneuver nodes'). It adds useful disclosure about what data is surfaced (delta-v, burn vector, timing, next-patch orbit), yet omits whether this requires an active flight scene, what happens with zero nodes, or the response shape.

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

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

A single front-loaded sentence with zero filler; the verb and resource lead and the payload details follow compactly.

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

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

For a zero-parameter read tool with no output schema, the description does the minimum-plus by enumerating the returned fields (delta-v, burn vector, timing, next-patch orbit). It would be stronger with a note about scene prerequisites or behavior when no nodes exist, but nothing critical is missing.

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

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

The tool takes no parameters, so the baseline is 4; the schema has no properties to misinterpret. The description correctly implies no inputs are needed to read the current node set.

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

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

States a specific verb (Read) and a precise resource (native KSP patched-conic maneuver nodes), and enumerates the data returned: node-coordinate delta-v, burn vector, timing, next-patch orbit. It does not, however, explicitly distinguish itself from siblings like ksp_flight_add_maneuver_node or ksp_flight_clear_maneuver_nodes, which operate on the same maneuver-node concept.

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?

There is no when-to-use guidance, no preconditions (e.g. must be in flight scene), and no routing to alternatives such as ksp_flight_transfer_plan or ksp_flight_add_maneuver_node. The agent must infer usage entirely from the read semantics and the name.

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

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

No annotations are provided, so the description carries the full burden. It discloses useful behavior (checks active body, performs deorbit and powered descent, auto-stages/ignites engines, exposes height_agl and touchdown events) and a safety gate (confirm=true). However, it omits key traits: what happens on failure, whether it's abortable, permissions/side effects, and the max_seconds timeout behavior.

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

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

Single dense sentence front-loads the action and condition, with no wasted words. It is appropriately sized, though cramming many behaviors into one sentence slightly reduces readability.

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 an 8-parameter, no-annotation, no-output-schema tool, the description should do more. It covers the core what/when and required confirm, but leaves most parameters undocumented and omits output/event details beyond naming height_agl and touchdown events. Adequate but with clear gaps.

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

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

Schema description coverage is only 13%, so the description must compensate for seven undocumented parameters. It mentions only 'confirm=true' and implicitly 'auto_stage' via 'automatically stages/ignites', leaving deploy_gear, max_seconds, target_latitude/longitude, and gear_deploy_altitude unmentioned and thus semantically opaque to the agent.

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

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

States a specific verb ('start') and a specific resource ('game-side Mun powered-descent controller'), with clear conditions ('after the vessel is at Mun'). Distinguishes itself from siblings like ksp_moon_landing_plan (planning) and ksp_flight_guidance_start (generic guidance) by its Mun-specific descent scope, though it doesn't name those alternatives explicitly.

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

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

Gives one clear precondition ('after the vessel is at Mun') and notes confirm=true is required, but does not say when NOT to use it or how it relates to alternatives like ksp_moon_landing_plan or ksp_flight_guidance_start. Usage is implied by the precondition rather than fully guided.

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

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

With no annotations and no output schema, the description carries the full disclosure burden. 'Request' hints the operation may be refused and 'when KSP allows it' hints at a state-dependent precondition, but neither is specified, and nothing is said about whether the flight is terminated, what scene results, or whether the action is reversible.

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

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

A single compact sentence with the resource front-loaded and no filler. It is under-specified rather than verbose, but structurally it is efficient.

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

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

For a stateful, potentially irreversible game action with no annotations and no output schema, the definition is too thin: it never explains the 'when KSP allows it' precondition, the result of the call, or how it differs from revert/return-to-editor behavior.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; baseline 4 applies. The empty schema is consistent with the description.

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

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

States a specific verb+resource: recovering/reverting the current flight. However it conflates two distinct operations ('recovery' vs 'revert') and does not distinguish this tool from overlapping siblings like ksp_flight_return_to_editor or ksp_flight_abort.

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?

'When KSP allows it' gestures at a precondition but never says what those conditions are, nor does it name the alternative tools an agent should consider. No explicit when-to-use or when-not-to-use guidance is given.

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

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

With no annotations, the description carries the full burden. It does disclose meaningful behavior: the transition uses the native FlightDriver path rather than visual UI automation, implying a reliable internal call. It does not say what happens to the in-flight vessel (preserved, reverted, destroyed) or whether the action requires a save or specific scene state.

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

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

A single front-loaded sentence with the action first and the mechanism qualifier second. Nothing is wasted, though the 'without visual UI automation' clause is somewhat of a reassurance rather than an operational instruction.

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 one-optional-parameter scene-transition tool with no annotations and no output schema, the description covers the action and mechanism but omits the default behavior when editor_mode is absent and the fate of the current flight. These are the two gaps an agent would most want closed.

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

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

Schema coverage is 0% and editor_mode is optional, yet the description only echoes the enum values ('VAB or SPH') without adding meaning. Critically, it never says what happens when editor_mode is omitted, which is the key ambiguity for an optional parameter with no schema documentation.

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

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

States a specific verb+resource+scope: return from flight to the VAB or SPH editor. It also identifies the mechanism ('KSP's native FlightDriver path'), which separates it from any UI-automation route. It stops short of naming the sibling it is distinct from (e.g., ksp_editor_enter), so sibling differentiation is left implicit.

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

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

The phrase 'from the current flight' implies the precondition that the game must be in flight, which is real usage context. However, it never states when to use this versus ksp_editor_enter or other editor-transition tools, and gives no exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full behavioral burden. It introduces the key concept of a 'short-lived lease,' but never explains what the lease means in practice—duration semantics, whether it auto-expires, how it interacts with ksp_flight_clear_control, or what happens if controls are set without renewal. For a 13-parameter flight-control tool this is a large disclosure gap.

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

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

A single efficient sentence with no redundancy and the action front-loaded. It is not padded, though it is arguably too terse for the tool's complexity.

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

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

For a 13-parameter tool with zero schema coverage, no annotations, and no output schema, the description is insufficient. It leaves key mechanics—lease duration, expiry behavior, defaults for the many optional axes—completely unexplained.

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

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

Schema description coverage is 0%, so the description must compensate for all 13 undocumented parameters. It names the control axes (throttle, pitch, yaw, roll, translation, wheels, gear, brakes, lights), providing only a loose mapping, and omits lease_seconds entirely along with any value ranges or units.

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

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

The description gives a specific verb (Set) and resource (fly-by-wire control lease) and enumerates the control axes affected, so an agent can tell roughly what it does. It stops short of distinguishing itself from sibling setters like ksp_flight_set_sas or ksp_flight_set_rcs, which also configure flight controls.

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?

There is no guidance on when to use this versus alternatives such as ksp_flight_set_sas, ksp_flight_set_rcs, or ksp_flight_clear_control, nor any prerequisite (e.g., must be in flight). Usage must be inferred entirely from the name and 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?

No annotations are provided, so the description must carry the behavioral load. It discloses the mutation (toggling RCS) and the scope (active vessel), but omits whether this requires flight scene, whether it's reversible, side effects, or return behavior. Adequate but incomplete.

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

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

A single efficient sentence that front-loads the action and includes the scope. No waste.

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 toggle tool with one boolean parameter, the description is minimally complete. However, with no annotations and no output schema, it could usefully state prerequisites (e.g., must be in flight scene) or side effects (e.g., affects the active vessel only).

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

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

Schema coverage is 0% and the description doesn't explain the 'enabled' boolean. However, the parameter name is self-explanatory and there is only one parameter, so the baseline of 3 is appropriate for a single obvious 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?

States a specific verb (Enable or disable) and resource (stock RCS) via the active vessel action group. Clear and distinct from siblings like ksp_flight_set_sas and ksp_flight_set_controls, though it doesn't name those alternatives.

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

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

Implies usage context (active vessel, action group) but provides no explicit when-to-use guidance, prerequisites, or differentiation from related control tools like ksp_flight_set_controls or ksp_flight_clear_control.

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

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

No annotations are provided, so the description carries the full burden. It indicates a state-changing action (enable/disable) but doesn't disclose whether the change is immediate, whether it requires specific vessel conditions, or what happens if the vessel lacks SAS capability.

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

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

A single, clear sentence with no wasted words. It front-loads the action and resource, making it easy to parse quickly.

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

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

For a mutation tool with no annotations and no output schema, the description is too sparse. It omits essential context like scene requirements, potential side effects, and error conditions, leaving an agent under-informed.

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 one required parameter and 0% schema description coverage, the description only implies that 'enabled' controls the on/off state. It does not clarify the type, default, or any constraints, adding minimal value beyond the parameter name.

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

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

States a specific verb and resource: enable/disable stock SAS on the active vessel. It's clearly distinguished from sibling tools like ksp_flight_set_rcs and ksp_flight_set_controls, which handle different control systems.

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

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

The description states what the tool does but provides no guidance on when to use it versus alternatives, no prerequisites (e.g., must be in flight scene), and no mention of what happens if the vessel doesn't support SAS.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing: it does not say the action consumes/advances a stage, whether it is reversible, what happens when no stages remain, or that it requires an active flight scene. 'Activate' implies a mutating, one-way operation but that is inference, not disclosure.

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

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

A single front-loaded sentence with zero waste. It is arguably too terse for the amount of undisclosed behavior, but as a matter of structure and economy it is clean.

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

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

For a zero-parameter action with no output schema and no annotations, the minimum viable content is present, but the irreversible/one-shot nature of staging and the flight-scene prerequisite are both absent. An agent can call it, but not confidently predict or recover from the result.

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

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

The tool takes zero parameters, so per the baseline there is nothing for the description to clarify. A 4 is the appropriate ceiling given the schema is empty and needs no compensation.

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

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

States a specific verb ('Activate') and a specific resource ('the next KSP staging step'), so the agent knows exactly what the call does. It does not, however, distinguish itself from adjacent siblings such as ksp_flight_activate_part or ksp_editor_set_stage, which is the gap that keeps it off a 5.

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

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

There is no when-to-use guidance, no statement of prerequisites (e.g. must be in the flight scene), and no reference to alternatives like ksp_flight_activate_part or the editor-side staging tools. The flight-prefixed name is the only signal that this is the in-flight staging action.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It implies a read operation but offers no detail on freshness, rate limits, scope, or return format, and it does not state that it is non-destructive or safe to poll.

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

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

A single, efficient sentence lists the telemetry domains front-loaded and without filler. It is appropriately sized, though more structure or a brief clarification of scope would help.

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 a zero-param telemetry reader with no annotations, no output schema, and many overlapping sibling status tools, the description is too thin. It does not clarify what distinguishes it from ksp_status or ksp_flight_guidance_status, nor does it describe the return shape, leaving the agent under-informed.

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

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

The tool takes zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, though it could clarify that no inputs are required.

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

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

The description states a read of a specific resource (active-vessel telemetry, resources, engines, stage, controls, orbital values), so the purpose is clear. However, it does not differentiate from siblings like ksp_status or ksp_flight_guidance_status, which likely provide overlapping state data, leaving ambiguity about which telemetry reader to use.

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

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

No guidance is given about when to call this tool versus alternatives such as ksp_status or ksp_flight_guidance_status. An agent must infer usage from the name and sibling list alone.

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

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

With no annotations provided, the description carries the full burden, and it does disclose the key safety trait: read-only and non-executing, which is the most important behavioral fact for a planning tool. However, it omits other relevant behavior: that the estimate assumes circular coplanar orbits (therefore inapplicable to eccentric/inclined transfers), whether it reads the current vessel state, and any error conditions.

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 tightly written sentences with no filler; the operation and the read-only guarantee are both front-loaded and each clause earns its place.

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

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

For a 5-parameter tool with zero schema coverage, no annotations, and no output schema, the description should explain units, defaults, and what the estimate returns. Instead it covers roughly two parameters and leaves the rest of the invocation contract unstated.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate, and it only partially does: it implies origin_body defaults to the active vessel's body and clarifies destination_body. It says nothing about direction (the prograde-only enum), target_altitude_m, or parking_altitude_m — units, defaults, or meaning — leaving three parameters undocumented in both places.

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 gives a specific verb ('Calculate') and a precisely scoped resource ('transparent circular-coplanar Hohmann estimate from the active vessel's body to a destination body'), which clearly separates it from the burn-executing siblings like ksp_flight_maneuver_burn_start. It does not explicitly name a sibling alternative, but the purpose is unambiguous on its own.

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

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

Usage is implied rather than stated: the reader infers this is a pre-burn planning/estimation step, and the closing clause ('does not create or execute a burn') hints at the boundary with ksp_flight_add_maneuver_node and burn-start tools. There is no explicit when-to-use statement, prerequisite list, or named alternative.

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

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

With no annotations, the description carries the full burden. It discloses one important, non-obvious behavior — rejection during an active AI guidance plan — and explains why. However, it doesn't cover what happens on success, whether the change persists across scenes, or the meaning of the accepted range, leaving meaningful behavioral gaps.

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

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

Two sentences, action front-loaded ahead of the constraint. The trailing rationale ('because KSP can advance orbital state without running a reliable fly-by-wire callback for every physics step') is somewhat elaborate for an agent but still earns its place by explaining the restriction.

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 tool with no output schema, the description covers the action and one key constraint. It remains incomplete on the most important detail — what the index values other than zero actually select — which an agent needs to call it correctly.

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

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

Schema coverage is 0%, so the description must compensate. It only clarifies that rate index zero means real time; the mapping of indices 1-20 to actual warp factors (and why 20 is the maximum) is never explained, so it only partially fills the documentation gap.

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

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

States a clear verb+resource: 'Set the stock time-warp rate index.' An agent immediately knows it controls KSP time warp. It does not explicitly differentiate from any sibling, but no sibling overlaps this function, so the gap is minor.

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

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

Gives a concrete when-not condition: time warp is rejected while a no-visual AI guidance plan is active, with only zero (real time) permitted. This is a real constraint that shapes invocation, though no general 'use this to speed up coasting phases' guidance or named alternative is offered.

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

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

With no annotations provided, the description carries the full burden, and it does add real behavioral context: 'read-only' and 'needs no visual UI' tell the agent this is a safe, headless query. However, it says nothing about the return shape (folder names? paths? metadata?) or whether results can be stale, which matters for a discovery tool with no 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?

A single front-loaded sentence with no padding; the resource, scope, and safety profile all appear in one pass and every clause earns its place.

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

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

For a simple zero-parameter list tool the description is broadly adequate, but with no output schema and no annotations, it should say what the listed saves look like or how they map to load arguments. The safety note is a plus, yet the return-value gap leaves the agent inferring 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?

The tool takes zero parameters, which is the baseline-4 case per the rubric; there are no parameter semantics to clarify and the description does not introduce confusion about inputs.

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

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

States a specific verb (List) and resource (real KSP save folders) with a scoping qualifier ('that can be loaded through the bridge') that distinguishes it from generic folder listing. It does not explicitly name the sibling ksp_game_load_save it feeds into, so it falls short of full sibling differentiation.

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

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

The phrase 'that can be loaded through the bridge' implies this is a discovery step before ksp_game_load_save, but the description never states when to use this versus the alternative or any prerequisite ordering. Usage is only implied.

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

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

No annotations are provided, so the description carries full burden. It leaves the mutation semantics vague: does it overwrite current game state, require KSP to be running, block until loaded, or fail if already in a scene? For a load/mutation tool with zero annotation coverage this is a significant gap.

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

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

One sentence, front-loaded with the action, with no filler. It is tight, though the phrase 'avoiding title-screen Computer Use' is slightly cryptic jargon for an external agent.

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

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

For a stateful game-loading tool with no annotations, no output schema, and undocumented parameters, the description omits prerequisites (KSP running), blocking behavior, failure modes, and return value. The sibling tool names suggest a coordinated workflow that this description does not acknowledge.

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

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

Schema description coverage is 0% for the single required parameter save_folder. The description mentions 'save' but gives no format, whether it is a folder name vs path, or where saves live; the agent must guess. A brief example (e.g. 'folder name under KSP/saves') would have closed the gap.

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

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

States a specific verb+resource: load a KSP save via GamePersistence and enter the Space Center scene. Clearly distinguishable from ksp_editor_load (craft loading) and ksp_game_list_saves (enumeration), and the 'real' qualifier plus the save-folder param disambiguate it from listing tools.

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

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

The trailing clause 'avoiding title-screen Computer Use' hints at when this is preferred over manual UI navigation, but it never states preconditions, what happens if the game is already in-flight, or which alternatives (e.g. ksp_wait_for_scene, ksp_game_list_saves) pair with it.

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

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

With no annotations, the description carries the full burden, and it does disclose the key trait that this is a side-effect-free read that creates no node and performs no burn. However, it says nothing about prerequisites (must you be in flight?), what the estimate actually contains, or whether the result is a snapshot versus a running plan — meaningful gaps for a no-annotation tool.

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

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

Two tight, front-loaded sentences with no filler; the core action leads and the read-only caveat follows. Efficient, though it spends its brevity on caveats rather than the missing parameter/usage detail.

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

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

For a 5-parameter tool with no output schema and no annotations, the description is too thin: it neither explains the return estimate's contents nor the meaning of four undocumented parameters. What an agent needs to invoke it correctly is largely absent.

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

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

Schema description coverage is only 20% (just target_body = "Defaults to Mun."), leaving landing_latitude, landing_longitude, target_altitude_m, and parking_altitude_m undocumented anywhere. The description mentions "current-body-to-moon" generically but adds no units, defaults, or meaning for the four undocumented coordinates/altitudes, so it fails to compensate for the low 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 gives a specific verb ("Read") and resource (a live-data transfer estimate plus soft-landing handoff), and the read-only/no-burn clause implicitly separates it from siblings like ksp_flight_moon_soft_landing_start and ksp_flight_add_maneuver_node. The jargon "no-visual soft-landing handoff" is a bit opaque, and it never names the siblings it is distinct from, so it lands at a clear-but-not-disambiguating 4.

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

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

Usage is only implied: the read-only framing suggests it's a query/preparation step, but there is no explicit when-to-use statement and no alternatives named (e.g., versus ksp_flight_transfer_plan for non-landing transfers). The agent has to infer the scenario from the KSP domain context.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a safe read, but nothing is said about pagination, result size, whether limit truncates silently, or what the query actually filters on. With three undocumented parameters this is a significant gap.

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

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

A single front-loaded sentence with no waste and the scope qualifier placed immediately after the core action. It is efficient, though its brevity is partly the source of the coverage gaps.

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

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

For a tool with three undocumented parameters, no annotations, and no output schema, the agent cannot tell what limit/query do or what the returned part records contain. The description names the resource but leaves invocation details and return content unresolved.

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

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

Schema description coverage is 0%, so the description must compensate and largely does not. Only include_modules gets indirect support via 'including ... modules'; limit and query are left completely unexplained in both schema and description.

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

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

States a specific verb and resource ('List the actual parts loaded by the running KSP instance') and clarifies scope by noting attachment nodes and modules are included. It distinguishes itself from the many editor/flight mutation siblings by being a read of the live runtime part set, though it never explicitly names a contrasting tool.

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

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

No indication of when to call this versus alternatives such as ksp_flight_state, ksp_realtime_state, or the editor part tools. The 'running KSP instance' phrasing implies a live-flight context but no requirement, prerequisite, or exclusion is stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that data is cached, compact, and non-visual, that events are incremental, and how to recover from truncation via next_since, but it omits permission/auth requirements, whether wait_ms blocks, and caching/staleness implications of 'cached'.

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 tight sentences: purpose first, then routing and operational directives, with zero filler. Every clause conveys actionable 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?

There is no output schema and no annotations, so the description should be carrying more weight than it does. It gives a good conceptual model of the return (cached, compact, non-visual, incremental) but leaves four of five parameters undocumented and does not describe the shape of the returned telemetry or event stream.

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 only 20% (only 'sections' is documented in the schema), so the description must compensate but does not. It never explains limit, since, wait_ms, or include_events; it references next_since and height_agl, which are not parameter names at all, risking confusion with the actual 'since' 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?

States a specific verb and resource (read compact cached telemetry and incremental KSP events) and explicitly distinguishes itself from the sibling ksp_status ('Prefer this over ksp_status while building or flying'). An agent can identify what this returns and how it differs from the main status tool without opening either schema.

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

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

Names the alternative (ksp_status) and the condition that selects this one ('while building or flying'), plus concrete operational directives for height_agl and truncated events via next_since. It does not state when NOT to use it or cover the other polling siblings (ksp_watch, ksp_wait_for_event), so it falls short of full when/when-not guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that construction is live and emits per-part events, and that the result is modular, which is useful. But it omits critical mutation details: does it alter the current craft? Are there side effects or performance considerations? Not enough for a write operation with zero annotation support.

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

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

Three focused sentences: purpose, modularity benefit, and live event behavior. No fluff and well front-loaded, though it could be slightly tighter.

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

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

For a 7-parameter mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain parameters, return behavior, or how the generated station interacts with existing editor content, leaving the agent under-informed for correct invocation.

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

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

Schema description coverage is 0%, meaning all 7 parameters are undocumented in the schema. The description does not explain any parameter's meaning or effect, leaving the agent to guess the semantics of 'live', 'pace', 'template', 'parts_per_frame', 'require_connected', and 'wait_for_completion'. This is a significant gap.

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

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

The description clearly states it generates and builds a connected stock orbital-station core in the VAB, distinguishing it from generic part-assembly tools by its station-core scope. It does not explicitly contrast with siblings like ksp_editor_add_part, but the dedicated station-building purpose is unambiguous.

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

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

Usage is implied by the description: use this to create a modular station core. However, it gives no guidance on when to use this versus manually building a station with editor tools or other builders, nor any prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the burden, but it is a parameterless read, so the risk surface is small. The description does disclose the content set it returns, which is useful, but says nothing about whether calls are cached, how expensive they are, or whether fields are absent when not in flight or not in the editor.

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

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

A single compact sentence that front-loads the verb and then lists the payload. Nothing is padded, though the comma-chained noun list is dense and could have been grouped more legibly (e.g., scene/editor vs. flight telemetry vs. bridge metadata).

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

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

With no output schema, the description must convey what comes back, and it does enumerate the return categories, which is the key information for an agent deciding whether to call it. It stops short of describing field-level detail or the shape of the 'compact flight telemetry', but for a zero-parameter read tool this is close to sufficient.

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

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

The tool takes zero parameters (schema has an empty properties object), so there is nothing for the description to clarify and the baseline is 4. No parameter-level claims are made that could mislead.

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?

Uses a specific verb ('Read') and enumerates the five concrete resources returned: current scene, editor craft summary, compact flight telemetry, no-visual control capabilities, and bridge version. This is far more than a restatement of the name. However, it never distinguishes itself from closely overlapping siblings such as ksp_flight_state or ksp_realtime_state, so an agent cannot tell from the description alone why it should pick this aggregator.

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?

There is no when-to-use guidance, no mention of when this is preferable to ksp_flight_state, ksp_realtime_state, or ksp_watch, and no prerequisites. The breadth of the tool (scene + editor + flight + capabilities + version) arguably makes it a good first probe, but that intent is left entirely to inference.

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

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

With no annotations, the description carries the full burden. It usefully discloses the core blocking/return semantics ('return immediately when the event cursor advances'), which is the central behavioral trait. It says nothing about timeout behavior, what happens if no event arrives, polling cost, or cursor resumption, which are critical for a wait primitive.

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

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

A single well-formed sentence that front-loads the verb and return condition before the elaboration clause. Efficient, though the trailing rationale clause is longer than strictly needed.

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?

A 6-parameter, zero-annotation, no-output-schema tool needs far more than this description provides. The agent is not told what the return payload looks like (events? cursor? state?), how timeout interacts with return, or the meaning of most parameters, leaving it under-specified for correct invocation.

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

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

Schema coverage is only 17% (only 'sections' is documented) across 6 parameters, so the description must compensate but does not. 'Cursor advances' loosely hints at the resume semantics of the 'since' parameter, but limit, timeout, poll_interval, and include_events are left entirely unexplained.

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

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

States a specific verb (wait) and resource (next KSP telemetry event) and explains the return condition (cursor advances). It also characterizes itself as the event-driven primitive for observing scene/state changes, which partially distinguishes it, but it never names an alternative sibling like ksp_wait_for_scene or ksp_watch.

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

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

Usage is implied by the phrase 'primary event-driven primitive for an AI without vision to observe construction, ignition, staging, orbit crossings, and touchdown,' which gives a sense of the context. However, no explicit when-to-use/when-not guidance is given, and the closely related siblings (ksp_wait_for_scene, ksp_watch) are never mentioned as alternatives or compared.

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

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

No annotations are provided, so the description carries the full burden. It implies blocking behavior by saying 'wait until', but does not disclose what happens on timeout, whether the call blocks indefinitely, error conditions, or any permission/auth requirements.

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, front-loaded sentence with no wasted words. It immediately states the action and the key resource, which is appropriate for such a simple tool.

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 wait tool with no annotations, no output schema, and 0% schema coverage, the description is too sparse. It does not explain valid scene values, timeout semantics, blocking behavior, or how to detect timeout versus success.

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

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

Schema description coverage is 0%, so the description must compensate. It gives examples for the required scene parameter (EDITOR, FLIGHT) but does not enumerate valid scenes or explain the optional timeout parameter, leaving a substantial gap for both 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 states a specific verb and resource: wait until KSP reaches a requested scene, with examples EDITOR and FLIGHT. This clearly separates it from most flight-control siblings, though it does not explicitly contrast with ksp_wait_for_event, which is the nearest sibling.

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

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

There is no explicit when-to-use guidance, no mention of alternatives such as ksp_wait_for_event, ksp_status, or ksp_realtime_state, and no exclusions. The intended usage is only implied by the tool name and description.

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

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

With no annotations, the description carries the full load. It usefully discloses failure semantics ('Treat timeout, flameout, commandability loss, and vessel loss as explicit failures'), which is real behavioral value. But it says nothing about what the sampling returns, whether it is polled or blocking, or any limits, leaving significant gaps for a 7-param tool.

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

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

Two sentences, no filler, purpose stated first. Efficient and front-loaded, though the second sentence is a stand-alone rule rather than an integrated usage hint.

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

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

For a tool with 7 largely undocumented parameters and no output schema, the description should explain what telemetry is returned and how the sampling controls shape it. It covers failure handling but leaves parameter behavior and return shape entirely unaddressed.

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

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

Schema description coverage is only 14% across 7 parameters (only 'sections' is annotated). The description never mentions since, duration, interval, event_limit, max_samples, or include_events, offering only the vague phrase 'bounded interval' that hints at two of them. It does not compensate for the coverage gap.

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

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

The description gives a specific verb+resource ('Sample compact telemetry') and a scope ('for a bounded interval'), which is clear on its own. It does not, however, differentiate itself from siblings like ksp_status, ksp_flight_state, or ksp_realtime_state that plausibly return overlapping state information.

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

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

It gestures at intent ('so a model without vision can observe construction, staging, ascent, orbit, or landing') but never states when to choose this over ksp_realtime_state, ksp_flight_state, or ksp_wait_for_event. No prerequisites, no exclusions, no alternative routing.

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