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

With no annotations, the description carries the burden and does well: it discloses the return shape (findings with severity 'fault', component, measurement, tolerance) and the bounding-box output, which is exactly the behavioral context an agent needs. It omits whether the check is read-only (implied), how long it takes, or whether it mutates session state, so not fully complete.

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

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

Front-loaded with purpose, then return content, then the usage constraint in three compact sentences. Nothing is wasted and the agent can act on the first clause alone.

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, but the description still explains what comes back (findings plus per-component bounding boxes), satisfying the return-value burden. Combined with the explicit sequencing hint, the definition is nearly complete for a one-parameter validation tool; the only gap is the undocumented session_id.

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

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

The schema has 0% description coverage and the description never mentions session_id. With only one required, self-evident parameter (session_id), the gap is small, but the description adds no meaning beyond the schema.

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

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

States a specific verb and resource ('Check the aircraft's geometry ... against the file') and enumerates concrete fault classes (one-sided wing, wing not touching fuselage, impossible reference area) that no sibling tool covers. An agent can distinguish this validation tool from get_configuration_summary or list_geometric_components at a glance.

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?

'Run it after opening a file and before meshing' gives explicit sequencing relative to open_cpacs and export_component_mesh. It doesn't name an alternative tool or state when not to run it, so it stops short of full routing 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 disclosure burden. 'Free resources' hints at cleanup, but it does not say whether the session_id becomes invalid, whether the call is idempotent, what error occurs for an unknown/already-closed session, or whether in-flight work is discarded — significant gaps for a state-tearing 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 the action front-loaded and no filler. It is efficient, though its brevity is partly the cause of the missing behavioral detail rather than a sign of completeness.

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 state-changing teardown tool with no annotations, no output schema, and an undocumented required parameter, the description should cover post-conditions and error behavior. It does not, so an agent cannot predict the result of calling it on a stale or invalid session.

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 description never mentions session_id, its expected format, or whether it must reference a currently open session. With one required, wholly undocumented parameter, the description adds nothing beyond the schema's bare type declaration.

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 ('Close') and resource ('CPACS session'), which pairs cleanly against the sibling open_cpacs and separates it from read/query siblings like get_configuration_summary. The added 'free resources' clarifies the effect but no further scope detail.

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 guidance on when to close versus when to leave a session open, whether closing is required before process exit, or what to do if the session is already closed. The only hint is the implied lifecycle pairing with open_cpacs, which the agent must infer from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It reveals only that output is base64-encoded; it says nothing about required session state, permissions, failure modes for unsupported formats, or whether the operation is read-only or has side effects.

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

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

It is a single waste-free sentence, front-loaded with the verb and resource. However, for a four-parameter export tool it is arguably undersized rather than appropriately sized, leaving no room for the context an agent needs.

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 across four parameters, the description is far too thin. An agent cannot tell how to populate meshing_options, what the formats imply, or what conditions must hold before export succeeds.

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 should compensate but mentions none of the four parameters. In particular 'meshing_options' (an arbitrary numeric map with null default) and the meaning of 'session_id' versus 'component_uid' are 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?

The description uses a clear verb+resource pairing ("Export a component mesh") and adds the output form (base64-encoded content). The resource distinguishes it implicitly from siblings like export_configuration_cad, 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 guidance on when to use this tool versus export_configuration_cad or the other export/list siblings, and no stated prerequisites such as whether a mesh must already exist or whether a session must be open.

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 that a file is written and that the path is returned as cad_path, which is useful mutation context. It omits overwrite behavior for output_path, permission/session requirements, format defaults, and any size/pagination concerns.

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 tight sentences, front-loaded with the action and scope, then upstream/downstream linking, then the optional flag. 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?

It covers the return value well (cad_path) despite no output schema, and links to the downstream tool. But for a 5-parameter file-writing tool with zero schema documentation, the unexplained output_path and session_id leave real 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% across 5 parameters, so the description must compensate. It explains component_uid and include_base64 meaningfully, but leaves output_path (where the file lands, overwrite semantics) and session_id unexplained, and only the enum values hint at format.

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 (export configuration CAD) and clarifies scope: full configuration vs. a single component when component_uid is set. It does not, however, distinguish itself from the sibling export_component_mesh, which an agent could plausibly confuse with this 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?

Gives concrete downstream wiring — pass cad_path to su2_generate_mesh_from_step as step_path — and a conditional rule for include_base64 (only when file content itself is needed). No explicit when-not or sibling alternative is offered, but the intended workflow is clear.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation but does not state whether errors are returned for invalid sessions/components, what metadata fields are included, or any required authorisation or lifecycle context.

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

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

A single front-loaded sentence with no wasted words. The brevity is appropriate for structure, though it reflects under-specification rather than deliberate concision.

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 explain what metadata is returned and what the parameters mean. It does neither, making it inadequate for an agent to call this tool confidently.

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 both parameters are undocumented in the schema. The description does nothing to explain 'session_id' (session context) or 'component_uid' (component identifier), leaving parameter meaning entirely to inference.

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 ('Return metadata for a geometric component'), so the basic action is clear. However, 'metadata' is vague and the description does not distinguish this from sibling tools like get_high_level_parameters, get_configuration_summary, or list_geometric_components.

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, no preconditions, and no exclusions. The agent must infer usage from the tool 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 carries the full burden. It implies a read but doesn't state that it is non-mutating, doesn't mention the session prerequisite/ownership, doesn't describe failure modes (e.g., invalid or closed session), and doesn't mention what happens if no geometry 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?

One short, front-loaded sentence with no padding, but the conciseness comes at the cost of under-specification rather than economy; there is room to add essential routing and session context without bloat.

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 session-scoped aggregation tool with no annotations, no output schema, and an undocumented required parameter. The description never explains the return shape beyond 'component lists and bounding box', so an agent has no basis to know what fields to expect or how to handle an empty session.

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 session_id is described nowhere — the description says nothing about where the session comes from or what a valid session id looks like. With a required param that must be supplied correctly, the description should compensate but does not.

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 verb and partial resource: it returns 'component lists and the overall bounding box'. However, it never says what a 'configuration' is, and it overlaps visibly with the sibling list_geometric_components without distinguishing itself — an agent cannot tell which one to use to enumerate components.

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 routing at all. Given siblings like list_geometric_components, get_component_metadata, and get_high_level_parameters, the absence of any disambiguation guidance 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. Beyond implying a read ('Return'), it says nothing about session requirements, whether the operation fails for missing components, what shape the returned parameters take, or any side effects.

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

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

A single short sentence with the key noun front-loaded after the verb; there is no filler. Its brevity is more under-specification than verbosity, 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?

This is a simple 2-parameter read with no output schema. The description states the resource clearly but leaves both required parameters undocumented and gives no information about what is returned. Given the simplicity, that is a moderate gap rather than a fatal one.

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 schema description coverage at 0%, the description must explain session_id and component_uid, but it adds no meaning at all for either. An agent can only guess that component_uid identifies the target component and session_id refers to an open CPACS session.

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 ('Return') and resource ('high-level design parameters') scoped to 'a component', so the operation itself is unambiguous. It does not explicitly distinguish itself from near-neighbors like get_configuration_summary or get_component_metadata, which likely return different data for the same component.

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 its siblings (e.g. get_configuration_summary, get_component_metadata) or versus set_high_level_parameters. The only implied context is that a component must exist, and nothing about prerequisites 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. 'List' weakly implies a non-destructive read, but nothing is said about whether the session must be open first, whether results are paginated, or how type_filter affects the output.

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 with no wasted words, but the brevity reflects under-specification rather than efficient communication. It is front-loaded but says far too little for a two-parameter 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?

With no annotations, no output schema, and zero parameter descriptions, the definition provides almost nothing an agent needs beyond the name. A session-bound listing tool with a free-form type filter should at minimum explain the session lifecycle and the filter's accepted values.

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 both parameters. The description never mentions session_id (required, presumably a handle from open_cpacs) or type_filter, including what type values are valid — an enum is absent and no guidance is given, leaving the most important parameter 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?

The verb 'List' plus the specific resource 'CPACS geometric components' tells an agent exactly what the tool returns. It does not differentiate itself from siblings such as get_component_metadata or check_geometry, which operate on the same component set, so it stops short of a 5.

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

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

There is no statement of when to use this tool versus get_component_metadata or check_geometry, nor any prerequisite context. 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?

With no annotations at all, the description carries the full burden and discloses little: it doesn't say whether an already-open session is replaced or errors out, whether the file path must exist or the XML must validate, what side effects the call has, or what it returns. Only the accepted source forms are surfaced.

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 and no redundancy. It is efficient, though the brevity borders on under-specification for a stateful session-creation 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?

The tool is simple (2 required params, no nesting, no output schema), so a short description is defensible, but for a stateful opener with zero annotations the description should at least hint at the resulting session or the error/overwrite behavior. What is present covers inputs 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 description coverage is 0%, so the description has to compensate, and it partly does by explaining that the source may be either a file path or an XML string — which maps directly to the source_type enum (path | xml_string) and the source string. It stops short of stating explicitly that source_type selects how source is interpreted, or any format/validation expectations.

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 ('Open') plus resource ('CPACS session') and enumerates the two supported input forms, so the agent knows exactly what the tool establishes. It is clearly distinct from siblings like close_cpacs and get_configuration_summary, though it never names 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?

Usage is only implied: 'open a session' suggests it must be called before session-dependent tools and paired with close_cpacs, but the description never states prerequisites or when-not-to-use. There are no explicit alternatives or conditions spelled out.

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 the call is lightweight and independent of CPACS/TiGL runtime, but it does not explicitly state that it is read-only, idempotent, or side-effect free, leaving some safety assumptions to the agent.

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. The purpose and key prerequisite are stated immediately.

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 health-check tool with an output schema, the description covers the essential purpose and prerequisites. The main omission is any explanation of the optional 'message' parameter, and the lack of annotations leaves minor behavioral assumptions 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?

There is one optional parameter, 'message', with 0% schema description coverage. The description never mentions it, and the schema only provides a name and default, so the parameter's meaning and expected behavior are 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?

The description states a specific function — a health check confirming server reachability — and distinguishes it from all domain siblings by clarifying it needs no CPACS session or TiGL runtime. An agent can immediately tell this is the diagnostic/health endpoint rather than a geometry or configuration 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?

The terms 'health check' and 'without requiring a CPACS session' imply it can be used before opening a session, giving some usage context. However, it does not explicitly say when to use this versus doing nothing, nor does it name any alternative or exclusion.

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 usefully discloses the key non-obvious trait: this write does not propagate to CPACS geometry. It nonetheless omits whether 'updates' merges with or replaces existing values, whether unknown parameter names are accepted or rejected, and whether the change persists beyond the session.

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

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

Two sentences, front-loaded with the action and immediately followed by the most important caveat, with no filler. The parenthetical '(see applies_to_geometry)' is a dangling reference to a field not present anywhere in the schema, which slightly reduces clarity for the space it occupies.

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 three-parameter, no-output-schema, no-annotation write tool this is only partially sufficient: the geometry caveat is covered, but a caller still cannot tell what component_uid scopes, how updates are applied, or what (if anything) is returned on 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 explain all three parameters and does not. 'Session's parameter table' loosely maps to session_id, but component_uid's role is never mentioned and the nested 'updates' key/value structure (parameter name to number-or-string) is unexplained, leaving the most important parameter 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?

States a specific verb and resource: recording high-level design parameter values into a session parameter table. The set/get split is implicit rather than naming get_high_level_parameters explicitly, but the scoping sentence ('does NOT modify CPACS geometry') makes it clearly distinct from geometry-mutating siblings.

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

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

The description tells you the effect scope (CAD export and CFD keep the original shape), which implicitly tells an agent when this tool is appropriate versus a geometry-changing one. However it never explicitly states when to call it or which sibling to use instead when geometry changes are wanted — the '(see applies_to_geometry)' pointer refers to nothing in the schema.

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