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

Annotations provide no safety hints (readOnlyHint=false), so the description carries the burden. 'For display' suggests a non-destructive view operation, but it doesn't explicitly state that it doesn't modify the model, whether it hides non-activated elements, or if it's reversible. The effect on existing display state is unclear, which could mislead an agent expecting model changes.

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

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

The description is efficient and front-loaded with the core purpose, then documents arguments. The bilingual text is redundant but not harmful. No wasted sentences, though the Arg list could be integrated more cleanly.

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

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

For a simple tool with two optional parameters and no output schema, the description covers the basic mechanics. However, it lacks context about how activation interacts with the global display state (e.g., resets previous activations), whether deactivation is implied, and how to restore full display (e.g., reset_display). Given the large number of sibling display tools, this context would help correct usage.

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

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

Schema description coverage is 0%, so the description's 'Node IDs to activate' and 'Element IDs to activate' add minimal meaning. It explains what each parameter contains but doesn't clarify optionality, whether both can be used at once, or semantics of empty/null. This is marginal value beyond the schema's type hints.

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

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

The description clearly states the action (activate) and the resource (nodes/elements) and specifies the purpose (for display). It distinguishes from siblings that create or modify geometry, but doesn't explicitly name alternatives. It's specific enough that an agent can infer it's a display-filtering 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?

No guidance on when to use this tool versus display_ids, reset_display, switch_display_stage, or other display-related tools. It doesn't mention prerequisites, or whether it should be called before/after other operations. The tool's role in the display workflow is implied but not explained.

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

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

The description explains the meaning of True/False values and the DOF order [dx, dy, dz, rx, ry, rz], which goes beyond annotations. However, it does not disclose whether existing releases are overwritten, what null defaults for release_i/release_j mean behaviorally, or any side effects on the boundary group. Annotations are all default-false, so the description carries the transparency burden but only partially fulfills it.

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

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

The description is well-structured with a purpose statement, semantic bullets, args, and example, and it front-loads the core purpose. It is somewhat verbose due to full bilingual repetition of most content, but every section adds value and the structure helps an agent parse it 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 4-parameter tool with no output schema and minimal annotations, the description covers purpose, parameter meanings, and an example. However, it omits the behavior when release_i/release_j are null (the schema defaults), and it does not state that each release array must contain exactly six booleans. These gaps could lead to incorrect invocations, so it is not fully complete.

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

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

Schema description coverage is 0%, so the description must fully compensate. The Args section clearly documents all four parameters, explains the array structure of release_i and release_j with True=release semantics, and provides a concrete example showing how to release My at the I-end. This is exemplary parameter documentation given a bare schema.

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

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

The description opens with a specific verb+resource: 'Set beam end releases / constraints' and immediately clarifies it controls DOF releases at each beam end. This distinguishes it from generic constraint tools like add_constraint_equation or set_support, and the True/False semantics remove ambiguity about 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?

It provides clear usage context with 'Common use: releasing rotation at one end to create a pin connection' and implies beam-element-specific application. It does not explicitly name alternative tools or state when not to use it, so it falls short of a 5 but gives an agent enough context to select it appropriately.

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

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

Annotations indicate readOnly=false, so the agent can infer this is a mutating operation, but the description adds no further behavioral detail. It does not disclose whether applying this load overwrites existing beam section temperature loads, appends to them, or requires a specific model state.

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

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

The description uses one purpose line followed by a compact argument list with no filler. It is appropriately sized for a 10-parameter tool, though the purpose line is not elaborated with examples or constraints.

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 10-parameter mutation tool with no output schema and no detailed annotations, the description omits key context: what code_index values are valid, what t1–t4 physically represent, whether the load case and group must already exist, and how this tool differs from sibling temperature-load tools. An agent would struggle to invoke it correctly without external domain knowledge.

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

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

The input schema has 0% description coverage, and the description compensates by naming every parameter with a short English and Chinese gloss, e.g. 'sec_type: Section type (截面类型, 如1为箱梁等)'. However, several definitions are vague, such as 'Temperature difference param 1' and 'Thickness parameter', with no units, valid ranges, or relationship to section type.

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

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

The opening sentence 'Apply beam section temperature load' states a specific verb and resource, and the bilingual title adds precision. It is not a tautology and is distinguishable from gradient/system temperature loads by the phrase 'beam section', though it does not explicitly contrast with sibling tools.

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

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

No guidance is given on when to use this tool over siblings such as add_gradient_temperature, add_system_temperature, or add_custom_temperature. There are also no stated preconditions, such as whether the load case must already exist or how this load interacts with other temperature loads.

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 all annotations set to false, the description carries the full burden of behavioral disclosure, but it only states the operation without explaining side effects, whether the load replaces or adds to existing loads, required prior setup, or units. An agent cannot infer the behavioral impact beyond the bare word 'Apply'.

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 compact and front-loaded with the core action, followed by a brief argument list. It avoids unnecessary prose, though it could earn a 5 by including more semantic detail 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?

For a mutation tool with five parameters, no output schema, and no helpful annotations, the description is too thin. It omits prerequisites, units, default behavior for optional parameters, and expected effects, making it hard for an agent to call correctly in an unconstrained context.

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

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

Schema description coverage is 0%, so the description must compensate, but it only restates parameter names with Chinese translations. It adds no extra meaning about units, valid ranges, the meaning of tension_type values, or how group_name interacts with the load case.

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: 'Apply cable length adjustment load', which clearly identifies what the tool does. The Chinese annotation '索长误差荷载' reinforces the meaning and distinguishes it from sibling load tools like add_initial_tension_load.

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 gives no guidance on when to use this tool versus alternatives such as add_initial_tension_load, apply_prestress, or add_beam_section_temperature. No context about typical scenarios, prerequisites, or exclusions is provided.

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

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

Annotations are all false and offer no behavioral hints, so the description must carry the burden. It only says 'Add' and details parameters; it does not disclose side effects, whether duplicate names are rejected, whether load_case_factors must reference existing load cases, or any mutation/validation behavior. This is a significant gap for a state-changing tool.

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

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

The description is front-loaded with the tool's purpose, then organized as a clear Args list. Every parameter entry is informative, bilingual, and non-redundant; no sentence is wasted despite the length.

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 parameter construction, the description is essentially complete given all enum values and formats are included. However, it omits behavioral context such as prerequisites, error conditions, and whether omitted load_case_factors is acceptable, which an agent would benefit from when invoking this mutating 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%, but the description thoroughly compensates by explaining every parameter: name, standard with its numeric codes, kind with full per-standard enum mappings, load_case_factors with an example format, and combine_method. This goes well beyond the bare schema and gives an agent everything needed to construct valid arguments.

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 opens with a specific verb and resource: 'Add a load combination for structural checking' (添加检算荷载组合), which clearly states what the tool does. The phrase 'for structural checking' distinguishes it from the sibling add_load_combine, which likely targets general load combinations.

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

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

The description provides clear context: this tool is for adding load combinations used in structural checking, and it specifies the relevant code standards (JTG D60-2015, TB 2017). It does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusion 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?

Annotations already carry the basic write-operation profile (readOnly=false, destructive=false), and the description adds useful conditional behavior: limbs_number is for normal stirrups, loops_number and core_diameter are for spiral stirrups, with units clarified. It does not disclose duplicate-ID behavior or other side effects, but the annotations lower the burden.

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 one-line purpose is front-loaded, followed by a compact structured parameter list. Each parameter line carries useful information, and the bilingual labels are non-redundant in a mixed-language context.

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

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

With 9 parameters, no enums, no output schema, and no nested objects, the description supplies enough to invoke the tool correctly: all argument semantics, units, defaults context, and type-specific usage. It could be slightly richer by stating the return/result of the call or duplicate-ID behavior, but these are not blocking for a creation 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?

Even though the input schema has 0% description coverage, the Args block documents all 9 parameters with meanings, units (meters), and the 1=normal/2=spiral type mapping. It also explains which parameters apply to which stirrup type, adding semantic value far beyond the bare schema types and defaults.

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

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

The description opens with a specific verb and resource: 'Add a stirrup definition for checking', so an agent knows exactly what action is performed. It does not explicitly contrast itself with siblings like manage_check_stirrup or assign_element_stirrup, which keeps it from a 5.

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

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

The phrase 'for checking' gives clear context that this tool creates a stirrup definition used in check/verification workflows. It does not mention when to prefer manage_check_stirrup or assign_element_stirrup, so exclusions/alternatives are absent.

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

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

Annotations provide no behavioral hints, so the description must carry the burden. It does disclose the core linear-relationship behavior and DOF index meanings, but it does not explain side effects, duplicate-name behavior, validation, or how the equation affects the model beyond being added.

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 content is well-organized with a summary, Args block, and example, and the key behavior is front-loaded. However, repeating every line in Chinese roughly doubles the length without adding information for an English-speaking 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 5-parameter tool with no output schema and unhelpful annotations, the description supplies nearly all needed call semantics: parameter roles, valid value meanings, and an example. It is still slightly incomplete about when this tool should be preferred over other master/slave or constraint tools.

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 fully compensates by explaining each parameter, including DOF index meaning (1=Dx, 2=Dy, etc.), the nested master_info structure, and coefficient interpretation. The worked example concretizes the exact list format expected.

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

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

The description clearly identifies a specific action ('Add a constraint equation between node DOFs') with a precise mathematical definition: slave_dof = Σ(coefficient × master_dof). This distinguishes it from generic 'link' or 'support' tools, though it does not explicitly contrast with the similar add_master_slave_link 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 guidance on when to use this tool instead of alternatives like add_master_slave_link or add_bea_constraint. The example clarifies syntax but not the selection criteria or preconditions for constraint equations.

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

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

The annotations provide no useful hints (all false), so the description must carry the behavioral burden, but it only documents parameter formats. It does not mention side effects, insertion order of stages, prerequisites, duplicate-name handling, or what the tool returns after adding a stage. The enum code mappings are useful but belong more to parameter semantics than operational behavior.

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

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

The purpose is front-loaded and the layout follows a clean Args docstring with indented nested formats that are easy to parse. Minor waste is the duplicated 'tangent' mapping for install_method codes 3 and 4, which could confuse an AI agent without the Chinese parentheticals.

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 output schema and no schema-level parameter descriptions, the parameter documentation is thorough. However, the overall context is incomplete: it lacks usage guidance, prerequisites, stage-ordering behavior, and differentiation from the five stage-related sibling tools, so an agent still cannot confidently decide when to call 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 coverage is 0% and the schema types are opaque (arrays of empty items arrays), so the description must do all the work. It fully specifies every parameter, including the nested [group_name, age, install_method, weight_stage_id] structure, position codes (0/1), time codes (0/1), and install_method codes, with Chinese equivalents that disambiguate the duplicate 'tangent' translation.

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 opens with a specific verb+resource ('Add a construction stage') in both English and Chinese, which is unambiguous about the operation. It does not explicitly distinguish itself from the many stage-related siblings (update_construction_stage, remove_construction_stage, merge_operation_stage, change_construct_stage), but the 'add' verb plus the parameter list makes the core purpose clear enough.

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 alternatives such as update_construction_stage, remove_construction_stage, merge_operation_stage, or change_construct_stage. Given five closely related construction-stage siblings, the absence of any routing context leaves the agent to guess based only on parameter overlap.

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

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

Annotations provide no meaningful behavioral signals (all false), and the description only says 'Add' without disclosing effects, whether existing functions are overwritten, validation rules, or return behavior. For a mutating tool this is a notable gap.

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

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

The description is compact, front-loaded with the purpose, and uses a clean Args structure. The bilingual repetition adds length but is not wasteful; it aids clarity for mixed-language users.

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 add-operation with three parameters, the description documents the parameters adequately but omits usage guidance, behavioral effects, and any return/result information. With no output schema and no annotation support, the definition is only minimally 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 description carries the full burden for parameter meaning. It compensates well by explaining each argument, especially creep_data with its expected format '[[time(days), coefficient], ...]' and Chinese translations. Scale_factor gets only a minimal 'Scale factor' gloss, preventing a 5.

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 opens with 'Add user-defined creep function', a specific verb and resource that clearly identifies the tool's purpose. It distinguishes itself from sibling functions like add_shrink_function and add_spectrum_function by naming 'creep function' 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?

No guidance is given about when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only states what the tool does, leaving the agent to infer usage context 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?

Annotations are minimal (readOnly=false, no idempotency or destructiveness signal), and the description adds no behavioral context such as whether an existing load case must exist, whether the load is appended or replaces existing loads, or what units apply. It mostly restates parameter semantics, leaving side effects opaque.

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 definition is one sentence plus a flat Args list, front-loads the purpose, and avoids excessive prose. The only minor inefficiency is repeating the same information in English and Chinese for every parameter.

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 mutation with no output schema and minimal annotations, the parameter coverage is strong, but the description omits prerequisites, fallback behaviors (temperature_data default null), and any result/return information. It is adequate but not complete enough for fully reliable autonomous 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?

With schema description coverage at 0%, the description compensates by documenting all five parameters, including orientation values (1=Y, 2=Z) and the [distance, temp_diff] shape of temperature_data. However, it leaves ambiguities such as the accepted string form of element_id and the meaning of null temperature_data.

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 ('Apply') and resource ('custom temperature load'), with a Chinese gloss that reinforces the intent. It is distinguishable from sibling temperature tools such as add_system_temperature and add_gradient_temperature because it is labeled 'custom', 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?

The description provides no guidance on when to use this tool versus siblings like add_system_temperature, add_gradient_temperature, or add_beam_section_temperature. An agent must infer that 'custom temperature points' implies a point-wise profile; no exclusions, prerequisites, or alternative suggestions 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?

Annotations are all false/default, so they only indicate this is a mutation. The description adds no behavioral context about side effects, duplicate handling, required setup, or how the load is actually associated with the model. It does not explain what happens if points or plate_ids are omitted.

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 docstring is compact and scannable, with a one-sentence summary followed by an aligned Args list. The bilingual glosses add some repetition but each line contributes parameter information; there is no filler or unnecessary prose.

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 9 parameters, no schema descriptions, and no output schema, the description is not sufficient for reliable invocation. It omits load magnitude specification, valid type_name values, coordinate-system semantics, and any required setup, so an agent would need external knowledge to call this tool 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 description coverage is 0%, so the Chinese parameter glosses carry the explanatory burden. They clarify each parameter's basic role (e.g., point1 defines the plane, plate_ids is optional), but leave critical semantics unexplained: what type_name values are valid, how coord_system is interpreted, and what units/format the point coordinates use.

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 first line states a clear verb ('Apply') and resource ('arbitrary distributed plane load'), reinforced by the Chinese gloss. It is not a tautology and the plane-load terminology separates it from beam/plate loads, though it does not explicitly contrast with siblings like add_plate_element_load.

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 use this tool versus alternatives such as add_plate_element_load or apply_beam_distributed_load. There is also no mention of prerequisites like needing a pre-existing load case, load group, or load type.

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

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

Annotations are all neutral false, so the description carries the full burden of behavioral disclosure. It never explains side effects, whether existing effective widths are overwritten, whether a boundary group must already exist, or what 'adding' does to the model beyond the literal action.

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 opening action sentence is concise and front-loaded, and the Args block is structured with no obvious fluff. The bilingual repetition slightly lengthens the text but remains informative.

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 thin on operational context. It covers parameter labels well but omits prerequisites, side effects, units, and the relationship between effective width and beam elements, leaving the agent to rely on assumptions.

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 compensates by explaining every parameter: element_ids, I/J factors, Dz offsets, and the boundary group. It adds meaning beyond the bare schema titles, such as 'I-end factor', 'J-end Dz offset', and 'boundary group 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 ('Add effective width to beam elements'), making the core action and target clear. It does not explicitly differentiate itself from sibling add_* tools, but the resource name narrows the scope sufficiently.

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 use this tool versus alternatives. The sibling list contains many related section/update tools, but the description provides no criteria, prerequisites, or exclusions to help an agent select this tool.

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

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

Since annotations are all false and provide no hints, the description carries the behavioral disclosure burden. It compensates well by detailing per-link-type constraints such as stiffness_values being only for type=1 and kx only for type=3/4, and gives concrete examples. It does not mention what happens if referenced nodes do not exist or whether an existing link is replaced, but the core behavioral constraints are covered.

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

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

The description is bilingual and lengthy, but well-structured with an Args list and Example section. Every sentence carries semantic value, and the conditional parameter notes are front-loaded within the parameter list. It could be slightly tighter in wording, but nothing is 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 tool with ten parameters, no output schema, and no enums, the description covers all parameter semantics and gives two realistic examples, making it highly usable for an agent. It omits any description of the return value or side-effect behavior such as whether the operation overwrites existing links, but the input-side information is sufficiently complete 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?

The schema has 0% description coverage, so the description fully compensates by documenting all ten parameters, including types, allowable values for link_type, the six-component stiffness array, units for beta_angle, and conditional 'ONLY for' usage. This is more than the schema provides and is essential for correct invocation.

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

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

The description clearly states the tool adds an elastic link between two nodes and models connections like bearings, which is a specific verb and resource. It distinguishes from support-style tools by the 'between two nodes' phrasing, but it does not explicitly contrast with similar link tools such as add_master_slave_link.

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 when to use the tool by explaining that elastic links model connections like bearings between members, and the examples show typical calls. However, it does not explicitly state when to choose this tool over alternatives or when not to use it, so the guidance is implied rather than direct.

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

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

Annotations provide no positive hints, so description carries the burder. It discloses the mutation ('Add'), explains how spring_values are interpreted differently for each support_type, and includes units and direction mappings. It does not state whether repeated calls overwrite or merge with existing springs or what side effects boundary-group creation has, preventing a 5.

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

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

Well-structured with a concise summary, Args section, and Example section, front-loading the purpose. The bilingual repetitions add length but are purposeful for this domain and every line carries meaning; slightly redundant but not padded.

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 unusually complete: it covers purpose, all parameters, type-specific formats, units, and usage examples. Minor gaps remain, such as exact range-string syntax and whether an existing elastic support at the same node is replaced or accumulated.

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 fully compensates: every parameter is explained, including node_id's allowed forms (int, list, range string), the type-dependent shape of spring_values, direction codes, and support_type meanings. Examples demonstrate valid argument combinations.

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, 'Add elastic spring supports on nodes', and clarifies real-world modeling intent (foundation flexibility, pile caps, rubber bearings). This clearly separates it from sibling tools like add_elastic_link or set_support, which concern different structural entities.

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 use cases (foundation flexibility, pile caps, rubber bearings) and worked examples showing when to use type=1 vs type=3. Does not explicitly warn against using set_support or add_elastic_link instead, so it lacks explicit exclusions, but the context is strong.

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

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

Annotations are all false and provide little behavioral context, so the description carries the burden. It usefully discloses that the group must already exist and that element_ids supports list or range-string formats. It does not mention error behavior, duplicate handling, or whether the operation is additive-only, which keeps it at a mid score.

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 compact and front-loaded with the main purpose, followed by a concise Args block. Every sentence contributes useful information, and the bilingual repetition is not excessive.

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 tool with no output schema, the description covers the essential invocation details: target group, element IDs, and supported formats. It is slightly incomplete because it does not address the ambiguous overlap with 'add_to_structure_group', but otherwise the agent has enough 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 description coverage is 0%, but the description documents both parameters meaningfully: group_name is the structure group name and element_ids accepts element IDs with explicit support for list or range string '1to20'. This adds real value beyond the raw schema types.

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

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

The description clearly states a specific verb and resource: 'Add elements to an existing structure group'. It distinguishes itself from creation and removal tools by emphasizing 'existing'. However, it does not distinguish itself from the almost identically named sibling 'add_to_structure_group', so it loses the top score.

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 the tool is for adding elements to a group that already exists, but it provides no explicit when-to-use guidance, no exclusions, and no alternatives. Given the near-duplicate sibling 'add_to_structure_group', the absence of any routing guidance is a notable 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?

Annotations declare readOnlyHint=false and destructiveHint=false, so the mutation profile is known, and the description is consistent with those annotations. However, the description adds little behavioral context beyond the parameter list: it does not state whether repeated application accumulates, whether an existing load case is required, or what side effects occur on the model.

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 docstring-style format is compact and well organized: a one-line action summary followed by a complete Args block. The bilingual text doubles length but is intentional for the target engineering domain. No filler or redundant sentences.

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

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

For a 6-parameter load-application tool with no output schema, the description covers parameter semantics thoroughly but omits workflow context: whether the load case must pre-exist, expected units for temperature, and what the tool returns after success. These are minor but non-trivial gaps 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%, so the description carries the full burden, and it succeeds. Every parameter gets a bilingual meaning: element_id explains that strings are supported as range strings, section_oriental gives the 0=Y/1=Z meanings and the beams-only constraint, element_type gives the 1=beam/2=plate mapping, and defaults are restated. This adds genuine value beyond the bare schema types.

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

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

The description opens with 'Apply gradient temperature load (梯度温度荷载)', which states a specific verb and resource. However, it does not differentiate itself from closely related sibling tools such as add_system_temperature, add_beam_section_temperature, and add_custom_temperature, so an agent must infer the distinction from the name 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 guidance on when to use this tool versus the many alternative load/temperature tools in the sibling list. No prerequisites (e.g., needing an existing load case), no exclusion criteria, and no mention of when a different temperature/load tool would be more appropriate are provided.

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

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

Annotations provide no effective safety signals (all false), so the description carries the burden. It explains that the influence plane is built from node tandems and is a prerequisite for lanes/load cases, but it does not disclose duplicate-name behavior, validation failures, or other side effects. This is adequate but not deeply transparent.

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

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

The description is compact and front-loaded with the purpose and workflow step. Only minor redundancy exists, such as mentioning node tandems in both the first sentence and the explanation sentence, but the overall structure is clear and free of unnecessary 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 simple two-parameter tool with no output schema, the description covers what the tool does, what it requires, and where it fits in the workflow. It could be improved by explicitly pointing to add_node_tandem as the source of tandem names or noting duplicate-name behavior, but nothing essential is missing for a correct call.

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

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

The input schema has 0% parameter description coverage, but the description's Args section compensates by defining both parameters, giving a Chinese equivalent and example for name, and stating that tandem_names are node tandem names. It also notes 'one or more' node tandems, adding cardinality information beyond the raw 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 opens with a specific verb+resource statement, 'Define an influence plane from node tandems,' which clearly distinguishes this tool from siblings like add_node_tandem or add_traffic_lane. The added workflow context ('STEP 2 of the moving load workflow') further clarifies its unique role.

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 gives clear usage context: it is 'STEP 2 of the moving load workflow', depends on 'one or more node tandems', and is 'required by lanes and load cases'. This implies when to call it relative to other tools, though it does not explicitly state when not to use it or name an 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?

Annotations only indicate the tool is not read-only, not idempotent, and not destructive, which provides minimal safety context. The description does not explain side effects, required model state, units, or how the load is applied, leaving the agent without meaningful behavioral expectations beyond the verb 'Apply'.

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

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

The description is reasonably concise, with the core action front-loaded and parameters listed compactly. The argument list is repetitive with the schema but each entry is short and adds translation value, so no major 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 seven parameters, no output schema, and no annotations explaining behavior, the description is incomplete for correct invocation. It does not explain how the load is calculated, what prerequisites exist (e.g., elements and load cases must already be created), or how tension_type and application_type affect 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?

Schema description coverage is 0%, so the description must compensate. It lists all seven parameters with Chinese translations and clarifies stiffness as 'Stiffness reduction (刚度参数)', adding some meaning beyond the schema titles. However, it omits units, allowed values, and the relationship between tension_type and application_type, so coverage remains shallow.

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, 'Apply initial tension load (初拉力荷载)', which clearly identifies the tool's function. However, it does not differentiate from sibling tools such as apply_prestress or add_cable_length_load, leaving the agent to infer the distinction.

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 like apply_prestress, add_cable_length_load, or assign_tendon_elements. The description only lists arguments and does not mention prerequisites, typical scenarios, 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?

Annotations already indicate this is not read-only and not destructive, but the description adds no behavioral detail beyond the creation action. It does not mention what happens on duplicate names, whether referenced load cases must already exist, or what side effects occur, so the description carries little transparency burden beyond the structured hints.

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

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

The description is well-structured with the core action first and a compact Args list. The bilingual text duplicates content, which adds length, but the structure is still clear and front-loaded, and each part supports invocation.

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

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

Parameter information is complete, but for a mutating tool with no output schema, the description lacks details about duplicate-name behavior, required load-case existence, and any return/result semantics. It is adequate for a basic add operation but has notable gaps in behavioral and operational context.

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

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

Schema description coverage is 0%, so the description must carry the full parameter burden. It does: all five parameters are listed, combine_type is given numeric meaning, combine_info is explained as a nested list [case_name, case_type, factor], and index default -1 is clarified. This fully compensates for the sparse schema.

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

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

The description clearly states the verb and resource: 'Add a load combination' and 'Combines multiple load cases into a single combination.' However, it does not distinguish itself from the sibling tool add_check_load_combination, and the phrase 'for analysis/checking' could cause an agent to confuse this with a checking-specific combination 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?

There is no guidance on when to use this tool versus alternatives such as add_check_load_combination or create_load_case. The intended context is only implied by the general combination purpose, with no exclusions, prerequisites, or conditional routing.

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

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

Annotations give only default false hints, so the description carries the behavioral disclosure burden. It says 'convert' but does not explain side effects, whether the original load case remains, whether the conversion is reversible, or what model state is changed.

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 compact and front-loaded with the core purpose, followed by concise argument documentation. The bilingual duplication adds some length, but it is not excessive and serves to clarify meaning.

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 tool, the description provides enough to invoke it, but it omits side effects and return behavior. There is also no usage distinction from similar load- and mass-related siblings, leaving some ambiguity for agent decision-making.

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 documents both parameters: name as the load case to convert and factor as the conversion factor with the usual value of 1.0, adding practical meaning beyond the bare schema types.

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

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

The description states a specific verb and resource: 'Convert a load case to mass for dynamic analysis.' This clearly identifies what the tool does and semantically distinguishes it from related tools like add_nodal_mass or create_load_case.

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 'for dynamic analysis' provides an implied usage context, but there is no explicit guidance about when to prefer this tool over alternatives such as add_nodal_mass. No when-not-to-use conditions or alternative tool references 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?

Annotations are all false, so the description carries the behavioral burden. It usefully discloses the constraint semantics (slaves follow master motion) and the dof_constraints default (all constrained). It does not address side effects such as duplicate-link behavior on repeated calls (relevant given idempotentHint=false) or interaction with existing constraints on the same nodes.

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

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

Compact and front-loaded: the core action is the first sentence, followed by the use case and a tight Args block. The bilingual repetition roughly doubles length but serves the domain's user base, and every section earns its place given the schema's 0% coverage.

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?

Everything needed to call the tool correctly — semantics of all four parameters, defaults, and range-string syntax — is present. Remaining gaps (return/success signal, duplicate or conflict behavior) are minor for a model-construction tool, and there is no output schema whose absence would compound the issue.

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

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

With 0% schema description coverage, the description fully compensates by documenting all four parameters with meaning the schema cannot convey. Critical details live only here: the '2to5' range-string format for slave_node_ids, the [dx,dy,dz,rx,ry,rz] ordering of dof_constraints, what True means, and the default all-constrained behavior.

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

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

Opens with a specific verb+resource — 'Add master-slave constraint (rigid link) between nodes' — and then explains the underlying mechanism: slave nodes follow the master node's motion. The rigid-link concept, reinforced by the diaphragm application, clearly differentiates it from sibling constraint tools like add_elastic_link, add_beam_constraint, add_constraint_equation, and set_support.

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?

States a concrete use case — rigid connections where slave nodes follow a master node, typically for diaphragm rigid zones — which gives an agent clear context for when to invoke it. However, it never explicitly names alternatives (e.g., add_elastic_link for flexible coupling) or states when not to use it, leaving comparative routing 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?

Annotations are all false, so the description carries the full burden of behavioral disclosure; 'Add nodal mass' confirms a mutating operation but nothing more. It does not explain whether repeated calls accumulate or overwrite mass, what units or coordinate system apply, or any side effects on existing definitions.

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 definition is compact and front-loaded with the operation and purpose. The bilingual parentheticals add some redundancy for an English-speaking agent, but overall the structure is scannable and free of 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 simple 5-parameter add operation, the essential operation and parameters are present, and defaults are visible in the schema. However, notes on units, accumulation behavior, and relationship to the broader dynamic-analysis workflow are missing, leaving some uncertainty about side effects.

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, but the Args list mostly restates schema titles ('Mass in X direction' vs 'Mass X'). It adds modest clarification that node_id can be plural and that mass_rm is rotational mass, but these are largely self-evident from 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 ('Add nodal mass') with an explicit purpose ('for dynamic analysis'), making its function clear. It is distinguishable from related sibling tools like apply_nodal_force or add_load_to_mass, though it does not name 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?

The phrase 'for dynamic analysis' implies it belongs in dynamic-analysis model setup, which is useful context. However, it does not state when not to use it, does not mention alternatives, and leaves the boundary with related load/mass tools 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?

Annotations provide no behavioral hints (all false), so the description must carry the burden. It does disclose that order_by_x auto-sorts nodes by X coordinate, which is useful. However, it does not mention side effects (e.g., whether repeated calls create duplicates), error conditions, or any consistency guarantees. No contradictions with annotations, but the description leaves behavioral gaps.

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

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

The description is structured with a purpose statement, workflow context, and parameter list. It includes bilingual text which doubles length but appears intentional for the user base. The core information is front-loaded and no redundant fluff, though the translations add some verbosity.

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

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

Given the tool's simplicity (3 params, no output schema) and lack of annotations, the description covers purpose, workflow placement, and parameter semantics effectively. It could add prerequisites (e.g., nodes must exist) or error handling, but for a step-1 tool in a defined workflow, the context is largely 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?

Schema description coverage is 0%, so the description must compensate. It fully explains all three parameters: name (tandem name), node_ids (node list or range string like '1to101'), and order_by_x (auto-sort behavior). This goes well beyond the schema's type-only definitions, providing critical usage details like format and default behavior.

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

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

The description clearly states the tool defines a node tandem—the node path a moving load travels along—and explicitly labels it as STEP 1 of a moving load workflow. This is a specific verb-resource pair that distinguishes it from siblings like add_influence_plane or create_live_load_case through its step sequencing.

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

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

The description provides explicit workflow context: 'This is STEP 1 of the moving load workflow' followed by the ordered steps. This tells agents when to invoke it (when starting a moving load setup). It does not enumerate alternatives or exclusions, but the stepwise sequence gives clear usage direction.

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

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

The annotations are neutral (all false), so the description carries the burden of explaining side effects, but it only documents parameters and does not state whether existing reinforcement is overwritten, whether the operation is additive, or what errors can occur. No contradiction with annotations exists, but behavioral disclosure is minimal.

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 opens with a clear one-line purpose and then presents a structured Args section. The bilingual annotations add length but are purposeful and aid comprehension; there is minimal 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 6-parameter tool with complex nested array inputs and no output schema, the description covers the parameter format well and explains the outer/inner rebar structure. However, it omits relationships between has_outer/has_inner and the corresponding info arrays, and does not mention prerequisites like whether the section must already exist. Overall, the essential calling information is present.

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

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

With 0% schema description coverage, the description fully compensates by naming each parameter, defining position mapping (0=I端/start, 1=J端/end), and specifying the exact nested list format for rebar info including units (mm, m). This adds substantial meaning beyond the bare schema types.

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

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

The description clearly states the action ('Add parametric reinforcement') and the target ('to a concrete section'), making the tool's function immediately identifiable. It is distinct from sibling section-related tools such as create_section, update_section_property, and remove_section.

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 use this tool versus alternatives, nor any prerequisites such as the section needing to already exist. The only usage signal is implied by the action itself, so the agent receives no routing or precondition help.

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?

All annotations are false/neutral, so the description carries the burden of behavioral disclosure. It only says 'Apply plate element load', which implies a mutation but does not explain whether repeated calls accumulate loads, overwrite existing loads, or require prior setup. No side effects, constraints, or consequences are 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?

The description is tight and front-loaded with the core action, followed by a compact parameter list with no filler. The bilingual annotations are repetitive but each line carries information. It is appropriately sized for an 8-parameter tool, though it prioritizes completeness over detailed explanation.

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 load-application tool with 8 parameters and no output schema, the description omits critical context: allowed numeric values for load_type and load_place, how list_load and list_xy are paired, whether element_id accepts ranges/names, and what happens on success. The parameter list alone is not enough for an agent to call the tool correctly with valid inputs.

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

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

With 0% schema description coverage, the parameter list is the only source of meaning for the 8 parameters. It provides a short gloss for each parameter, including Chinese translations and a useful note that coord_system=3 means global. However, most entries just restate the parameter names ('Load type', 'Load values', 'Location coords') without explaining value domains, units, or relationships between list_load and list_xy.

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 opens with a specific verb and resource: 'Apply plate element load', reinforced by the Chinese gloss '板单元面上荷载'. This identifies the target operation and distinguishes it at a basic level from beam, nodal, and temperature load tools in the sibling list. However, it does not explicitly differentiate from similar-looking load tools such as add_distribute_plane_load, 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 guidance on when to use this tool versus alternatives, such as apply_beam_distributed_load or add_distribute_plane_load. It also does not mention prerequisites like whether the load case must already exist, or whether the tool is appropriate for a particular load type. The agent is left to infer usage solely 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?

Annotations provide no behavioral hints (all false), so the description must carry this burden. 'Add' implies mutation, but the description does not say what happens on name collision, whether shrink_data may be omitted, or how scale_factor affects the definition. There is no mention of return values or side effects beyond the add action itself.

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 definition is compact and front-loaded with a one-line purpose followed by a short arg list. Bilingual duplication lengthens it slightly but does not obscure the essential content.

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

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

For a simple function-addition tool, parameter semantics are reasonably covered, but no output schema and no behavioral details leave gaps around overwrite/idempotency and optional inputs. It is adequate but not 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 coverage is 0%, so the description must explain parameters, and it does. It documents name, gives a concrete data shape for shrink_data with units ([[time(days), strain], ...]), and defines scale_factor as a multiplier. Minor gap: it does not explain what scale_factor multiplies or the meaning of a null shrink_data.

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 opens with 'Add user-defined shrinkage function,' naming a specific verb and resource. This clearly distinguishes it from siblings like add_creep_function and add_spectrum_function, whose domain differs by material effect.

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 context is implied by the function name and 'user-defined shrinkage function' wording, but the description never states when this tool should be preferred over alternative function-definition tools, nor does it mention any 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?

Annotations are all neutral/false, so the description carries the burden of behavioral disclosure. It states that a load case is added, but does not clarify side effects, dependencies on existing spectrum functions, whether duplicate cases are allowed, or how null direction info is treated.

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 compact, well-structured as an Args list, and every line adds information. It includes bilingual terms without unnecessary prose, making it easy to scan and parse.

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

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

For a mutation tool with no output schema and no explicit annotations, the description is incomplete. It lacks usage context, dependency requirements (e.g., spectrum functions must exist), behavior for optional/null fields, and any note about results or side effects.

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 is the only source of parameter meaning. It adds valuable semantics for all six parameters, including that 'kind' is a combination method (SRSS/CQC) and that info_x/y/z are arrays of [function_name, factor]. However, it does not specify valid integer values for 'kind' or exact array shapes.

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 a specific verb and resource: 'Add response spectrum load case', with an additional Chinese translation. It does not explicitly differentiate itself from sibling tools like add_time_history_case or create_load_case, but the resource is specific enough to be identifiable.

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

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

The description provides no guidance on when to use this tool over alternatives such as add_time_history_case or create_load_case. It does not mention prerequisites, exclusions, or conditions that would help an agent select this tool correctly.

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

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

The annotations provide only weak signals (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds no behavioral detail about duplicate handling, validation, required conditions for kind, side effects, or error behavior, which is a meaningful gap for a model-mutating add 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?

The description is compact: a one-line purpose followed by a four-item parameter list. The bilingual annotations are terse and add no filler, and the most important information is front-loaded.

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 essential parameters are covered, but the description omits workflow context such as how this relates to add_spectrum_case, accepted kind values, and return/error behavior. Since there is no output schema, a bit more context about expected outcomes would improve completeness.

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

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

Schema description coverage is 0%, but the docstring compensates by explaining each parameter: name, factor, kind, and function_info, including the concrete structure [[period, value], ...] for function_info. It does not enumerate kind values, but it provides enough semantic meaning for initial tool selection.

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

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

The description states a specific action and resource: 'Add response spectrum function', with a Chinese translation. This clearly differentiates it from sibling tools like add_creep_function, add_shrink_function, and add_time_history_function.

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: call this when you need to define a response spectrum function. There is no explicit guidance about when to choose this over related tools like add_time_history_function or add_spectrum_case, nor any stated 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?

Annotations are all false, so the description carries the transparency burden. It adds useful behavioral detail beyond the schema: loads come from a design code database, load_type must match the QiaoTong UI exactly, and standard_code maps to specific design codes. It does not fully describe side effects or return values, but it gives enough behavioral grounding for safe invocation.

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

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

The description is well-structured and front-loaded with the primary purpose, followed by the workflow step and then a clean Args block. It is somewhat lengthy due to bilingual content and per-parameter annotations, but each piece adds necessary domain 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?

For a 5-parameter tool with no output schema, the description covers the essential invocation details: the operation, workflow position, all parameter semantics, and UI-matching requirements. It does not mention prerequisites such as an active model or what happens on duplicate names, but the provided context is sufficient for most agent calls.

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 is the only source of parameter meaning. It explains all five parameters, provides the complete 1-7 standard_code mapping, gives concrete load_type examples, and clarifies the special meanings of load_length (0 = unlimited) and factor. This is exactly what an agent needs beyond the raw schema.

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

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

The description clearly states the action and resource: 'Add a standard vehicle load from a design code database' and labels it as 'STEP 4 of the moving load workflow.' This is specific enough to understand the tool's role, though it does not directly contrast with nearby siblings like add_node_tandem or create_live_load_case.

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 'STEP 4 of the moving load workflow' phrase provides clear workflow context for when this tool should be invoked. It does not explicitly mention alternatives or exclusions, but the workflow placement gives an agent reasonable guidance on sequencing.

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

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

Annotations already indicate this is a mutating, non-idempotent operation (readOnlyHint=false, idempotentHint=false). The description adds no extra behavioral context beyond 'Apply' — it doesn't state whether the load is appended to an existing case, whether duplicate calls create duplicate loads, or whether the operation can be reversed. It merely restates the operation type.

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 tightly structured: one purpose line followed by a clean Args list. There is no redundant prose, no repetition of types or defaults already in the schema, and each parameter is explained in a single short line. The core action is front-loaded.

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?

All parameter meanings are covered, but practical invocation context is missing for a 9-parameter mutating tool with no output schema. The description doesn't state whether case_name must already exist, whether group_name can be omitted safely, how multiple displacement components interact, or what happens on repeated calls. These gaps could lead an agent to misuse the 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%, but the description compensates fully by documenting all nine parameters with meaningful bilingual labels. It gives the sign convention for dz ('下沉为负值'), clarifies dx/dy as forced displacements, rx/ry/rz as rotations, and indicates node_id can be multiple IDs. This is exactly the kind of semantic enrichment the schema lacks.

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 and resource: 'Apply support settlement / nodal displacement load'. It goes beyond the tool name by giving the alternative term and Chinese translations, making the operation clear. It doesn't explicitly contrast with siblings like apply_nodal_force or set_support, but the core 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?

No guidance is provided on when to use this tool versus alternatives such as apply_nodal_force, set_support, or other load-application tools. It also doesn't mention prerequisites like whether case_name must reference an existing load case or whether group_name is required. The only implied usage is from the purpose line itself, which is not sufficient.

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

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

Annotations already show readOnlyHint false, implying mutation, but the description adds no further behavioral context. It does not disclose whether repeated calls accumulate or overwrite loads, whether the load case must already exist, or what side effects occur on existing model data. With weak annotations, more responsibility falls on the description, and 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?

The description is a compact docstring: one sentence defining behavior plus a four-item argument list. Each line adds relevant information, and the Chinese glosses serve as useful clarifiers rather than 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 mutating tool with no output schema and several closely related sibling load tools, this description is not sufficiently complete. It omits when to choose system temperature over custom/gradient/beam-section temperature, and it does not state prerequisites or the effect of repeated calls. An agent could make a plausible call, but not with full confidence about load-case handling.

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 partially does by clarifying element_id can be plural ('Element ID(s)') and by giving temperature sign convention ('升温+20，降温-20'). However, it omits units and acceptable string formats for element_id, and group_name is only labeled rather than explained.

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: 'Apply system temperature load', and the Chinese gloss '整体升降温荷载' clarifies this is a whole-structure thermal load. This distinguishes it in load type from sibling tools like add_gradient_temperature and add_beam_section_temperature, though it does not 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?

There is no guidance on when to use this tool versus add_custom_temperature, add_gradient_temperature, or add_beam_section_temperature. No prerequisites are mentioned, such as whether a load case or group must already exist, and no exclusions or alternative conditions are provided. The Args block documents parameters, not usage policy.

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

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

The annotations only say this is not read-only, not idempotent, and not destructive, but they do not describe side effects. The description merely says 'Add' and does not disclose whether re-adding with the same name overwrites, whether existing element sections are modified, or what the result/return behavior is. With sparse annotations, the description carries a heavy burden and does not carry it.

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 compact: one summary sentence plus a bulleted parameter list with no filler. The repeated Chinese translations add length but are likely intentional for the target domain and are not excessive.

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 mutating tool with eight parameters, no output schema, and minimal annotations, the description is incomplete. It explains what arguments mean but not what happens when the group is added, whether it replaces an existing group, what string ids may contain, or how factor/ref/dis values combine to produce the taper. An agent would still be guessing about side effects and return 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?

The input schema has 0% description coverage, so the description fully compensates by explaining all eight parameters with semantic labels, including the key reference-point convention '0=i, 1=j'. It does not clarify the accepted string format for ids or the exact geometric meaning of the variation distance and factors, but it provides substantially more meaning than the bare schema titles.

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

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

The description states a clear action and resource: 'Add a tapered section group' with a Chinese gloss. It is not a tautology and the parameter list reinforces the purpose. However, it does not explicitly distinguish this from the sibling create_tapered_section, which could be confused with defining a tapered section property rather than a group of elements.

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

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

No guidance is given about when to use this tool versus related alternatives such as create_tapered_section, create_structure_group, or add_elements_to_group. There is no mention of prerequisites (e.g., elements already existing or sections already defined) or exclusions, so the agent must infer usage from the name and arguments.

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 all annotation hints false, the description carries the full burden of behavioral disclosure. It clearly states a mutation ('Add') and adds one useful precondition ('property_name must exist'), but it does not explain side effects, duplicate-name behavior, return values, or whether the tendon is immediately usable. No contradiction with annotations 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 a one-sentence summary followed by a tight Args block, with each parameter on one line and bilingual glosses. It is front-loaded, contains no filler, and is appropriately sized for an 8-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?

For a geometry-creation tool with nested arrays and no output schema, the description covers inputs thoroughly but omits interaction details (e.g., how line_type relates to position_type), coordinate units, minimum control-point count, and error behavior. It enables a basic call but leaves edge cases ambiguous.

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 does. It provides explicit formats for control_points ([x, y, z, r]), explains point_insert, and gives numeric codes for line_type and position_type. All parameters receive at least a gloss, though units and array-length constraints are not specified.

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 opens with a specific verb and resource: 'Add a 3D tendon' (添加三维钢束/空间钢束). The 3D qualifier clearly distinguishes it from sibling create_tendon_2d. An agent can immediately identify what the tool does without reading the 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?

No guidance is given about when to use this tool versus alternatives like create_tendon_2d or assign_tendon_elements. The only usage-related hint is the prerequisite that property_name must already exist, which addresses ordering but not tool selection. This falls short of explicit usage 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?

The annotations already indicate readOnlyHint=false, so the mutating nature is expected. The description adds a bit of behavioral context by explaining that 'index: -1 for auto' and detailing thick_type meanings, but it does not disclose side effects, duplicate-handling behavior, or what happens after the property is added. No contradiction with annotations 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 compact and front-loaded with the core purpose, then systematically documents each argument. Every line earns its place given the schema's lack of property descriptions, and the bilingual hints add clarity 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?

All parameters are documented and the tool is simple, but the description lacks usage guidance, return-value information (no output schema exists), and any note about how this thickness property is later applied to plates. This leaves an agent without enough context to confidently choose this tool over other property-related siblings.

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

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

The schema provides no property descriptions, so the Args block in the description fully compensates. It explains name as thickness name, t in meters, thick_type with explicit meanings for values 0 and 1, and index's auto behavior. This is exactly the semantic detail an agent needs to invoke the tool correctly.

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 a specific verb and resource: 'Add a plate thickness property.' It is not a tautology and the Chinese gloss reinforces the meaning. There is no ambiguity about what entity this tool creates, and it is easily distinguished from sibling tools by the resource name.

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

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

No guidance is provided about when to use this tool versus alternatives. It does not mention that thickness properties are global definitions to be assigned later, nor does it reference any sibling tools or conditions that should guide selection. The intended usage is merely implied by the name and parameter 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?

Annotations already indicate readOnlyHint=false, so the mutating nature is known. The description adds no behavioral context beyond the word 'Add' and parameter labels; it does not say whether the case is appended to the model, whether duplicates are allowed, or how this affects analysis configuration. No credit is earned beyond what annotations already convey.

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 compact and front-loaded with the purpose line, followed by an ordered parameter list with bilingual labels. There is little wasted prose, though the parameter list partially repeats schema titles and could be trimmed if schema descriptions existed.

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 add-operation with five parameters, the description covers the core purpose and parameter meanings, but it lacks usage context, relationships to time-history functions or analysis cases, and any return or side-effect details. It is minimally viable but leaves notable 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%, but the description compensates by listing each parameter with a meaningful role and unit, e.g. duration as 'Total duration in seconds' and time_step as 'Output time step in seconds', plus Chinese translations. The index and description parameters remain thin, but overall it provides real semantic value beyond the raw schema.

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

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

The description clearly identifies the operation with a specific verb and resource: 'Add time history analysis case', including a bilingual translation. It is unambiguous, but it does not explicitly distinguish itself from sibling tools like add_time_history_function, relying on the 'case' vs 'function' contrast to be inferred.

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 about when to use this tool versus alternatives such as add_time_history_function or add_spectrum_case, no mention of prerequisites, and no indication of where this operation fits in a typical analysis workflow. The agent must infer usage context 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?

Annotations provide no meaningful behavioral hints beyond non-readOnly, non-idempotent signals, and the description does not disclose side effects such as whether an existing function with the same name is replaced, whether points must be ordered, or what happens with invalid input. The description only says 'Add', leaving most behavioral traits 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?

The description is short, front-loaded with the purpose, and uses a clear parameter list. It avoids unnecessary prose, though the whitespace-heavy formatting adds little value.

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

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

The tool is a simple additive function with defaults for all but one parameter, and the description provides the core input shape. Still, it lacks context about how this function relates to time history cases, whether duplicate names are allowed, and what range or format constraints apply to the time-value pairs.

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 partially does: it explains name, factor as scale factor, kind as type, and function_info as [[time, value], ...] points. However, 'kind: Type' is nearly tautological and no valid kind values or constraints are given, so the added parameter meaning is incomplete.

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

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

The description clearly states the action ('Add time history function') and identifies the resource. It lists the relevant parameters, making the tool's function understandable, though it does not explicitly distinguish it from sibling functions like add_creep_function or add_shrink_function.

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 use this tool versus alternatives such as add_spectrum_function or add_time_history_case. The description states only what the tool does, not the conditions that should lead an agent to select 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?

All annotations are false and provide no read-only, idempotency, or destructiveness signals. The description only says 'Add' and lists parameters; it does not disclose side effects, prerequisites, default behavior, or whether existing parameters are replaced.

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 compact and front-loaded with the main purpose, followed by a scannable argument list. The bilingual repetition adds some length but does not hurt usability.

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

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

The description is adequate for a basic call with one required parameter and sensible defaults, but it lacks context about how this tool relates to materials, functions, or analysis cases, and there is no output schema to clarify return behavior. An agent would need additional knowledge to use it 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 the description compensates by naming all six parameters and adding useful hints such as creep_data format '[[time, value], ...]' and index '-1 for auto'. However, 'time_parameter' is vaguely described as 'Code specific parameters', leaving its exact meaning unclear.

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 ('Add') and resource ('time-dependent material parameters'), and the argument list clarifies that it deals with creep and shrinkage data. It is clear, though it does not explicitly differentiate itself from sibling tools like add_creep_function or add_shrink_function.

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

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

No guidance is provided about when to use this tool versus alternatives such as add_creep_function or add_shrink_function, nor whether this applies to an existing material or creates a new one. The usage context 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?

The description communicates an additive mutation to an existing group, which is consistent with the annotations. However, it does not explain behavior for edge cases such as nonexistent groups, duplicate IDs, or whether both node_ids and element_ids may be combined in a single call.

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 purpose is front-loaded and the Args section is compact and readable. The bilingual text adds some repetition but does not make the description unwieldy.

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

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

The description covers the main purpose, parameter types, and an example, which is good for a simple tool. However, it omits prerequisites or error behavior, and the lack of explicit 'at least one of node_ids/element_ids' guidance leaves room for incorrect invocations.

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

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

With 0% schema description coverage, the description compensates well by explaining that node_ids and element_ids support int, list, or range string like '1to10' and by providing a concrete example. It falls short of explicitly requiring at least one of node_ids or element_ids to be provided.

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

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

The description clearly states the tool adds nodes and/or elements to an existing structure group, using a specific verb and resource. It is easy to understand, but it does not explicitly differentiate itself from the sibling tool add_elements_to_group.

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 intended use is implied by the action and example, but the description does not explicitly state when to prefer this tool over alternatives such as add_elements_to_group or create_structure_group. No exclusions or prerequisites are mentioned.

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

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

Annotations provide only false hints, so the description carries the burden of behavioral context. It adds useful information about prerequisites and workflow position, but does not describe side effects, failure behavior, or whether existing lanes with the same name are replaced. This is adequate but not rich.

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

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

The description is well-structured: a one-sentence purpose, a workflow-position sentence, and a compact parameter list with relevant details. Every line adds value, and the most important context (purpose and prerequisites) appears before the parameter details.

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 output schema, the description covers the workflow step, dependencies, all parameter semantics, and typical usage values. An agent has enough information to invoke the tool correctly and understand where it fits in the moving load analysis workflow.

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

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

Despite the input schema having 0% parameter descriptions, the tool description thoroughly documents all seven parameters: names, Chinese translations, units, examples, typical values for lane_width, and explicit meanings for optimize and direction. This fully compensates for the schema's lack of descriptions.

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

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

The description opens with a specific verb and resource: 'Define a traffic lane line for moving load analysis.' It also explicitly identifies itself as 'STEP 3 of the moving load workflow,' distinguishing this tool from related siblings like add_influence_plane, add_node_tandem, and add_standard_vehicle.

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 clearly states when to use the tool ('STEP 3 of the moving load workflow') and the required prerequisites: 'Requires an influence plane and a node tandem created beforehand.' It does not explicitly state when not to use it or name alternatives, but the workflow placement and prerequisites give clear contextual 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?

Annotations only indicate readOnly=false, destructive=false, and idempotent=false; the description adds little beyond the act of applying a load. It does not disclose side effects, whether existing distributed loads are overwritten, whether a load case must already exist, or what happens on failure. This is a meaningful gap for a mutating tool.

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

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

The description is a compact, well-structured docstring with the purpose front-loaded and each parameter earning its place through concrete semantic detail. It is not bloated despite the bilingual annotations, and every line adds useful 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?

The argument coverage is strong and the tool is not overly complex, but the description omits return behavior, prerequisites, and side-effect context. With no output schema, an agent cannot tell what a successful call returns or what model state changes are expected beyond 'applies load'.

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 carries full responsibility for parameter meaning. It thoroughly documents all six arguments, including direction value-to-axis mappings, the [q1,q2] linear-varying example for load_values, the 0-1 range for load_positions, and bilingual labels for each parameter. This greatly exceeds the bare schema.

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

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

The description states a specific verb ('Apply'), a specific resource ('distributed load on beam elements'), and clearly distinguishes this from sibling load tools like apply_nodal_force and add_plate_element_load. The bilingual phrasing reinforces the intended operation without ambiguity.

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

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

The description implies this tool is for distributed loads on beam elements, which helps an agent narrow against plate or nodal load tools. However, it provides no explicit when-to-use guidance, no alternatives, and no conditions or prerequisites such as requiring an existing load case or load group.

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

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

Annotations already signal that this is a write operation (readOnlyHint=false) and non-idempotent, and the description adds no behavioral detail beyond the annotated profile. It does not disclose whether reapplying loads duplicates them, whether existing loads are overwritten, or whether the load case must pre-exist.

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 compact and front-loaded with a one-sentence purpose followed by a standard Args block. The bilingual repetition adds minor length but remains readable and well organized for 9 parameters.

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

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

The description is thin for a load-application tool with no output schema and minimal annotations. It omits when to use this tool among load siblings, the node_id string format, unit conventions, coordinate system context, and prerequisites like an existing load case or load group.

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

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

With 0% schema description coverage, the description's Args section provides the only semantic meaning for all 9 parameters, including directional meaning for force/moment components (e.g., 'Force in X direction', 'Moment about X axis'). However, it does not clarify the node_id format accepted per the schema (integer, array, or string) or the default-zero behavior of force components.

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 and resource: 'Apply forces/moments at nodes', which clearly conveys the tool's function. It implicitly distinguishes this from sibling load tools like apply_beam_distributed_load or add_plate_element_load by specifying 'nodes', though it does not explicitly name alternatives or contrast with add_nodal_mass.

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 use this tool versus the many sibling load-application tools (e.g., add_initial_tension_load, set_gravity, add_nodal_mass). The description simply states what it does, leaving the agent to infer the appropriate context such as requiring an existing load case.

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

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

The description only restates the action and documents arguments; it does not disclose side effects, whether existing prestress loads are overwritten or accumulated, failure behavior, or prerequisites. Annotations only indicate readOnly=false and destructive=false, so the description was expected to add behavioral context but does not.

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 compact, well-structured docstring with a one-line purpose followed by parameter explanations. Nothing is redundant, though the bilingual repetitions add a little length without diminishing clarity.

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

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

All parameters are covered and the core action is clear, but the description omits preconditions such as the tendon and load case already existing, and it does not describe what happens in the model after application. For a mutating tool with no output schema and no annotations guidance, this leaves an agent to infer important operational context.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining every parameter: units for force (N with a kN example), tension_type code meanings (0=start, 1=end, 2=both), the list-or-string form of tendon_name, and the purpose of group_name. This is strong semantic value beyond the raw 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 clear verb and resource: 'Apply prestress force to tendon(s)' with a matching Chinese gloss. It is specific enough that an agent can identify the operation, but it does not explicitly differentiate from sibling load-related tools such as add_initial_tension_load or add_cable_length_load.

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 about when to use this tool versus alternatives. Sibling tools include other load-application and initial-tension tools, and the description gives no conditions, exclusions, or hints that would help an agent choose among them.

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

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

The description discloses the important destructive behavior: for action 'remove', element_id <= 0 removes all elements. This is valuable because annotations provide no destructiveHint and readOnlyHint is false. It does not describe overwrite semantics or other side effects, which prevents a higher score.

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

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

The description is front-loaded with the core action, then gives essential context, then a structured parameter list. Every line earns its place, including the bilingual annotations which clarify terminology rather than pad the text.

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

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

For a complex 8-parameter tool with no output schema, the description covers all parameters, action modes, the remove-all sentinel, and the relationship to add_check_stirrup. It leaves some ambiguity about which parameters are effectively required per action, though schema defaults partially mitigate this.

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

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

Schema description coverage is 0%, but the description defines every parameter's role, the valid action values, and which stirrup IDs apply to shear vs torsion. It fully compensates for the empty schema and adds meaning well beyond the parameter names.

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

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

The description states a specific verb+resource: 'Assign or remove element stirrups'. It also anchors stirrup numbers to definitions created by add_check_stirrup, which distinguishes this tool from that sibling and clarifies exactly what the tool operates on.

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

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

The description explicitly documents the three action modes ('shear', 'torsion', 'remove') and labels each parameter as shear-only or torsion-only, giving clear context for how to use the tool. It does not name alternative tools for when not to use it, so it stops short of full exclusion 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?

The description only says 'assign', which aligns with the non-read-only annotation but adds no context about idempotency, replacement of previous assignments, or side effects on existing tendon data. Nothing contradicts the annotations, but little behavior 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?

The purpose sentence is front-loaded and the descriptor is compact. The Args block is minimal and mostly earns its place, though it could be folded into a single sentence.

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

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

The one-parameter tool is simple, but the description omits the critical context of which tendon is being assigned and what state is required before calling. Without that, an agent cannot reliably know how to invoke the 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 coverage is 0% and the description only labels ids as Element IDs. It does not explain accepted string formats, the distinction between single and multiple IDs, or how the tendon itself is identified when ids is the only 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: assign elements to a tendon. It is distinct from sibling tendon tools like create_tendon_2d and get_tendon_info, though it does not clarify which tendon is targeted.

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 this tool should be used relative to related tendon tools, nor any prerequisite such as creating a tendon first. The intended workflow 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds a meaningful behavioral fact: it computes without creating a section, i.e., no model mutation. It does not describe return values or error cases, but for a read-only calculation this is acceptable.

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 compact and front-loaded: purpose first, side-effect avoidance second, then exact input formats. Every sentence contributes necessary information, and no filler is present.

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 read-only calculation tool with two parameters, the description provides enough to invoke it correctly: input formats are explicit, and the no-creation behavior is stated. The lack of any return-value description is a minor gap, and the unresolved relationship with 'calculate_section_property' prevents a perfect score.

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 carries the full burden for parameters. It provides concrete structures for both: loop_segments as [{'main': [[x,y],...], 'sub': ...}, ...] and sec_lines as [[x1,y1,x2,y2,width], ...]. This is genuinely useful beyond the schema, though it does not elaborate on details like the meaning of 'sub' loops or coordinate 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 uses a specific verb and resource: 'Compute section properties from raw geometry' and adds the key distinction 'without creating a section', separating it from creation tools. However, it does not differentiate from the nearly identical sibling 'calculate_section_property', which an agent could easily 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?

The description implies usage context: compute properties directly from geometry when no section object should be created. It also explicitly constrains input selection with 'Provide EXACTLY ONE of'. However, it gives no when-not-to-use guidance or named alternatives, and the sibling 'calculate_section_property' is left unaddressed.

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

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

The annotations are all false and thus uninformative; the description adds useful behavioral context: this recalculates across all sections and synchronizes derived section properties after geometry changes. It does not detail side effects like overwriting manual edits, but the recalculation semantics are reasonably clear.

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 short bilingual sentences. The core action is front-loaded and the trigger condition follows naturally. Every sentence earns its place with 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 zero-parameter tool with no output schema, this description is complete: it states what the tool recalculates, the scope (all sections), and when to call it. An agent has enough information to invoke 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?

The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to explain. The zero-parameter baseline of 4 applies.

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

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

Description states a specific action (recalculate) and resource (properties for all sections), with concrete property examples like Area, Iy, Iz, J. It is clear about what the tool does, though it does not distinguish itself from the similarly named sibling calc_section_property.

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

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

The description explicitly says to call this after creating or modifying section geometry to ensure properties are up-to-date. This gives clear context for when to use it, but it does not mention when not to use it or name 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?

The description reveals important behavioral traits beyond the annotations: arguments are validated against the real signature before dispatch, causing wrong parameter names to fail fast rather than corrupting the model. It also discloses that destructive/long-running methods are blocked, adding safety context beyond the generic annotations. This is substantial behavioral transparency with no contradiction to the annotations.

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

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

The description is well-organized with a clear header, guidance, blocklist note, Args section, and example. It is somewhat long due to bilingual text, but every section contributes to correct invocation. The front-loaded purpose and usage guidance help an agent quickly decide and proceed.

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

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

Given the open-ended nature of a generic API call tool, the description provides the necessary context: how to discover signatures via list_qtmodel_api, what parameter formats to use, which methods are blocked, and a concrete example. It does not describe return values, but for an arbitrary API call that is impractical and not expected, and no output schema exists. The description is complete for its purpose.

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

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

With 0% schema description coverage, the description fully compensates by documenting each parameter: api_object has allowed values ('mdb', 'odb', 'cdb'), method is an exact name with an example, and kwargs is a dict matching the real signature. This adds meaning far beyond the bare schema titles.

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

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

The description states a clear verb and resource: 'Call a qtmodel API method not covered by a curated tool'. It explicitly positions itself as an escape hatch, distinguishing it from the curated siblings and making its scope unambiguous. The example further clarifies the intended usage.

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 gives explicit guidance: 'prefer a dedicated tool when one exists', 'Discover the real signature with list_qtmodel_api first', and identifies blocked methods with alternatives ('use initialize_model / run_analysis instead'). This clearly tells an agent when to use this tool and when not to, including named 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?

The 'in view' qualifier adds behavioral context beyond the annotations: it discloses that this operation changes only the displayed stage, not the model's construction-stage data, which meaningfully differentiates it from update_construction_stage. The stage=0 semantics ('0 for Base stage / 0为成桥阶段') further clarify a domain-specific convention. No statement contradicts the annotations (readOnlyHint=false is consistent with a view mutation).

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

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

The description is two concise sentences plus a parameter annotation, with the English purpose front-loaded and the Chinese gloss placed after. There is no fluff, though the bilingual repetition of the same idea is mildly redundant rather than additive.

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 one optional integer parameter, no enums, and no output schema, the description covers purpose, scope (view-only), and the meaning of the special value 0. It is complete enough to invoke correctly, though it omits what happens for an invalid stage ID and the guidance dimension already noted (sibling differentiation) 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 input schema provides only 'integer, default 0' with no description (0% coverage), so the description carries the full burden. It does: 'stage: Stage ID' defines the parameter's role, and '0 for Base stage (0为成桥阶段)' explains the special sentinel value, which the schema omits. This compensates well for the barren 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 and resource: 'Change current construction stage in view', and clarifies this is about display rather than model modification via the Chinese gloss '切换当前显示的施工阶段'. It is clear, but it does not distinguish itself from the near-identical sibling 'switch_display_stage', so an agent cannot tell which of the two to pick without inspecting further.

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 on when to use this tool versus alternatives such as 'switch_display_stage' or 'update_construction_stage'. There are no exclusions, no prerequisites, and no mention that changing the display stage does not alter the model's stage definitions. An agent is left to infer usage from the tool name alone.

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

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

Annotations are all false and provide no safety profile, so the description carries the full burden, and it delivers: it discloses the strict version-pinning behavior of qtmodel and the non-obvious Windows HTTP.sys gotcha that the URL host must be `localhost` rather than `127.0.0.1` through a port forward. This is precisely the kind of platform-specific behavior an agent could never infer from the schema or annotations. No contradiction with the annotations.

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

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

Well-structured and front-loaded: purpose → trigger condition → three statuses with fixes → return values → critical gotcha, with every section earning its place. Mild deduction because the inline Chinese translations roughly double the length, though they are arguably necessary for this user base.

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 0-parameter diagnostic tool with no output schema, nothing an agent needs to invoke correctly is missing: the trigger condition, all three possible statuses with per-status remediation, the return contract, and the port-forward host pitfall are all specified. The description fully substitutes for the absent output schema.

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

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

With 0 parameters, the schema documents everything there is to document, so the baseline is 4. The description adds value by compensating for the missing output schema, naming the four returned components (status, human-readable message, recommended action, client/server versions) and the exact status enum values.

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 ('Diagnose the connection to QiaoTong software') and enumerates the three distinct outcomes (connected, version_mismatch, software_not_running), which makes the tool's scope unmistakable. Among ~150 modeling-focused siblings, it is the only connection diagnostic, so an agent can immediately tell it apart.

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 an explicit, imperative trigger condition — 'CALL THIS FIRST when any tool reports the backend is unavailable' — which is exactly the routing decision an agent faces. It also tells the agent what to do after each outcome (upgrade QiaoTong, start the software and wait), effectively supplying the post-call action plan alongside the when-to-call rule.

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

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

Annotations indicate this is not read-only and not idempotent, so the description need not restate that it changes model state. It adds context about which settings are configured, but does not disclose whether repeated calls overwrite prior settings or how these settings affect subsequent analysis runs.

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

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

The description is well-organized as a compact parameter list with bilingual explanations and no filler. Every line adds meaning, and the summary line is front-loaded.

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?

All five parameters are fully explained, and there is no output schema requiring return-value documentation. The description is incomplete only in that it does not state how this configuration relates to run_analysis or whether settings persist across calls.

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 carries full responsibility for parameter semantics. It explains every parameter, provides Chinese translations, and gives explicit value mappings for solver_type (0=sparse matrix, 1=variable bandwidth), which the schema does not provide.

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

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

The description clearly states the tool configures analysis settings and enumerates the specific settings it controls (construction stage, creep, vibration, solver type). However, it does not explicitly distinguish itself from the related sibling configure_check_analysis or state how it relates to run_analysis.

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 gives no guidance on when to use this tool versus alternatives. It does not mention that it should be called before run_analysis, nor does it contrast with configure_check_analysis or other analysis-related tools.

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