Qiao-MCP

by SorataYang

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.1
Disambiguation2/5
Several tool pairs have overlapping or nearly identical purposes, such as `add_to_structure_group` vs `add_elements_to_group`, `switch_display_stage` vs `change_construct_stage`, and `calc_section_property` vs `calculate_section_property`. The 4-add temperature tools and `get_tendon_info` vs the specific tendon result queries further blur boundaries, making misselection likely.
Naming Consistency3/5
Most tools follow a predictable verb_noun snake_case pattern (create_*, add_*, get_*, update_*), which helps navigation. However, there are notable deviations: `calc_section_property` vs `calculate_section_property`, `add_load_combine` vs `add_load_combination`, `switch_display_stage` vs `change_construct_stage`, the `tapper` typo in `add_tapper_section_group`, and mixed `add_`/`apply_` for loads.
Tool Count1/5
With 132 tools, this server far exceeds the 50+ threshold for an extreme count mismatch. Many are micro-wrappers (e.g. `update_element_material`, `update_element_section`, `update_element_beta`, `update_element_nodes`) that could be consolidated into single parameterized tools, and the presence of a `call_qtmodel_api` escape hatch suggests the curated surface is over-split.
Completeness4/5
The server covers the full bridge modeling workflow: geometry, sections, materials, loads, construction stages, analysis, results, moving loads, and concrete checking. Minor gaps exist — no delete/update for load cases, load groups, materials, or tendons — but the `call_qtmodel_api` escape hatch allows agents to work around these without dead-ending.
Average 3.8/5 across 115 of 132 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 88 commits in the last 12 weeks
- Last stable release on August 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false but do not clarify consequences. The description discloses only that an ID is changed, not whether references to the old ID are updated, whether the new ID must be unique, or whether the change can be reversed. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core action stated first and parameters listed clearly. The bilingual translation is redundant but not harmful. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that changes a node identifier in what appears to be a structural model, the description omits critical context: potential impact on connected elements, uniqueness conflicts, scope of ID rules, and error behavior. With no output schema and sparse annotations, this is insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaning by labeling node_id as the existing ID and new_id as the replacement ID, which is helpful. However, it does not explain validation rules, uniqueness requirements, or what happens if the node does not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Change a node's ID', which clearly distinguishes it from nearby siblings like update_node (property changes) and renumber_nodes (bulk renumbering). It does not mention constraints like uniqueness, but the core purpose is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 renumber_nodes or update_node. There is no mention of prerequisites, intended scope, or cases where a different tool should be preferred, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral context that this is a UI display operation ('Updates the software UI to display the model at the specified stage'), which clarifies it is not a model modification. Annotations are all false, providing limited information, so the description carries some burden but does not discuss side effects, reversibility, or invalid stage handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action, followed by a clarifying sentence and an Args section. The bilingual text adds some redundancy but each sentence serves a purpose, and it is not bloated or verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the core purpose and the parameter name. However, it lacks context about where stage names come from (e.g., previously added construction stages), what happens if an invalid stage is given, and how this tool fits with related siblings like 'change_construct_stage' and 'add_construction_stage'. This makes it minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the undocumented stage_name parameter. It says 'Name of the stage to display', which adds minimal meaning beyond the schema's 'Stage Name' but does not provide valid stages, how to obtain them, or the relationship to construction-stage management tools. This is insufficient compensation for a fully undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Switch' and the resource 'view' / 'construction stage', and explains that the tool updates the UI to display the model at the specified stage. However, it does not differentiate itself from similar sibling tools like 'change_construct_stage' or 'set_view_angle', so it is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 only states what the tool does and does not mention any exclusions, prerequisites, or conditions that would help an agent choose between this and related display/stage tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states that end nodes are replaced, without explaining side effects such as element connectivity changes, validation requirements, whether existing node references are checked, or how the model is affected. Annotations indicate this is a mutable but not explicitly destructive operation, but the description adds little behavioral context beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose. The bilingual argument list is somewhat repetitive but serves to clarify meaning. Every sentence contributes useful information, and there is no significant padding or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no output schema, no return value description, and minimal behavioral context. An agent cannot know whether the operation succeeds silently, whether node IDs must already exist, whether replacing nodes invalidates the element, or what is returned. For a modeling operation with potential structural consequences, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 burden of explaining parameters. It does provide meaningful semantics for all three arguments: element_id is the element to modify, node_i is the new I-end node, and node_j is the new J-end node. This compensates well for the bare integer schemas, though it omits constraints such as node existence or element compatibility.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as replacing the end nodes of an element, with a specific verb and resource. It distinguishes this from generic update_element or update_node tools by specifying I-end and J-end node replacement, 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.
Usage Guidelines2/5
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 update_element, update_node, renumber_nodes, or move_nodes. The description does not state prerequisites, context, or exclusions, leaving the agent to infer appropriate usage from the tool name and argument list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutating operation (readOnlyHint=false) and the description matches by saying 'Create', so there is no contradiction. However, the description does not disclose side effects such as behavior when a section with the same name already exists, coordinate system context, or error conditions. Since the annotations are mostly uninformative false flags, the description carries the burden and adds little beyond the 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the action, followed by a clean Args section. The Chinese translations add some redundancy but improve accessibility for bilingual users, and no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter creation tool, the parameter format is well explained, and the tool is probably callable as-is. But the description omits integration context such as whether a model must be active, whether sections are added or replaced, what units are expected, and what happens on invalid input. It is adequate but not complete, especially with no output schema to describe results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only names and types (0% coverage), but the description compensates well by defining 'name' as the section name and giving an explicit format for sec_lines as [[y1, z1, y2, z2, thickness], ...]. It lacks units and coordinate-system details, so it is not a full 5, but it makes the parameters meaningfully actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'line-width cross-section', with a helpful Chinese translation. It is specific enough to distinguish this from most sibling section tools, but it does not explicitly differentiate it from create_polygon_section or create_section, 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.
Usage Guidelines2/5
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 the many sibling section-creation tools, nor about prerequisites or exclusions. The only implied usage is the tool's name and one-line purpose, which is insufficient given the large set of similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety profile (all hints false), so the description carries the full burden. It says the display is reset but does not disclose whether this affects only the view state, whether it is reversible, or whether it changes visibility/selection settings. A view/reset tool could reasonably be read-only, but the description does not confirm this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a helpful parenthetical clarification. It is appropriately short for a zero-parameter utility, though slightly under-specified in behavioral terms.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-param, no-output-schema tool, the description is mostly sufficient: an agent can infer the basic action. However, it omits usage context and does not clarify whether this is a pure view-state change or a broader display reset, leaving some ambiguity for correct invocation in a large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter information needed in the description beyond acknowledging the operation requires no input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Reset display view', and the Chinese gloss clarifies it restores the default display or shows everything. This distinguishes it from related display tools like display_ids, set_view_angle, and set_render, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 set_view_angle, set_render, or switch_display_stage. The intended use is only implied by the name and description, with no exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only false flags, so they do not convey safety or effect. The description does not disclose whether the operation permanently modifies elements, overrides user-defined orientation values, or is reversible, leaving behavioral impact unclear for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entry is compact and front-loads the action in its first sentence, followed by the args. The Chinese translation duplicates the English text, adding some redundancy, but the overall structure remains tight and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity with a single parameter and no output schema, so the description covers the basics. It remains incomplete around when to apply the tool and what side effects to expect, which is notable given the annotations provide no behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description coverage for 'ids', so the description's 'Element ID(s) to revert' is the only semantic information. It clarifies the parameter's role and allows a list, though it does not specify type or accepted format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('revert') and noun phrase ('local orientation of frame elements'), clearly identifying the action and resource. It is distinguishable from sibling tools like update_element_beta, though it does not explicitly explain what 'revert' entails relative to those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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; there are no prerequisites, exclusions, or references to sibling tools. The description only restates the operation and parameter, leaving the agent to infer the appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no positive hints (readOnlyHint=false, destructiveHint=false, etc.), so the description carries the burden. It only says 'Configure' and lists parameters; it does not disclose side effects such as whether prior buckling settings are overwritten, whether the change persists, or whether a valid construction stage is required. No behavioral context beyond the tool's name is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one clear purpose statement plus a tight Args list. It avoids repeating schema defaults and every line carries useful information, though the indented docstring format is slightly unconventional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with three optional parameters and no output schema, the description explains purpose and parameters well enough for a basic call. However, it omits usage context relative to sibling analysis tools, behavioral effects, and return behavior, leaving gaps for a mutation tool with no annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's bare names. The docstring explains each parameter, e.g., 'Enable buckling analysis' for do_analysis and 'Number of modes to calculate' for mode_count, and clarifies stage_id's '-1 for base model' semantics. This adds meaningful context beyond the schema, though it could include ranges or validity rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Configure buckling analysis settings', a specific verb-resource pair that clearly identifies the tool's function. It names the buckling-specific domain, which distinguishes it from generic siblings like configure_analysis, though it does not explicitly call out that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 configure_analysis or update_construction_stage. The description only states what it does and lists parameters, with no 'use this when' or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description's 'Get' agrees with the readOnlyHint and idempotentHint annotations, but it adds no behavioral context beyond those annotations. It does not disclose return format, error behavior, or whether results depend on prior analysis steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then gives a compact, scannable Args block. There is no filler, and the bilingual labels are directly useful for this API's domain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple two-parameter read-only query, the description adequately explains the inputs and relies on strong annotations for safety. However, with no output schema, it should have sketched what the returned loss results contain or when they become available after analysis, which is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden for parameter meaning. It provides useful labels: 'Tendon name' for name and 'Construction stage ID' for stage_id, which are more informative than the bare schema titles 'Name' and 'Stage Id'. It does not elaborate on stage_id optionality beyond the schema default, but it still adds real semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation and resource: 'Get tendon prestress loss results'. This distinguishes it from sibling query tools like get_tendon_position_result and get_tendon_length_result through the 'loss' resource type, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 related tools such as get_tendon_info or get_special_results. It also does not mention prerequisites like running an analysis first, leaving the agent to infer usage from the verb 'Get'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only indicate this is not a read-only operation, and the description adds little behavioral context beyond that. It does not disclose whether the new ID must be unique, whether dependent references are updated, whether the operation can be undone, or what side effects may occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loads the core action, and includes a clean Args list. Every sentence serves a purpose, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-integer mutation, the description covers the core action and both parameters adequately. However, it omits important operational context such as ID uniqueness, effects on elements referencing the old ID, and how this relates to sibling tools like renumber_elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 defining old_id as 'Existing element ID' and new_id as 'New element ID'. This adds meaningful clarification beyond the bare integer types in the schema, though it does not mention constraints like uniqueness or existence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Change an element's ID'. This clearly identifies the operation and distinguishes it from update_node_id by targeting element IDs specifically. The Chinese annotation reinforces the meaning but does not add ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 renumber_elements or update_node_id. There are no conditions, exclusions, or context signals explaining the preferred scenario for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false/neutral, so the description carries most of the behavioral burden. It explains loop key semantics ('main' for outer, 'sub1'... for hollow loops), which goes beyond the schema, but it does not disclose behavior like overwriting existing sections, coordinate conventions, or validation constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized with a brief summary followed by parameter details and an example. The bilingual text adds slight redundancy but does not harm usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core parameters and loop structure are covered, but there is no output schema and no mention of constraints like whether loops must be closed, minimum point count, or coordinate system context. The example helps, but an agent still lacks some practical details for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 explains each parameter, specifies the loop dictionary structure with 'main' and 'sub' keys, and provides a concrete example using [y,z] coordinate pairs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('create a custom polygon cross-section') with the resource clearly identified. It is distinct from generic section tools like create_section, though it does not explicitly name or contrast sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create_section, create_section_from_properties, or create_tapered_section. The reader must infer that this is for arbitrary polygon shapes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only operation, and the description aligns by saying it saves the current model. It adds the .qtb file format and absolute/relative path behavior, but it does not disclose whether an existing file is overwritten or what happens on success or failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose, followed by a compact Args block. The Chinese parentheticals repeat the English content and add mild redundancy, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter save operation, the essential input is covered and the tool is not complex. However, with no output schema and no mention of return values, overwrite behavior, or failure modes, the description is only moderately complete for an agent deciding how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines file_path as a string with no description, so the description carries the burden of explaining it. It does so clearly: file_path is an absolute or relative path to a .qtb file. This meaningfully compensates for the 0% schema coverage, though it could include examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Save'), the resource ('the current model'), and the destination ('a file' with .qtb extension). It is specific enough to identify the tool's job, though it does not explicitly contrast it with siblings like open_model_file or save_model_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions. The description defines the operation but leaves the tool-selection decision entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations describe a non-read-only, non-idempotent mutation, and the description's 'creates' claim is consistent with them (no contradiction). The description adds some behavioral context: it is a composite one-step operation that auto-generates supports (fixed at piers, movable at ends) and a self-weight load case, and requires pre-existing material/section. However, it does not disclose repeated-call consequences, duplicate naming behavior, or what happens when prerequisites are unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is logically ordered and the main action is front-loaded, and the Args block earns its place given zero schema coverage. However, every statement is duplicated verbatim in Chinese, roughly doubling length without adding information for an English-reading agent, which is avoidable bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter, no-output-schema, composite bridge-creation tool, the description explains what model geometry is generated, the support conditions, the load case, and key prerequisites. Gaps remain: no stated return value, no behavior on repeated calls, and the spans example's '均匀布置' (uniformly arranged) wording is slightly inconsistent with the non-uniform [30, 50, 30] values it illustrates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 its Args section compensates well: spans gets units (meters) plus a concrete example ([30.0, 50.0, 30.0] = 3-span), num_elements_per_span and self_weight_case get plain-language meaning, and material_name/section_name get the 'must already exist' precondition. It only lacks finer constraints such as a minimum span count or ordering rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: "One-step creation of a continuous beam bridge model," and elaborates the structural configuration (multi-span continuous beam, fixed supports at piers, movable supports at ends). This implicitly differentiates it from the sibling create_simple_beam_bridge, but it never names that alternative or states the difference explicitly, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: an agent can infer this tool is for multi-span continuous beam models as opposed to simple beam models among the siblings. It discloses prerequisites inside the parameter docs (material and section must already exist, '须已创建'), which is useful gate-keeping, but there is no explicit when-to-use vs. alternative guidance and no stated exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate not read-only and not destructive, and the description simply restates that it creates a material. There is no disclosure of side effects, required preconditions, validation behavior, or what happens on invalid input. With no annotations providing safety context, the description should carry more behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then efficiently lists parameter semantics. The bilingual repetition adds some length but remains structured and scannable. Every sentence carries useful information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward creation tool, the description covers the essential invocation details: all parameters, the enum meaning for mat_type, and the custom properties requirement when mat_type=5. It lacks a short usage example or clarification of how standard and database interact, but is otherwise complete for a 5-parameter tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only titles with no descriptions, and schema coverage is 0%. The description compensates fully by explaining every parameter, including the enum values for mat_type, the default behavior of standard, the meaning of database (with examples), and the exact structure of data_info for custom materials. This is far beyond what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Create a material in the bridge model'), which clearly identifies the operation. It does not explicitly differentiate this from sibling tools like create_section or create_polygon_section, but the resource 'material' is distinct enough from sections and elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 are exclusions or prerequisites mentioned. The description implies it is for creating materials with standard databases or custom properties, but an agent gets no help deciding between this and related creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond the read-only getter semantics, such as coordinate frame, units, or what happens if the tendon name does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and front-loaded: one purpose line plus one parameter gloss. No redundant prose, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description does not explain what is returned (coordinate values, units, format) or when results become available. An agent can call the tool but cannot confidently interpret or validate the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 clarifies that 'name' means 'Tendon name (钢束名)', which resolves the parameter's role, but it does not explain how names must match existing tendons or any format constraints. Minimal but acceptable for one simple string parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb 'Get' and a specific resource 'tendon position/coordinate results', which clearly distinguishes it from sibling tendon result getters like get_tendon_loss_results and get_tendon_length_result. The Chinese gloss reinforces the meaning without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no when-to-use guidance or alternatives. An agent is not told when to pick this over get_tendon_info, get_tendon_length_result, or get_tendon_loss_results, nor whether an analysis or model must exist first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no meaningful behavioral hints (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description must carry the burden. It does disclose that calling without IDs renumbers all nodes from 1, which is useful, but it does not describe what happens when IDs and new_ids are partially provided, how duplicates are handled, or any side effects on dependent entities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the core behavior stated immediately and the parameter meanings summarized in a compact Args block. The bilingual repetition is mildly redundant but does not harm clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and no output schema, the description covers the main scenario well but leaves important edge cases unstated, such as partial renumbering semantics, relationship between ids and new_ids, and potential constraints like requiring a loaded model. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 labels ids as 'List of node IDs or string format (可选，原节点号)' and new_ids as 'List of new node IDs (可选，新节点号)', which adds some meaning beyond the empty schema. However, it remains ambiguous whether the lists must have equal length, what happens if only one is supplied, and what string formats are accepted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Renumber nodes' with an explicit behavior for the no-IDs case: renumber all nodes starting from 1 continuously. The resource is specifically nodes, which distinguishes it from the sibling tool renumber_elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives one conditional usage note ('If no IDs are provided, renumbers all nodes starting from 1 continuously') but does not explain when to choose this tool over related siblings such as update_node_id, merge_nodes, or renumber_elements. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation/non-destructive profile is covered. The description adds a useful behavioral detail by specifying that the gravity applies to self-weight, but it does not disclose side effects, persistence, or scope beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. The Args block is useful, though the Chinese translation is slightly redundant for an AI agent consuming the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-parameter simple setter tool with no output schema, the description is largely complete: it names the effect (self-weight gravity), units, and default. Missing usage guidance is a minor gap but not crippling for such a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description's Args block compensates well: it defines gravity as gravitational acceleration in m/s² and notes the default 9.8. This adds semantics beyond the bare schema type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Set the gravitational acceleration used for self-weight.' This clearly conveys what the tool does and is specific enough to distinguish it from most sibling tools, though it does not explicitly compare itself to related tools like set_self_weight_stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. With many sibling tools in the same domain, the agent receives no routing information beyond the basic purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses a useful behavior: sec_property is option and, if omitted, a basic list with Area, Ix, Iy, Iz is auto-generated. With all annotations false, the description carries the safety/behavior burden, yet it does not mention side effects such as overwriting an existing section, units, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring is structured and front-loaded with the action, followed by a concise Args list. The bilingual duplication adds length but every line carries meaning; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema, the description covers the core action and all parameter meanings, plus the option-behavior. Missing details include units, name-collision behavior, and the full contract of the 29-item property list, so completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 defining each parameter including Chinese meanings, and explains sec_property's up-to-29 list and default fallback. It does not clarify the exact relationship between the individual required fields and a supplied sec_property, nor units, so it is not perfect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Create a section') and narrows the method to 'pre-calculated properties', which sents it apart from geometry-based section tools like create_polygon_section. It does not explicitly name sibling tools, so differentiation is partial rather than fully explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'directly from its pre-alculated properties' implies the intended context: when section properties are already known rather than computed from geometry. However, there is no explicit guidance on when to choose this over siblings like create_section or update_section_property, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description stays consistent by saying 'Delete one or more sections.' It adds that deletion is scoped to section IDs, but it does not disclose whether deletion is permanent, what happens to elements referencing deleted sections, or any cascading effects. This is moderate added context, not full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. The Chinese translations in parentheses duplicate the English text, and the Args block repeats the same information, but there is no filler or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool with no output schema, the call mechanics are mostly covered: what to delete and how to format ids. However, it leaves out destructive consequences and the distinction from remove_unused_sections, so an agent invoking it on a real model is missing safety-relevant context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates. It explains that ids are section IDs and, crucially, that the string variant is a range like '3to5' — a detail the schema's plain anyOf string would not reveal. This is strong added semantics for the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Delete one or more sections from the model.' It is unambiguous about the operation, but it does not explicitly differentiate itself from the close sibling remove_unused_sections, relying instead on the 'ids' parameter to imply user-selected sections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that it deletes specific sections by ID as opposed to remove_unused_sections, nor does it state any prerequisites or consequences that would help an agent choose it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no meaningful safe/read-only context beyond all-false flags, so the description carries the burden. It states the creation action but does not disclose side effects, prerequisites, whether repeated calls overwrite existing cases, or how the check case is registered in the model. This is thin for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, then organized as an Args list. Each line is informative; the bilingual repetitions are slightly redundant but do not waste much space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All parameters and the basic purpose are covered, but with no output schema and weak annotations, the description is missing important operational context: when this should be called relative to run_concrete_check, whether structure groups must already exist, and what the tool returns or changes. It is adequate but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero property descriptions, so the description fully compensates by explaining every parameter: name, standard with its coded values, structure_type with its coded values, and group_name. This is the only source of semantic meaning for the parameters and it is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Create a concrete structural check case', which clearly distinguishes it from sibling tools like run_concrete_check and configure_check_analysis. The bilingual phrasing and parameter list reinforce exactly what object is being created.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to call this tool versus alternatives, nor any sequencing hints such as 'call before run_concrete_check' or 'requires an existing structure group'. The context of when it should be used is only implied by the name and the list of siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that this is not read-only and not destructive, but the description adds no behavioral context beyond restating the operation. It does not clarify that display units are a UI-level setting, whether the setting persists, or whether it has any side effects on model data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and contains no filler. Each sentence earns its place by either stating the operation or clarifying the accepted unit values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with two optional parameters and no output schema, the description is largely complete and includes the essential examples needed to invoke the tool correctly. The only notable gap is the missing usage context, which is already penalized under usage guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly documents both parameters with concrete examples: KN/N/TONF for force and M/MM/CM for length. This compensates for the sparse schema and provides actionable value for choosing valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Set') and resource ('display units'), and the bilingual wording eliminates ambiguity. It clearly distinguishes from sibling tools like set_render or set_view_angle because it targets units rather than visual rendering or camera state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to call this tool, whether it affects the current model globally, or how it relates to any alternative tools. An agent must infer the intended usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral detail that an empty string returns all tendons, which is useful, but it does not disclose return format, ordering, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 clear parameter explanation. Every sentence earns its place, and the bilingual addition mirrors the parameter semantics without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description gives enough context to invoke it correctly. It could be slightly more complete by noting that more specialized tendon queries (losses, position, length) live in sibling tools, but this is not essential for calling the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description fully compensates for the single parameter by explaining that tendon_name is either a specific tendon name or an empty string for all tendons. This is meaningful beyond the schema's default value, though it omits minor details such as case sensitivity or behavior for unknown names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource ('Get tendon geometry and prestress loss results') and explains the tendon_name parameter, making the tool's intent clear. However, it does not differentiate itself from siblings like get_tendon_loss_results or get_tendon_position_result, so an agent may hesitate about which read tool to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call when you need tendon geometry and/or prestress loss results, and use an empty tendon_name to get all tendons. But it provides no explicit guidance about when to choose this tool over get_tendon_loss_results, get_tendon_position_result, or get_tendon_length_result, and states no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false hints and provide no behavioral disclosure, so the description carries the burden. It does disclose file resolution priority and save-as behavior, but it does not mention overwrite semantics, what happens when the file does not exist, or whether the current check case is mutated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and the Args block is compact, with each parameter explanation earning its place. The bilingual duplication is slightly redundant but not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the parameter behavior is well covered. Still missing are return/error behavior and explicit guidance distinguishing this from model-file and check-stirrup siblings, which leaves selection context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema contains 0% description coverage, yet the description fully documents all three parameters: action values, name's default-directory behavior, and file_path's priority or save-as meaning. This adds substantial meaning that the schema alone does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Open or save a concrete check case file', using specific verbs and a concrete resource. It is clear enough to distinguish from model-level file tools like open_model_file/save_model_file, though it does not explicitly name those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains how to choose between 'open' and 'save' and how file_path/name interact, which is useful invocation guidance. However, it never states when this tool should be used instead of alternatives such as open_model_file, save_model_file, or manage_check_stirrup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the core safety profile: destructiveHint=true and readOnlyHint=false. The description adds the useful 'unused only' qualifier, telling the agent that in-use sections are spared. However, it does not disclose what counts as 'unused' (e.g., no element references), whether the operation is reversible, or the post-condition of the model. Some context beyond annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that leads with the action verb. The only imperfection is the redundant Chinese parenthetical that repeats the English meaning verbatim, adding no information but negligible bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description plus annotations cover what an agent needs to invoke it: it removes unused sections and is destructive. The main residual gap is the undefined criteria for 'unused' sections, but the tool's simplicity keeps this from being a serious omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is nothing for the description to document regarding arguments, and no parameter semantics are needed beyond the schema's empty properties object. The description correctly imposes no arg expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Clean up and remove all unused sections from the model'. The qualifier 'all unused' clearly differentiates it from the sibling remove_section, which targets a specific section. An agent can tell this is the bulk-cleanup tool without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over alternatives like remove_section or when to avoid it. The implications that it is for post-modeling cleanup, but no explicit context, preconditions, or exclusions are provided. The agent must infer the selection rule 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the primary effect (setting the 3D view angle) and explains the custom-mode condition, but it does not disclose whether the change is viewport-only, persists across operations, or affects the saved model. With all Hints false, the description carries the burden; this is adequate for a simple view setter 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the purpose, and organized by parameters. The bilingual repetition adds a little length, but every element earns its place and no fluff is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three optional parameters and no output schema, the parameter details are complete. However, the description omits tool-selection context, behavioral side effects, and any interaction with related display tools, leaving an agent to infer when and how to integrate this with other operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It enumerates all valid angle_preset values, explains their meaning, clarifies that horizontal/vertical apply only to 'custom', and provides bilingual labels. This is more than enough for an agent to construct valid arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Set the 3D view angle of the bridge model.' This clearly distinguishes the tool from display-related siblings like reset_display and set_render, and the multilingual phrasing reinforces the intent without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any exclusion criteria or prerequisites. The only usage hint is parameter-level ('Set to custom to use horizontal/vertical rotation'), which does not help an agent choose this tool over sibling display or view tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations are all false and don't characterize behavior richly, so the description has to carry some burden. It adds useful facts: new_id=-1 keeps the old ID, ele_type uses a 1-4 numeric mapping, and beta_angle is in degrees. However, it doesn't disclose what happens when changing topology-related fields like node_i/node_j, whether invalid IDs cause errors, or whether repeated identical updates are safe. It is neither misleading nor contradictory, but it communicates parameter mechanics more than side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose sentence is front-loaded, followed by a clean Args block in a consistent format and a compact example. The bilingual text adds some length but serves the likely mixed-language user context, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and 0% schema-level descriptions, the text does a strong job of making the tool callable. The main gaps are that it never explicitly states 'omitted optional arguments leave that property unchanged' (only implied by defaults) and it doesn't mention the specialized sibling alternatives. These are moderate omissions for a multi-purpose mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 given a human-readable explanation, the ele_type enum values are spelled out, beta_angle units are stated, and the -1 default behavior of new_id is explicit. The example also demonstrates the intended partial-update calling pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb-resource pair: 'Modify an existing element's properties' and lists what properties can be touched, so an agent knows what the tool does. However, it does not differentiate from the several specialized siblings (update_element_material, update_element_section, update_element_beta, update_element_nodes), so the generic vs. specific choice is left ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example call but no guidance on when to use this generic update_element versus the specialized update_element_* siblings. It never says 'use this to change multiple properties at once' or 'use update_element_material for material-only changes'. The intended usage must be inferred from the parameter list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the sentinel behavior for unchanged values (None for coordinates, -1 for ID) and includes an example, which adds useful context beyond the annotations. However, it does not mention side effects, ID conflict behavior, coordinate units, or whether the modification is in-place, though the annotations (all false) do not contradict the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-line summary, an Args block, and a relevant example. The bilingual text adds slight redundancy but remains efficient; every sentence serves a purpose with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter tool with no output schema and no schema-level descriptions, the description covers all invocation-critical details: parameter meanings, default behaviors, and a concrete example. It stops short of describing return values or potential errors, but this is not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 all parameter meaning. It fully explains every parameter: node_id is the existing ID, x/y/z are new coordinates with None meaning unchanged, and new_id uses -1 to mean unchanged. The example further clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Modify') and resource ('an existing node'), and specifies the two modification targets: coordinates and ID. It is specific enough to identify the tool's function, though it does not explicitly distinguish itself from sibling tools like update_node_id or move_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as update_node_id, renumber_nodes, or move_nodes. The usage context is only implied by the modification semantics; there are no exclusions or alternative routing cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no effective behavioral disclosure since readOnlyHint, openWorldHint, idempotentHint, and destructiveHint are all false. The description only says 'update', but does not explain side effects, whether it modifies the current tendon or creates one, how unspecified defaulted parameters are handled, or what happens if called repeatedly. For a mutating tool without meaningful annotations, the description carries a heavy burden and does not meet it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized: a one-sentence purpose statement followed by a parameter list. It is front-loaded and easy to scan. The bilingual repetition adds some redundancy, but it serves a real audience and does not make the description unwieldy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All five parameter semantics are covered, and the purpose is clear, which makes the tool minimally invocable. However, the description does not explain which tendon is affected, whether the update applies globally or to a selection, what happens when optional parameters are omitted, or what the expected result is. Given no output schema and no useful annotations, these gaps leave the tool less than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 document parameters, and it does. Every parameter is explained with units and practical examples: area in m² with the 0.000804 = 804mm² equivalence, effective_prestress in Pa with 8e8 = 800MPa, and fpd as design tensile strength. This adds substantial meaning that the raw schema completely lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Update vertical prestress tendon parameters for checking'. It clearly identifies the operation as a parameter update on vertical prestress tendons, which distinguishes it from siblings like create_tendon_2d, add_tendon_3d, apply_prestress, and update_section_property. The bilingual text reinforces the intended meaning without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for checking' implies this tool belongs to a prestress checking workflow, giving some usage context. However, it does not explicitly state when to use it instead of related tools like create_tendon_property or apply_prestress, nor does it mention prerequisites such as requiring an existing vertical tendon or a loaded model. The context is implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description's 'Create' matches the annotations' non-readOnly, non-idempotent hints, so there is no contradiction. However, it adds no behavioral detail beyond the creation claim, such as duplicate-name handling, return value, or whether the group is created empty. Because the annotations provide little safety context, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, action-first, and includes the key parameter explanation without filler. The bilingual restatements add some redundancy but are short and may improve clarity for the intended audience.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter create tool with no output schema, the description covers what the tool does, when it is used, and what its only parameter means. It could mention return values or duplicate behavior, but those gaps are minor at this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must carry parameter meaning. The 'Args' section defines 'name' as the boundary group name with a Chinese equivalent, which is minimal but sufficient for the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource ('Create a boundary condition group') and adds a useful explanation that boundary groups collect supports/links for stage-controlled activation/deactivation. It does not explicitly compare itself with sibling creators like create_load_group or create_structure_group, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The construction-stage context gives a clear signal for when this tool is relevant: when boundary conditions need to be grouped for activation/deactivation together. It does not list exclusions or name alternatives, but the use case is specific enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating, non-idempotent operation. The description adds context about construction-stage activation, but does not disclose behavior around duplicate group names, whether element IDs must already exist, or what the tool returns on success or failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a clear first sentence, a one-line purpose context, and a concise Args block. The Chinese translations are redundant but not harmful; every English sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter creation tool with no output schema, the essential invocation details are present: name, optional element IDs, and the accepted range-string format. However, it omits important operational context such as duplicate-name behavior, whether elements must pre-exist, and how to add elements later, leaving an agent to infer some failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 burden. It documents name as the structure group name and element_ids as 'int list or range string like 1to20', providing format guidance beyond the bare anyOf in the schema. It stops short of explaining constraints like range inclusivity or duplicate handling, but is still genuinely helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: 'Create a structure group and optionally assign elements to it.' It also explains the purpose in construction-stage analysis, which distinguishes it from sibling tools like update_structure_group_name, remove_structure_group, and create_boundary_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The construction-stage context implies when structure groups matter, and the optional element_ids parameter implies you can create an empty group or one with elements. However, it never explicitly says when to use add_to_structure_group or add_elements_to_group for existing groups, nor does it state any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-readOnly, non-idempotent, non-destructive operation, so the description does not need to repeat that. It adds the prerequisite that two sections must already exist, but it does not disclose what happens after creation, whether anything is overwritten, or how the tapered section is stored or applied. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-sentence purpose followed by a tidy Args block. Bilingual text adds length, but each parameter is on its own line and easy to scan. It could be tightened by removing the Chinese duplication, but it remains well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition fully documents all input parameters and states the high-level operation, which is sufficient for basic invocation. However, with no output schema and no mention of return values or downstream model effects, an agent cannot predict what the call will produce or whether additional steps are needed to use the tapered section.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 providing semantic glosses for all five parameters, including the default behavior of shear_consider and sec_normalize. This adds meaningful value beyond the bare schema, though the explanations are somewhat shallow—e.g., no ID format or validation details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Create a tapered section from two existing sections.' The 'from two existing sections' qualifier clearly distinguishes it from other section-creation siblings like create_section or create_polygon_section, so an agent can identify this tool's unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context by requiring two existing sections as inputs, but it does not explicitly state when to choose this tool over alternatives such as create_section or add_tapper_section_group. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured metadata. The description adds the set of valid group_type values but does not disclose behavior such as what happens for nonexistent groups or what data the returned member list contains. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the purpose, and contains no wasted content. The Args block concisely clarifies both parameters without verbose or redundant explanation. The bilingual note adds clarity without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing operation with only two required parameters, the description plus annotations provide enough information to invoke the tool. The absence of an output schema is mitigated by the clear 'List members' phrasing, though a note about the exact return format would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 semantic load. It provides meaningful explanations for both parameters: group_type is defined with the allowed values 'structure', 'boundary', and 'load', and name is identified as the group name. This goes beyond the bare schema but could add more detail about name lookup or formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List members') applied to a clear resource (structure/boundary/load group) and enumerates the allowed group types. This clearly distinguishes the tool from sibling group-management tools like add_elements_to_group, remove_from_structure_group, and create_structure_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of alternatives such as get_model_data, find_entities, or other group-related queries. The intended context is only implied by the name and description, with no when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly includes a 'remove' action, which is a destructive operation, but annotations declare destructiveHint=false. This is a direct contradiction between the description and the structured annotation, so the score must be 1. Apart from that, it does usefully disclose internal meter conversion and the ID<=0 name-matching rule, but the contradiction dominates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then the creation-tool pointer, then a units note, followed by a complete Args block. It is longer than strictly necessary because it is bilingual, but the bilingual content is not pure padding and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no output schema, the description should clarify which fields are needed for 'update' versus 'remove', what happens when both stirrup_id and name are supplied, and what the call returns or whether removal is irreversible. It does not address these, leaving meaningful gaps for an agent deciding how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 thoroughly. Every parameter gets a Chinese/English meaning, units are specified in meters, stirrup_type codes are decoded as 1=normal/2=spriral, and the ID<=0 match-by-name behavior is explained. This is exactly the semantic value the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Update or remove a stirrup definition', and it names the sibling add_check_stirrup as the creation tool. This lets an agent distinguish it from add_check_stirrup and assign_element_stirrup without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use add_check_stirrup to create one' and repeats this in Chinese ('新增请用 add_check_stirrup'), which tells the agent when not to use this tool. This is direct when/when-not guidance that routes to the correct sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, and the description aligns by saying 'remove.' It adds useful context by clarifying the operation targets group membership rather than the group itself or the underlying nodes/elements. However, it does not disclose what happens if the group does not exist, if both node_ids and element_ids are omitted, or whether the operation fails silently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by a clean Args list. The bilingual text adds some length but is not wasteful and helps clarify meaning. Every component contributes value, though the Chinese repetition slightly increases verbosity without adding new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive utility with no output schema and sparse input schema, the description covers the operation and parameters well. However, it omits important usage constraints such as needing at least one ID list, behavior when no IDs are supplied, and whether the group must already exist. These gaps make the definition functional but not fully complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions and leaves node_ids/element_ids untyped, so the description's Args section carries the burden. It compensates well by explaining that node_ids and element_ids support int, list, or range string, and by labeling group_name as the structure group name. It could add detail on the exact range string format, but the coverage is strong given 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Remove nodes and/or elements from an existing structure group.' This clearly distinguishes the operation from sibling tools like remove_structure_group (which deletes the whole group) and remove_nodes/remove_elements (which likely remove entities from the model rather than from a group).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from an existing structure group' implies that this tool is for modifying an existing group's membership rather than creating or deleting a group. However, it does not explicitly state when to choose this over add_to_structure_group or remove_structure_group, nor does it mention that the group must already exist or that at least one of node_ids/element_ids should be provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavior beyond the annotations: omitting the name removes all structure groups, a critical destructive edge case. The destructiveHint=true annotation already flags destructiveness, but the empty-name behavior is valuable context that the schema alone does not convey. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the main behavior stated first and the parameter clarification following in a clean Args section. The bilingual text is slightly redundant but not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool, the description is complete enough: it states what is removed and the critical all-removal behavior. No output schema exists, but a removal tool of this kind does not necessarily require return-value details. It avoids over-specifying and covers the essential edge case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 fully explains the only parameter, including the default behavior of removing all groups when name is empty. This adds real meaning beyond the schema's simple string type and default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove) and resource (structure group), and clarifies the optional-name behavior. It does not explicitly differentiate itself from the sibling remove_from_structure_group, but the phrasing makes the target resource unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives such as remove_from_structure_group, remove_section, or remove_elements. The description implies use for deleting groups, but does not state exclusion conditions or point the agent to a sibling for related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as a mutation (readOnlyHint=false) but provide no further context. The description adds per-DOF meaning and defaults, which is helpful, but it does not disclose whether existing supports are overwritten, how group_name is treated, or any side effects. This is a partial improvement over annotations rather than a full behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line purpose followed by a clean Args list. Every parameter earns its place, and the bilingual text is efficient. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8 parameters, 0% schema coverage, no output schema, and minimal annotations, the description adequately covers parameter semantics but omits key operational context: whether it replaces or accumulates supports, whether group_name must already exist, and any prerequisites or return behavior. It is usable but not complete enough for an agent to anticipate all consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 of explaining parameters. It does so thoroughly: node_id's accepted forms (int, list, range string like '1to10'), the meaning and default for each of the six DOF flags, and group_name's purpose. This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Set support boundary conditions on nodes'. This clearly differentiates it from related sibling tools like add_elastic_support or add_support_settlement, and the bilingual phrasing leaves no doubt about the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With siblings like remove_boundary, add_elastic_support, and add_support_settlement nearby, the description offers no exclusions or selection criteria, leaving the agent to infer usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is a non-read-only mutation, and the description's 'Change' wording is consistent with that, so there is no contradiction. It adds minor context about overwriting element material but does not disclose side effects, failure behavior, or validation details beyond referencing get_materials. Given that annotations cover the mutation/safety profile, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured with an Args section and an example, and every sentence provides useful information. The bilingual repetition adds a little length, but the core guidance is compact and the example is directly relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool, the description covers the essential input formats and tells the agent where to find valid material IDs. It does not mention return values or error handling, which is a minor gap given there is no output schema, but an agent has enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% description coverage and ids has no declared type, so the description carries the full burden. It clearly defines the accepted id forms (int, list, or range string '1to50'), explains that mat_id is a new material ID, and references get_materials for valid values. The example reinforces the parameter semantics with a concrete call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear operation: changing the material of one or more elements, which is more specific than the bare tool name because it adds scope and the Chinese gloss. It distinguishes the target (material) from sibling update_element_* operations such as update_element_section or update_element_beta, though it does not explicitly name any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when an element's material needs to be changed, and it provides a useful prerequisite by directing the agent to use get_materials to find valid material IDs. However, it does not explicitly state when not to use this tool or compare it with alternatives like update_element or update_element_section, leaving usage guidance mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds little behavioral detail beyond the tool's read-only purpose, but it does not contradict the annotations and is consistent with a side-effect-free getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The English description is a single efficient sentence. The parenthetical Chinese translation is redundant for an AI agent selecting a tool, but it does not add meaningful clutter. The essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only getter with strong annotations, the description sufficiently communicates what the tool returns. No output schema exists, but the purpose is straightforward and the expected result type is clear from the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the parameter semantics are fully covered by the empty input schema. The description does not need to explain parameters, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get'), a specific resource ('tendon length results'), and a clear scope ('all'). This distinguishes it from sibling tools like get_tendon_loss_results and get_tendon_position_result, which target different result types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the name and description: call this when you want all tendon length results. However, it does not explicitly contrast with related tendon-result tools or state when not to use it, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already expose destructiveHint=true and readOnlyHint=false, so the destructive nature is structurally known and the description matches rather than contradicts them. The description adds only a scoping trait ('specific' boundary rather than all boundaries) and the family of boundary types affected; it does not disclose what happens on a missing boundary, whether removal is permanent, or how extra_name/group_name disambiguate identical remove_ids. It adds some context but remains thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, and the Args block is well organized into per-parameter bullets. The ten-item kind list is long but earned because the schema defines no enums, and the bilingual content is functional since Chinese tokens are accepted inputs rather than decoration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and zero schema descriptions, this description is the sole carrier of semantics, and it covers the purpose, all four parameters, and every accepted kind — enough to place a correct call in the common case of removing a previously added boundary. The missing piece is outcome/error behavior: whether a non-existent boundary errors or no-ops and whether removal is immediately reflected in later analysis results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 and largely delivers: remove_id is explained as node/element/master-node depending on kind; kind is fully enumerated with both English tokens and Chinese aliases (support/一般支承 through constraint_equation/约束方程); extra_name's conditional semantics are specified (I/J end for elastic links, equation name for constraint equations). The weak spot is group_name, which receives only a bare label without guidance on when it must be supplied for disambiguation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line 'Remove a specific boundary condition' names a specific verb and resource, so it is not a tautology of the tool name. The body enumerates ten distinct boundary kinds (support, elastic_support, elastic_link, master_slave, etc.), which cleanly differentiates it from the add_* boundary siblings and from remove_section / remove_structure_group / remove_nodes, which target different entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The kind enumeration implies the tool's domain: anything previously created by set_support, add_elastic_support, add_elastic_link, add_master_slave_link, add_beam_constraint, or add_constraint_equation. However, there is no explicit when-to-use vs. alternatives guidance, no exclusions (e.g., prefer remove_structure_group to drop a whole group, or remove_nodes/remove_elements to delete entities), and no prerequisites such as needing group_name when IDs collide across groups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations by stating that omitting IDs causes all elements to be renumbered continuously starting from 1. It does not disclose potential side effects on references or what happens with partial ID mappings, but the default behavior is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating the purpose, default behavior, and parameter semantics in just a few sentences. Every part contributes useful information with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main operation and default behavior but leaves important calling details unresolved, such as the mapping between element_ids and new_ids and the effect of providing only one list. For a tool with two optional parameters and no output schema, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by labeling element_ids as original IDs and new_ids as new IDs, and noting both are optional. However, it does not clarify the required relationship between the two lists, such as whether they must be parallel, what happens when only one is provided, or constraints on the new IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Renumber elements') and explains the default behavior when no IDs are provided. This distinguishes it from sibling tools like renumber_nodes and update_element_id by focusing on element IDs and batch renumbering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for renumbering element IDs, especially in contrast to renumber_nodes, but it does not explicitly state when to prefer this over update_element_id or other related tools. There is no explicit when-to-use or when-not-to-use guidance, leaving the agent to infer context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the burden. It discloses that this is a low-level raw-array creation routine and hints it is error-prone for beams by pointing to easier alternatives. However, it does not state prerequisites such as existing nodes/materials/sections, whether elements are appended or overwritten, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then usage preference, then structured bullet formats. The bilingual type-code sentence is slightly redundant, but the content is otherwise tight and well-orgnized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex bulk-creation tool with no output schema and empty item schemas, it provides enough to construct the argument array. It omits prerequisites, return behavior, and validation behavior, which are meaningful gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% because element_data items are empty arrays, and the description compensates with detailed list formats for beam/truss, cable, and plate including type codes. It does not define every field such as beta, initType, or tensionType, but the field names are mostly self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Create elements') and resource ('raw data array'), enumerates supported element types (beam, truss, cable, plate), and names sibling alternatives for beam elements. This makes it distinguishable from create_beam_element and create_beam_elements_linear without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises preferring create_beam_element or create_beam_elements_linear for beam elements, giving a clear when-not-to-use signal. It does not explicitly state 'use this for cable/plate/bulk raw data', but the raw-array intro and format list imply those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the operation changes display state rather than model data, and the annotations already indicate it is not read-only and not destructive. It does not go deeper to state whether the change persists, whether it affects the current view only, or what happens when both flags are false; but this is minor for a simple display toggle.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose, and the parameter explanations are clear. It loses a point only for the bilingual repetition, which adds length without new semantic content for an English-only agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 booleans and no output schema, the description plus schema provide core knowledge: purpose and per-parameter semantics. It is not a 5 because it does not explicitly address omission behavior or interaction between the two flags, though the schema defaults partially cover this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 the two optional booleans. It fully compensates by explicitly stating 'True to show node IDs, False to hide' and the same for element IDs, which is exactly the semantic information an agent needs beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Toggle') and a precise resource ('the display of node and element IDs'), making the tool's purpose immediately unambiguous. It is also clearly distinct from sibling view-related tools such as set_render, reset_display, and set_view_angle, since no sibling targets ID visibility specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the description: call this tool when you want to show/hide node or element IDs. However, there is no explicit guidance about when to prefer this over display-related siblings, nor 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context by specifying the scope ('current bridge model') and enumerating the entity categories counted, which goes beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the primary action and resource. The bilingual text repeats the same content, which is somewhat redundant for an English-language agent but not harmful; overall it remains concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with no output schema, the description fully explains what the agent can expect: a summary of entity counts for the current bridge model. Nothing essential is missing for selecting and invoking this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. The baseline for 0-parameter tools is 4, and the description correctly focuses on the output rather than input, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get a summary'), a specific resource ('current bridge model'), and the exact output ('counts of all model entities'). It distinguishes itself from siblings like get_model_data and find_entities by specifying that it returns summary counts rather than detailed data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any explicit guidance on when to use this tool versus alternatives such as get_model_data or get_analysis_results. There is no mention of exclusions, prerequisites, or selection criteria; usage is only vaguely implied by the word 'summary'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not marked idempotent or destructive, so the description does not need to re-state those. It adds useful context about coordinate offsets and supported ID formats, but it does not disclose potential side effects, coordinate system assumptions, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise summary, parameter list, and example. The bilingual repetitions add some length but remain helpful for multilingual users and do not obscure the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple mutation tool, the description provides enough information to call it correctly: ID formats, all three offsets, default behavior via schema, and a representative example. It does not mention return values or error conditions, but those are not critical for a move operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 explains each parameter: ids accepts int, list, or '1to10' range strings, and offset_x/y/z are defined as offsets in model units with a clear example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear verb and resource: 'Move nodes by an offset', which precisely distinguishes this translate operation from sibling tools like update_node, renumber_nodes, or merge_nodes. The bilingual label and example reinforce the exact behavior without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when nodes need to be translated by X/Y/Z offsets, and the example illustrates a concrete scenario. However, it does not explicitly address when to choose this tool over alternatives such as update_node, nor does it state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the agent is warned that opening may alter or replace current state. The description itself adds no further behavioral context, such as whether the current model is replaced or unsaved changes are lost, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is compact and front-loaded: one sentence states the core action, and one line documents the single parameter. The bilingual phrasing adds clarity without meaningful redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The essential input is documented, but the description does not explain the resulting state change, such as the opened model becoming the active model for subsequent API calls, nor the destructive consequence implied by the annotation. With no output schema, this lightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only says 'File Path' with no description, so the description's 'Absolute or relative path to the .qtb file' carries the entire semantic burden and fully specifies how file_path should be provided. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') and resource ('existing model file') and identifies the .qtb format, clearly distinguishing this loading operation from siblings like initialize_model or save_model_file. The action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'existing' implies this tool should be used for loading a previously saved .qtb model, but the description does not explicitly state when to use it over initialize_model or save_model_file, nor does it mention prerequisites or exclusions. Usage context is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explaining the return behavior: by default it returns the plot image, while return_image=False returns only the saved path. It also discloses file_path behavior and default directory handling. It does not mention file overwriting or side effects, but the readOnlyHint=false annotation already signals this is not a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and default behavior, followed by a structured Args list. The bilingual repetition lengthens it but serves a real audience, and each parameter is covered without excessive fluff. It is slightly longer than strictly necessary but well organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and sparse annotations, the description covers all parameters, provides semantic detail for each, and explains the return behavior. It could add a explicit note about running analysis first or about side effects of saving files, but overall it gives enough for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 parameter documentation burden. It compensates thoroughly: result_type lists all valid enum-like values, stage_id explains special meanings (-1, 0, n), component gives concrete examples, and return_image/file_path behavior is fully specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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: 'Generate an analysis result contour plot'. It lists allowed result types and clarifies the default return behavior, which makes the tool's purpose concrete and distinguishable from raw-data retrieval or screenshot tools, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is reasonably clear: this is for plotting analysis results, with parameters like stage_id, case_name, and result_type implying that it is used after an analysis exists. However, it provides no explicit guidance on when to prefer this tool over alternatives such as get_analysis_results or save_model_screenshot, and no when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the burden of behavioral disclosure. It does disclose that the tool mutates current check data by syncing the named case, runs a verification, and blocks waiting for a background task. However, it does not mention timeout/error behavior beyond the max_wait_seconds parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core information is front-loaded and the structure is logical, but every line is duplicated in Chinese, which adds token cost without new information. The bilingual repetition makes it less concise than it should be for an AI-facing definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool, invocation is covered well, but there is no output schema and the description never states what the tool returns, how success is signaled, or what happens when max_wait_seconds is exceeded. Those gaps matter for a tool that waits on a background task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only names and types with zero description coverage, but the Args section fully explains both parameters: name is the check case name to run, and max_wait_seconds is the completion-wait limit with None meaning no limit. This adds real semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: 'Execute concrete structural checking analysis', then details the exact process: sync the named check case, run code-based verification, and wait for the background task. This clearly distinguishes it from siblings like setup_concrete_check, configure_check_analysis, and get_check_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the execution step after a check case has been set up, but it never explicitly states when to prefer it over alternatives such as run_analysis, setup_concrete_check, or configure_check_analysis. No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show this is a mutating operation (readOnlyHint=false). The description adds useful behavioral details: 'delete_*' parameters are mapped to 'deactivate' rather than permanent deletion, and the types of activations/deactivations are enumerated. It does not disclose whether repeated calls merge or replace previous stage settings, but it is transparent about primary effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The lead sentence and purpose are front-loaded, and the Args list is scannable. It is necessarily longer because 10 parameters need semantics, but bilingual repetition of every item adds some redundancy without materially improving clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, the description explains all parameters and the general operation. What is missing is a statement of merge-vs-replace behavior for the existing stage and any side effects or return shape, but an agent can invoke the tool correctly with the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden and succeeds: every one of the 10 parameters is listed with its exact expected format, including nested shapes for active_structures, active_boundaries, and active_loads. This is well beyond what the JSON schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update an existing construction stage', giving a specific verb and resource, and immediately states the core purpose: activating/deactivating structure groups, boundaries, and loads. The word 'existing' differentiates it from add_construction_stage, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies when to use the tool ('existing' stage, update/activate/deactivate), but does not state when not to use it or point to alternatives like add_construction_stage or change_construct_stage. The context is understandable but leaves the agent to infer selection boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not idempotent. The description adds useful domain context by explaining that beta angle controls local axis orientation, but it does not disclose side effects, limitations, or what happens to existing orientation settings. It is adequate for a simple setter but not rich in behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a summary, domain explanation, Args section, and example. The bilingual content adds some redundancy but remains compact and useful. Every section contributes directly to correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutating tool with no output schema, the description is nearly complete: it defines both parameters, gives supported types, units, and a concrete example. It does not describe error behavior or effects on existing orientations, but those are not essential for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully carries the parameter documentation burden. It explains that ids supports int, list, or range string ('1to10'), and that beta is in degrees. The example further clarifies usage, making both parameters actionable despite the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Change the beta angle of one or more elements.' It also explains what beta angle controls (local axis orientation), distinguishing this tool from generic element updates like update_element, update_element_section, or update_element_material. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the description: use this tool when you need to modify element beta angles. However, it does not explicitly mention alternatives or say when not to use this tool, such as when updating other element properties like section, material, or nodes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the specific validation checks (missing nodes/elements/materials, overlaps), which is useful, but it does not disclose what happens after validation, such as return values, errors, or whether issues block analysis. This is a moderate contribution beyond annotations, not a rich one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a clear bulleted list. The bilingual repetition adds some redundancy but does not materially hurt usability, and no unnecessary filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description covers what the tool checks and when to call it. However, since no output schema exists, the lack of any statement about what the tool returns or how it signals discovered issues leaves an agent with some uncertainty about the tool's post-validation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain. The default baseline of 4 applies because no parameter semantic burden exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('validate'), a resource ('the current model'), and the precise scope ('for common issues before running analysis'). It also enumerates the exact checks performed, which makes the tool's function unambiguous and easily distinguishable from related tools like run_analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before running analysis' gives clear temporal guidance on when to invoke this tool. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for an agent to place it in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds the pagination parameters and mode-dependent search behavior, but doesn't disclose return format or edge-case behavior. It is consistent with annotations, neither contradicting nor significantly expanding them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the structured list of modes and parameters is information-dense and every line corresponds to a decision an agent must make. It leads with the primary purpose and then details the branching modes efficiently. The dual-language repetition adds length without much extra semantic value, but doesn't obscure the content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should clarify what the tool returns (e.g., entity IDs, coordinates, count) and any default behavior when no entities match. It provides complete input-side guidance but is silent on output structure and failure semantics. This is the main completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero description coverage, so the description carries full burden. It explains every parameter, including conditional requirements (e.g., x/y/z needed for point searches, name for material, index for section) and the role of limit/offset. This is a thorough compensating explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the tool locates nodes/elements by coordinates or attributes, with a verb ('Locate') and resource. It enumerates eight distinct search modes, making its scope concrete and distinguishing it from other query tools like get_model_info or display_ids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Args list maps each 'by' mode to the required parameters, giving an agent an explicit decision procedure for selecting a mode. It doesn't name sibling alternatives or state when not to use find_entities, but the mode breakdown provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations, particularly the side_i explanation that 'for tapered sections True means I-end, False means J-end' and the center_type choices. However, it does not disclose how bias_type and bias_point interact when both are provided, nor how updates affect existing section bias settings, leaving important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring is structured with a one-line purpose followed by a compact Args block. Each parameter line is short and informative, with Chinese translations adding context without bloat. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutation tool with no output schema and uninformative annotations, the description covers nearly all invocation-relevant information: parameter meanings, defaults, enum-like values, and domain-specific side_i behavior. The main gap is the unstated relationship between bias_type and bias_point and error behavior for invalid section IDs, but the description is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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, and it succeeds. Every parameter gets semantic explanation: index is the section ID, bias_type has concrete example values, center_type names valid options, bias_point is a custom [y, z] offset, and side_i is clearly explained for tapered sections.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Update section bias/eccentricity (更新截面偏心/对齐方式).' This clearly identifies the operation and resource, and 'section bias' distinguishes it from sibling tools like update_section_property and update_element_section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—whenever section bias/eccentricity needs updating—but it never explicitly contrasts this with alternatives such as update_section_property or update_element_section. There is clear context but no exclusionary guidance, so the agent must infer the boundary from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses an important behavioral detail: the software automatically applies self-weight when a load case named '自重' is created. It also states the prerequisite relationship between load cases and loads. It does not cover duplicate-name behavior or failure modes, but the added context is meaningful and does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core action and prerequisite. The parameter block is organized and necessary. Minor redundancy exists with the schema (default value is repeated), but overall every section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two simple parameters and no output schema, the description provides the essential call information: purpose, prerequisite, parameter values, and a special-case behavior. It does not describe return values or error handling, but this is not critical given the simplicity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 fully compensates by explaining both parameters: 'name' with examples and 'case_type' with an enumerated list of allowed values and the default. This is significantly more informative than the bare schema string fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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: 'Create a load case', and adds a useful prerequisite ('A load case must exist before loads can be applied'). It does not explicitly differentiate itself from sibling tools like create_load_group or create_live_load_case, but the resource term 'load case' is specific enough to be clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual guidance: a load case must be created before applying loads, and creating a '自重' load case is the special path for self-weight. It does not state explicit exclusions or name alternative tools, but the usage context is sufficiently clear for an agent to decide when to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses several non-obvious behaviors: the material must already exist, the section is auto-created as a rectangle if it does not exist, and the operation creates nodes, elements, supports, and a load case together. This adds context beyond the annotations, though it does not mention potential side effects like overwriting existing model data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: the main purpose is front-loaded, followed by a clean Args block. The bilingual repetition adds length but serves multilingual users and each line carries semantic value. It is somewhat longer than necessary but remains organized and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter creation tool with no output schema, the description covers prerequisites, auto-creation behavior, coordinate orientation, and all parameter meanings. It does not specify the exact support placements or what the tool returns on success, but these are relatively minor gaps given the level of detail already provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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: span in meters, num_elements with minimum 2, material/section existence requirements, section width/height for auto-creating a rectangular section, and the self-weight case name. This is essential because the schema itself provides no descriptive text for any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource, 'create' a 'simple beam bridge model', and enumerates exactly what is produced: nodes, beam elements, supports, and a self-weight load case. It also states the bridge lies along the X-axis, which distinguishes it from generic or continuous bridge creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by emphasizing 'one-step creation' and listing all included components, which suggests it is for quick high-level bridge modeling rather than step-by-step setup. However, it does not explicitly mention alternatives such as create_continuous_beam_bridge or lower-level create_nodes/create_beam_elements_linear, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations false and no safety profile, the description carries the burden. It discloses the advanced override behavior (steel_detail overrides the four parameters) and the material-existence prerequisite, but does not explain duplicate-name behavior, validation, or return values. The override quirk is useful, but the side-effect contract remains under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded and dense: each parameter line adds units, examples, or codes absent from the schema. Bilingual repetition is verbose but functional for the locale.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter create operation with no output schema, this covers all inputs, preconditions, enum coding, and advanced override cases. It could add failure/duplicate behavior and return-value expectations, but nothing essential for selecting and invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and this description compensates fully: it explains every parameter's meaning, enum values, units, typical values, and the steel_detail list format. Without it, the eleven schema entries would be bare names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a tendon property definition (创建钢束特性)', naming a specific verb and resource. The parameter context (prestress steel material, duct, tendon type) clearly distinguishes this from siblings like create_tendon_2d and add_tendon_3d by showing it defines property data, not geometry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states that material_name must already exist and references create_material as the prerequisite, giving an agent a required precondition. It also labels steel_detail as an advanced override for special cases. It does not explicitly contrast with geometry/assignment siblings, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that this is a 'post-analysis' results query, which hints that an analysis must have been run, and it shows the result kinds available. However, it does not disclose behaviors such as which parameter combinations are required per kind beyond the inline notes, or what happens when no results exist. This is acceptable but not exceptional given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is stated in one front-loaded sentence, followed by a well-organized Args block. The bilingual formatting adds length but also disambiguates technical terms. It is somewhat verbose with 11 parameters, yet each line earns its place by adding needed meaning. It could be tightened slightly but remains well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-complexity tool with 11 parameters, no schema descriptions, and no output schema, the description is notably complete on the input side: it covers parameter meanings, required combinations, and default behavior via defaults. Missing pieces include the output shape and the precise semantics of generic flags like result_kind, envelop_type, and increment_type, but the description still gives an agent enough to call the tool correctly for most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions, so the description carries the full burden, and it delivers. It explains every parameter, provides allowed values for the 'kind' parameter, and explicitly notes which additional parameters are required for each result kind (e.g., '需 mode', '需 node_id + case_name'). This is substantially more informative than the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Get special post-analysis results', and immediately distinguishes itself from the sibling get_analysis_results by saying it covers results 'beyond the basic deformation/force/stress/reaction'. It also enumerates the exact result kinds, so an agent can tell exactly what this tool does and what it is not for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when special post-analysis results are needed, as opposed to the basic results covered by get_analysis_results. It explicitly names that sibling tool, which provides useful routing context. It does not go as far as stating explicit exclusion conditions ('do not use for X'), but the contrast with the sibling is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this mutates the name of an existing group, but the annotations are all false and provide no safety context. It does not say whether group members are preserved, whether new_name must be unique, or what happens if the old name does not exist, which would be useful for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a one-line purpose statement followed by a minimal Args list. Every element serves a purpose and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity rename tool with two required string parameters and no output schema, the description covers purpose, operand, and parameter semantics. It could add uniqueness or error behavior, but nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 parameter meaning; the Args section does this by distinguishing 'Current structure group name' from 'New structure group name'. For two simple string parameters, this is sufficient and adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Rename') and resource ('existing structure group'), making it clearly distinct from sibling tools like create_structure_group, remove_structure_group, and add_to_structure_group. The bilingual wording adds no ambiguity and directly conveys 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing structure group' clearly positions this tool as operating on an already-created group rather than creating or removing one. It does not name alternative tools or give explicit when-not conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so they add little; the description provides useful behavioral details like element_id=-1 meaning auto-assign next available ID and that materials/sections must be looked up via get_materials/get_section_list. However, it does not disclose the return value, overwrite behavior, or model-state side effects beyond the act of creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, then uses a structured Args block and a minimal example to make 9 parameters easy to scan. The bilingual notes and 'preferred way' sentence do not blout.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter create tool with no output schema and no enum constraints, the description covers every parameter, gives valid value ranges, and tells the agent where to find material/section IDs. Minor gaps remain around the return value and duplicate/overwite behavior, but an agent can invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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. The Args block documents all 9 parameters, including ele_type and initial_type value maps, beta_angle units, and element_id auto-assign semantics. The example also provides a minimal valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a single frame element (beam/truss/cable)' and distinguishes it from bulk/linear creation via the word 'single'. This clearly differentiates it from siblings like create_beam_elements_linear and create_elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'This is the preferred way to create individual elements,' which gives agents a clear condition for selecting this tool. It doesn't name alternatives or state when not to use it, so it stops just 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing no positive behavioral hints. The description adds useful context: that load-group membership is mandatory and that creation precedes load cases or applied loads. However, it does not disclose edge-case behaviors like duplicate names or whether the group is immediately referenceable, so it stops short of rich transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, followed by essential contextual rules and a parameter explanation. It includes appropriate bilingual repetition, which is slightly redundant but intentional for a dual-language API, and no irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output-schema create tool, the description covers the essential context: what a load group is, why it matters, ordering relative to other operations, and the only parameter. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented parameter. It does: 'name: Load group name (荷载组名称, e.g. "默认荷载组")' explains the parameter's meaning and provides an example, adding value beyond the bare schema title and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a load group' (创建荷载组), a specific verb and resource that clearly distinguishes this from siblings like create_load_case or apply_nodal_force. It further clarifies the tool's role by stating that every load must belong to a load group, cementing the resource's identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Create this before creating a load case or applying loads.' This gives the agent a clear operational sequence and prevents misuse relative to load case and load application tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, and the description adds substantial operational detail: automatic 'ST:' prefix insertion, pagination behavior, physical units (meters/radians, kN, kN·m), lower/upper-case key conventions, and the nested force_i/force_j structure. This materially reduces agent surprise beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The Args/Returns layout is well structured and front-loaded with a one-sentence purpose statement. Each block delivers necessary operational information without fluff, and the bilingual repetitions are compact and aid disambiguation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter tool with no output schema, the description covers purpose, parameters, units, pagination, and return shapes for deformation and force results. However, the stress and reaction return structures are only dismissed as 'similar nested dict structures', leaving an agent without exact keys for two of the four supported result types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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: allowed result_type values, node/element ids, stage_id semantics with -1/0/n meanings, case_name auto-prefix behavior, and limit/offset pagination. This is a strong example of description carrying the parameter-documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns analysis results from the bridge model and enumerates the available result types (deformation, force, stress, reaction), so the core purpose is unambiguous. However, it doesn't explicitly distinguish this generic retrieval tool from sibling specialized result tools such as get_tendon_loss_results, get_live_load_results, or get_special_results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parameter documentation gives useful contextual guidance about result_type and stage_id, making the intended use reasonably clear. It never says when to prefer this tool over sibling result-querying tools, nor does it provide any exclusions, so an agent must infer the boundary from tool names and the result_type list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly, idempotent, and non-destructive, and the description adds that the operation returns maximum/minimum envelope values for the queried element IDs. It also documents the supported result_type values. It does not describe output formatting or error behavior, but the annotations reduce the burden for safety-related behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by the return behavior and a compact Args list. The bilingual duplication makes it longer than strictly necessary, but each part is purposeful and structured for the intended audience.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, result envelope, and parameter semantics, which is enough to attempt a call. However, there is no output schema and no statement about what happens when element_ids is omitted (default ''), nor about the shape/units of returned envelope values, so an agent is left to guess those details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full semantic burden and does so well. The Args section explains case_name, enumerates result_type options ('force', 'stress', 'deformation'), and clarifies that element_ids can be element or node IDs, adding real meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a distinct resource ('moving load analysis results') and explicitly states that it returns envelope (maximum and minimum) results. This separates it from generic result tools like get_analysis_results and from tendon-specific result tools, so an agent can tell what it does without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes that this tool is for live load/moving load envelope queries on specified elements, giving enough context for when to call it. It does not explicitly name alternatives or exclusion conditions, so it stops short of full routing guidance, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-read-only mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds useful parameter behavior like range-string support, but does not disclose side effects such as overwriting prior section assignments or behavior on invalid IDs. This is adequate given the annotations, but not especially rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then provides a compact argument list and a minimal example. Bilingual text is not filler for a multilingual API. Every sentence adds useful information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with no output schema, the description is nearly complete: it defines valid ids formats, explains where to get a valid section ID, and shows usage. Minor gaps include not stating what happens if an ID is invalid or whether the operation replaces existing section assignments, but these are not critical for a low-complexity call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden for parameters. It compensates well: ids is explained as int, list, or range string '1to50', and sec_id is described as a new section ID with a pointer to get_section_list for valid values. This goes well beyond the minimal schema which gives no type for ids.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change the section'), the resource ('one or more frame elements'), and includes a Chinese translation. It is easily distinguished from sibling tools like update_element_material, update_element_nodes, and update_section_property because the scope is explicitly the section assignment of frame elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage guidance: ids accepts int, list, or range string '1to50', and sec_id should be looked up via get_section_list. The example clarifies a common batch call. It does not explicitly name alternative tools or exclusion conditions, but the usage context is clear enough for an agent to proceed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal mutation and non-destructiveness, and the description adds specific behavioral details: it overwrites stored section properties, accepts up to 29 values in a fixed order, and interprets side_i as I-end/J-end for tapered sections. It does not describe error cases or side effects, but the core behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and usage are front-loaded, and the Args section is cleanly structured. The bilingual repetition of the same statements adds minor redundancy, but the description remains compact and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, the description covers what is modified, which parameters matter, and the meaning of the tricky side_i flag. Missing details such as the complete property list and failure behavior do not undermine basic call correctness, but would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 parameter-documentation burden. It explains index as a section ID, side_i as a tapered-section end selector, and sec_property as an ordered list of up to 29 values with six examples. The main gap is not enumerating the full 29-property order.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('directly modify'), a specific resource ('calculated properties of a section'), and concrete examples (Area, Ix, Iy, Iz). It clearly distinguishes itself from sibling tools like calculate_section_property by emphasizing manual override of auto-calculated values after creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: use after section creation for fine-tuning or correcting auto-calculated values, which implies a distinction from calculation/creation tools. It does not explicitly name alternatives or state when not to use this tool, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the minimal annotations by disclosing that the tool uses qtmodel's native units (mm/MPa), that these units are undocumented and inferred from defaults, and that callers should use get_check_data before overwriting. It does not specify whether unspecified settings are reset or how the tool behaves on failure, but the disclosed quirks are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized: the unit warning is front-loaded, the read-first guidance is prominent, and each setting group is structured as a labeled list. The bilingual duplication adds length, but the content is dense and almost entirely necessary given the empty schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with deeply nested, heterogeneous parameters and no output schema, the description covers the parameter space and unit semantics thoroughly. However, it omits potential prerequisites such as whether setup_concrete_check must be called first, and it does not describe the success/error behavior or return value, 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema only defines 'kind' and a generic settings object. The description compensates fully by documenting every kind's valid parameters, their enum values, units, and Chinese labels, effectively serving as the complete parameter reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Configure a concrete-check analysis setting group', and enumerates seven exact setting kinds such as normal_section_bearing, oblique_shear_bearing, and limit_state. This is precise enough to distinguish it from sibling tools like configure_analysis, run_concrete_check, and get_check_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs the agent to read current values first via get_check_data and to pass only the settings being changed, which is valuable usage guidance. It does not explicitly state when to choose this tool over configure_analysis or setup_concrete_check, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-read-only, non-idempotent, non-destructive behavior, so the description carries the burden of explaining side effects. It discloses that the tool creates a case and that the engine performs an envelope analysis by finding worst-case vehicle positions, going beyond what annotations provide. It lacks details on overwrite or precondition failures, but the main behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening statement, workflow context, an Args section, and an example. Bilingual content adds some redundancy but is purposeful given the domain. It is longer than minimal but every section contributes to correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the low schema coverage, the description provides a complete enough picture: what the tool does, what arguments to pass, and how to structure sub_cases. It identifies the workflow position but does not explicitly enumerate prerequisites such as requiring an existing influence plane and lane definitions, though these are implied by 'FINAL STEP' and visible among sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% schema coverage), but the description fully compensates with an Args block explaining each parameter, including units for span and the exact nested structure of sub_cases. The concrete example demonstrates how to combine all parameters correctly, which is especially valuable for the complex sub_cases argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a moving live load case and identifies it as the final step of the moving load workflow. It also explains the core purpose: the analysis engine computes worst-case vehicle positions for envelope results. This distinguishes it from generic create_load_case and other workflow siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames the tool as the FINAL STEP of the moving load workflow, giving clear sequencing context: influence plane, lanes, and vehicles should already exist. It does not explicitly name alternatives or state when not to use it, but the workflow positioning is a strong usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark this as destructive, and the description adds meaningful context by stating what gets destroyed: duplicate nodes within tolerance are merged. It also clarifies scope via the ids parameter and the tolerance semantics, going beyond the bare destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then gives parameter details and an example in a logical order. Bilingual repetition of most content adds some length, but it remains compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter destructive tool with no output schema, the description covers the essential invocation knowledge: what the tool does, which nodes are affected, how tolerance works, and a full example. It lacks explicit notes on side effects to connected elements or warnings about setting a very large tolerance, but these are not strictly required for correct basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates fully. It explains that ids accepts int, list, or range string, with empty meaning all nodes, and defines tolerance as a merge distance in model units with an explicit default of 0.0001m. The example further clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Merge nodes that are at (nearly) the same coordinates'. It also anchors the operation to the GUI's 'Merge Nodes' feature, and the stated use case of removing accidental duplicate nodes distinguishes it from siblings like remove_nodes or move_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: 'Useful after building a model to remove accidental duplicate nodes.' It also explains the default behavior when ids is left empty. However, it does not explicitly say when not to use it or name alternative tools that might be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavioral detail beyond the annotations: it creates an operation stage and 'accumulates all previous stage results,' and it finalizes the construction stage analysis. The annotations only indicate this is a mutating operation, so the description adds useful context about what the mutation does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. The bilingual repetition is somewhat redundant for an English-reading agent but does not obscure the meaning and is still compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single optional parameter and no output schema, the description sufficiently covers what the tool does, when it applies, and what the parameter means. It does not mention prerequisites or whether existing stages are preserved, but the low complexity limits the impact of those omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly explains the only parameter: 'name: Name for the merged operation stage.' This adds clear meaning beyond the schema's title and default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Merge all construction stages into a final operation stage.' This is a specific verb and resource, and it naturally distinguishes the tool from siblings like add_construction_stage, update_construction_stage, and remove_construction_stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by saying 'This finalizes the construction stage analysis,' which tells an agent when this tool should be used in a workflow. It does not explicitly name alternatives or exclusion conditions, but the timing implication is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive, and the description adds important context: passing an empty name removes all construction stages. This is a critical behavioral detail that goes beyond the annotations and helps the agent understand the full destructive scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the primary action stated first and the parameter semantics explained immediately after. The bilingual content is acceptable and does not add unnecessary bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool with no output schema, the description provides all necessary operational context: what is removed and how the empty-name case behaves. The annotations cover the safety profile, so no additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no property description, so the description carries the full semantic burden for the single parameter. It clearly explains that name identifies the stage to remove and that an empty value triggers removal of all stages.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Remove a construction stage.' It clearly conveys the action and the target resource, and it is easy to distinguish from sibling tools like add_construction_stage or update_construction_stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the key conditional behavior: if name is empty, all stages are removed. However, it does not explicitly mention when to choose this tool over alternatives such as update_construction_stage or remove_boundary, leaving much of the tool-selection guidance to inference 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important runtime behavior: long solve time, execution in a worker thread to keep the connection responsive, periodic progress heartbeats, and timeout semantics including that the solve continues in the background after a read timeout. Annotations provide no behavioral hints, so the description carries the burden and does so well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is front-loaded with the core action and usage condition, and the behavioral warnings are relevant. The bilingual repetition adds length but appears intentional for a bilingual API audience; it does not create confusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter analysis command, the description covers prerequisites, duration expectations, concurrency behavior, and timeout semantics. It does not mention how to retrieve results, but the sibling get_analysis_results tool implies that path; this is a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains the only parameter, read_timeout: its meaning, default value, and the non-obvious consequence of a timeout (throws an error while the solve continues). This fully compensates for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Run the structural analysis calculation') and makes clear this is the execution step, distinct from configuration and validation tools like configure_analysis and validate_model. The bilingual phrasing reinforces intent without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear precondition: use after loads, boundaries, and analysis settings are configured. It does not explicitly name alternative tools or say when not to use it, but the sequencing guidance adequately orients an agent among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral details beyond the annotations: the default is to return the image itself, file writes go to a default directory when path is empty, and return_image controls whether the image or just the path is returned. It does not mention overwrite behavior, but the non-destructive annotation makes this a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line purpose followed by an Args block. The bilingual repetition adds length but also improves accessibility for Chinese users. Overall it is focused and front-loaded, though slightly longer than necessary due to full duplication in both languages.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter screenshot tool with no output schema, the description provides enough information to call it correctly: output path, view presets, and return behavior are all covered. It could specify what 'default directory' means or overwrite policy, but these are minor for a non-destructive capture operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 all parameter meaning, and it does. It explains file_path's default directory behavior, enumerates every view_angle option with Chinese translations, and clarifies return_image's effect. This goes well beyond the bare schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Capture a screenshot of the current bridge model view.' This clearly identifies what the tool does and distinguishes it from sibling tools like set_view_angle, which changes the view rather than capturing it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: whenever a screenshot of the model view is needed. It also explains default return behavior and how to control whether the image is returned directly or only the path. There are no competing screenshot tools among siblings, so explicit alternative routing is not necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and provide little behavioral guidance, so the description must carry the burden. It discloses useful behaviors: intersected splits elements at intersections, is_merged merges duplicate nodes, merge_error sets tolerance, and numbering follows start_id. It does not mention return values or repeated-call semantics, which prevents 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and the alternative tool before detailing parameters. Each line in the Args block adds needed information; the bilingual notes add minor redundancy but are not excessive. It is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters and no output schema, and the description covers parameter semantics and the main sibling. However, it never states what the tool returns, whether creation is additive to existing nodes, or how errors/conflicts are handled. These gaps matter for a mutation tool, so it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 all six parameters with formats, defaults, and meanings: node_data format as [[x,y,z],...] or [[id,x,y,z],...], merge_error default 1e-3, numbering_type strategy, start_id, intersected, and is_merged. This fully compensates for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create nodes in the bridge model from an explicit coordinate list.' It also names the key sibling, create_nodes_linear, as the alternative for evenly spaced nodes, allowing an agent to distinguish them without reading schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs: 'Prefer create_nodes_linear when nodes are evenly spaced along a line — it is far more concise for typical bridge models.' This is a clear when-to-use/alternative rule. It implies create_nodes is for explicit coordinate lists, which is exactly the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give only readOnlyHint=false, destructiveHint=false, so they communicate little. The description compensates by disclosing the full complexity of the tool: sec_info layout varies by sec_type, all parameter orderings for 20+ types, and which parameters are conditional (box_num/box_height/symmetry/chamfer_info for concrete box girders). It doesn't discuss error behavior or what happens on invalid combinations, but for a parametric creation tool the parameter-layout disclosure is the key behavioral transparency, and it is provided in depth. A small deduction for not mentioning side effects or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the length is earned: every section type entry lists different parameter orderings that cannot be omitted. It is well-structured with visual separators (基本形状, 混凝土/组合, 钢结构带肋) and ends with examples. The 'Args:' formatting is a bit unusual for an LLM-facing tool (reads like Python docstring), but it is organized and scannable. One minor deduction for the docstring-style format and a small amount of redundancy (e.g. Chinese parentheticals repeating the English terms).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, 20+ section types, and no output schema, the description is remarkably complete. It covers all parameter semantics, conditional parameter applicability, and provides examples. The remaining gaps: it doesn't state what the tool returns on success/failure, doesn't clarify whether mat_combine is formatted as ratios (e.g. percentages), and doesn't explain chamfer_info string format for concrete box girders. Given the complexity, this is strong but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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, and it does substantially. It defines sec_type as a Chinese enum with all allowed values, gives the exact sec_info element order for each type, and explains mat_combine, box_num, box_height, symmetry, and chamfer_info. However, it does not fully explain the default behavior of sec_info (nullable with default null) or whether it is required for all types, so there is a small remaining gap. Overall it adds enormous meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a cross-section and explicitly says it is 'one tool for all parametric section types' (创建截面). It distinguishes itself from non-parametric alternatives by naming siblings create_polygon_section, create_line_width_section, and create_section_from_properties. The purpose is unambiguous and directly differentiates from the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool vs alternatives: 'For non-parametric sections use: create_polygon_section, create_line_width_section, create_section_from_properties'. It also gives detailed per-type parameter guidance, including which parameters apply only to concrete box girders. This is exemplary usage guidance far beyond the minimum.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the burden of behavioral disclosure. It provides meaningful behavioral detail: the tendon profile lies in X-Z, control points are [x,z,r] with fillet radius semantics, property_name must already exist, and positioning modes are explained. It does not state return values or error behavior, but for a create tool the main behavioral surface is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized: one-line summary, geometry explanation, parameter list, and an example. Every sentence adds value, and the key distinguishing facts are front-loaded before the parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with no output schema and no schema-level descriptions, the description covers all parameters and gives an example. Minor gaps remain: the interplay between point_insert and position_type=2 (track line) is not fully explained, and return/error behavior is not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description documents all 9 parameters with meanings, coordinate formats, allowed values for line_type/position_type/symmetry, and a concrete example. This fully compensates for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Create a 2D tendon defined by profile control points.' It clearly distinguishes this from sibling tools like add_tendon_3d by stating the profile lies in the X-Z plane and refers to 2D/平弯钢束.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool creates a 2D tendon in the X-Z plane, and it notes that property_name must already exist (须已创建), which is a prerequisite. It does not explicitly say 'use add_tendon_3d for 3D tendons,' but the 2D vs. 3D distinction is strongly implied by the plane definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the visual outcome for each flag value, which adds useful behavioral context beyond the annotations. The annotations already cover the mutation and non-destructive nature of the operation, so the description doesn't need to repeat those. The word 'toggle' slightly overstates what is actually a set operation, but the flag explanation resolves the ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the parameter explanation immediately following the main statement. The bilingual parentheticals repeat the English content without adding new information, but overall it remains efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-boolean tool with no output schema and annotations covering safety traits, this description is complete enough for an agent to invoke it correctly. No additional return-value or side-effect documentation is necessary at this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a boolean type and a default value, with no parameter description. The description fully compensates by explaining that True means rendered view and False means wireframe, leaving no ambiguity about how to set the flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: toggle solid rendering mode, with the flag parameter defining the two states. This distinguishes it from display-related siblings like set_view_angle, reset_display, and switch_display_stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool controls whether the model is shown rendered or as wireframe. It doesn't explicitly name alternative tools or exclusion conditions, but for a one-parameter view-mode switch the usage context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful beyond-annotation behavior: the prerequisite that a check case must be opened first, explicit read-only restatement, and pagination behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but exceptionally well-structured: front-loaded with purpose and read-only note, then organized into clear categories (Results, Case, Reinforcement, Analysis settings) with compact separators. Every sentence and code block earns its place by carrying information absent from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 and no enums, the description is complete: it covers all parameter semantics, allowed values, defaults, pagination, prerequisites, and scope of data returned per kind. An agent has everything needed to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 defining every parameter: categorized kind values with Chinese translations, stress_type enumerations including AASHTO and non-AASHTO variants, name override logic, element_id scope, and limit/offset defaults and max. This is exemplary parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Query'), resource ('concrete-check data'), and selection dimension ('by kind'), clearly differentiating it from generic model-info and analysis-result siblings like get_model_info or get_analysis_results. The bilingual purpose line is immediately informative and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear operational context: read-only, requires an open/imported check case, and returns paginated results. It does not explicitly name sibling alternatives or when-not-to-use scenarios, so it stops short of a 5, but the context is strong and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context: it inspects specific databases ('mdb', 'odb', 'cdb'), filters method names with a case-insensitive substring, and returns 'real signatures'. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and structured clearly with an Args section. The bilingual duplication is slightly redundant, but it is compact and every major idea is covered without wandering.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the workflow, the parameters, and the relationship to call_qtmodel_api. There is no output schema, so a bit more detail about the exact return shape of the discovered signatures would be even better, but it is still adequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent, but the description fully compensates by explaining both parameters: api_object identifies which database to inspect with concrete allowed values, and pattern is a case-insensitive substring filter with examples. This is exactly the semantic detail an agent needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Discover qtmodel API methods and their real signatures.' It also explicitly differentiates this tool from the curated tools and from call_qtmodel_api, so an agent can tell what it is for without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage direction: use this for long-tail methods NOT covered by curated tools, and always discover the real signature here before calling call_qtmodel_api. It also says not to guess parameter names, which is a clear do-not behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses critical behavior: start_id is only honored when there are no conflicting IDs, the backend may reassign IDs, and the returned message should be trusted over start_id. It also explains that merging can result in fewer nodes than requested, which is valuable behavioral context not visible in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an intro, Args section, and Examples, and it front-loads the core purpose. It is somewhat long due to bilingual repetition, and the two examples are nearly identical in their parameter usage, but the structure makes it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with no output schema, the description covers all parameters, explains key edge cases (ID reassignment, node merging), and provides concrete examples. Nothing essential about how to call the tool correctly or interpret the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for any of the 10 parameters, so the description carries the full burden — and it succeeds. Each parameter is explained with both English and Chinese labels, and start_id and is_merged receive important caveats about reassignment and merging. This exceeds what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates evenly-spaced nodes along a straight line, with a concrete use case (modeling a bridge girder). This distinguishes it from generic node creation tools like create_nodes and from create_beam_elements_linear, which creates elements rather than nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is the preferred method for modeling a bridge girder and avoids listing many coordinates. It does not explicitly name the generic alternative create_nodes or state when NOT to use this tool, but the 'preferred way' framing and the coordinate-listing contrast provide adequate usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses important behavior: list results are paginated, limit has a max of 500, defaults are specified, and certain kinds require additional parameters. It also documents the special ids format including the '1to10' range string, adding real value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and the Args section is logically organized into categories with consistent formatting. The length is substantial, but it is justified by the large enumeration of kind values; the bilingual repetition adds bulk but also clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All 8 parameters are covered with defaults, constraints, and kind-specific requirements, plus pagination behavior. Although there is no output schema, the 'List results are paginated' statement and detailed kind semantics give an agent enough context to call the tool correctly and anticipate the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 all 8 parameters. It defines every parameter, enumerates all 30+ kind values organized by category, specifies per-kind required arguments, and gives semantics for ids, name, sec_id, position, stage_id, limit, and offset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Query model data by kind') and explicitly frames itself as 'the single read tool for entities, loads, groups and stages,' which clearly separates it from the many create/update sibling tools. It states exactly what domain it covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is the read tool for four model categories, and it enumerates all supported kind values so an agent knows what it can query. It does not explicitly name alternative read tools like get_analysis_results or get_model_info as when-not-to-use cases, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the destructiveHint annotation by explaining that empty ids triggers total deletion, that confirm_delete_all is mandatory in that case, and that free nodes can optionally be removed. It also adds a critical rule prohibiting autonomous mass deletion without user permission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and organized into clear Args and warning sections. Some bilingual repetition adds length, but the critical safety instruction and example provide enough value to justify their inclusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive three-parameter tool with no output schema, the description covers input formats, all parameters, the mandatory confirmation flag, and a worked example. Nothing essential to correctly invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 documenting all three parameters: ids supports int, list, or range string '1to10'; remove_free_nodes controls orphan node deletion; confirm_delete_all guards bulk deletion. This adds substantial meaning beyond the schema's minimal type/default information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Delete elements from the model') on a clear resource, and the ids parameter clarifies scope including partial or full deletion. Although sibling tools like remove_nodes and remove_section exist, the tool's focus on 'elements' distinguishes it sufficiently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when ids can be left empty and explicitly states that confirm_delete_all must be true. It includes a strong LLM-specific instruction to ask the user before deleting all elements, but does not discuss alternatives or exclusions versus other removal tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the destructiveHint annotation by explaining the dangerous empty-ids behavior, the mandatory confirmation flag, and the explicit guardrail asking user permission before mass deletion. This is strong, safety-relevant disclosure that an agent needs before invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-line purpose, Args breakdown, critical instruction, and example. It is slightly longer due to bilingual repetition, but the critical safety instruction and example are worth the space. Overall it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive 2-parameter tool with no output schema, the description is complete: it covers accepted id formats, the all-nodes deletion behavior, the required confirmation, and the LLM safety rule. Nothing essential for correct and safe invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 understanding. It fully compensates by explaining that ids accepts int, list, or range string '1to10', that leaving it empty deletes ALL nodes, and that confirm_delete_all must be true in that case. This is excellent parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete nodes from the model'. This clearly distinguishes it from sibling tools like remove_elements, remove_section, and remove_boundary. The example invocation further reinforces 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for how to delete specific nodes vs all nodes, explicitly requiring confirm_delete_all=true for the empty-ids case. It also provides a critical when-not rule: do not delete all nodes autonomously and must ask the user first. It does not explicitly compare against alternatives like remove_elements, but the resource is clearly identified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far exceeds the sparse annotations (readOnlyHint=false, destructiveHint=false). It discloses the backend's unpredictable ID ordering with measured evidence (qtmodel 2.6.3 examples), the silent failure mode (folded-back geometry the solver accepts without error), and the pre-write geometric monotonicity check that fails instead of building a bad model. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded: summary, preferred usage, critical warning, safety behavior, parameters, examples. It is long, and the bilingual repetition doubles every concept, but the extra length is earned — the ID-ordering warning is evidence-backed and each parameter needs explanation given the empty schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Everything an agent needs to invoke the tool correctly is present: preferred vs. legacy modes, the dangerous trap, all parameters, and examples. The one gap is the return value — the description never states what the call returns (presumably element IDs), and with no output schema that information is absent entirely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 succeeds. All 8 parameters are explained, including cross-parameter dependencies: node_ids creates len(node_ids)-1 elements, node_id_start is only valid with count, and ele_type maps 1/2/3 to Beam/Truss/Cable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Batch-create frame elements chaining nodes along a girder' — naming both the operation and its mechanism. It is clearly distinguishable from siblings like create_beam_element (singular) and create_nodes_linear (which produces the node_ids this tool consumes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly designates the PREFERRED calling mode (pass node_ids from create_nodes_linear) and marks node_id_start as a LEGACY fallback with the exact safety condition ('only safe when the nodes are known to be consecutive'). Two examples contrast the preferred and legacy paths, leaving no ambiguity about when to use which.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description goes further by naming exactly what is destroyed (current model data in the active bridge software) and adding a user-permission prerequisite. This is meaningful behavioral context beyond the structured annotations, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The key information is front-loaded and clearly structured: purpose, destructive warning, usage restriction, agent instruction, and parameter guidance. The only downside is that every English line is duplicated in Chinese, adding length without adding information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-boolean-parameter tool with no output schema, the description is complete: it explains the destructive effect, when to use it, when not to use it, the required user-permission step, and the required parameter value. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a boolean 'confirm' with default false and no description. The description adds the essential semantic: confirm must be set to true to execute, which is exactly what the agent needs to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a destructive initialize action: it creates a new empty model and CLEARS the current model data. It also explicitly distinguishes itself from normal create/modify tools by warning it is only for brand-new projects, so an agent can tell it apart from siblings like create_simple_beam_bridge or open_model_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this ONLY when starting a brand new project, NOT when modifying an existing model. It also adds a critical agent-level instruction: never call this tool autonomously to fix mistakes, and always ask the user for permission first. This is excellent when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations all set to false, the description carries the full behavioral burden and does so well. It discloses the key conceptual model — self-weight is NOT a load case, it is controlled by a per-structure-group stage number, and the solver computes gravity automatically from section area × unit weight × g. It also explains the meaning of the weight_stage_id values, giving the agent accurate expectations about what the tool mutates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then the IMPORTANT conceptual note, then usage guidance, then Args. The bilingual repetition (English followed by Chinese) adds length without much new semantic content for an AI agent, but the overall organization is clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's conceptual subtlety, this is complete. It explains the underlying self-weight model, when the tool is unnecessary, the alternative tool to use, and the parameter meanings including defaults inherited from the schema. No output schema exists, and for a configuration setter the return value is not critical to calling it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 documents all three parameters: stage_name, structure_group_name, and weight_stage_id, including the special semantics of weight_stage_id (0=not counted, 1=this stage, n=stage n). This adds meaning far beyond the bare schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Configure self-weight for a construction stage,' and immediately clarifies the exact scope — choosing which construction stage carries a structure group's self-weight. It distinguishes itself from related concepts (load cases) and sibling tools like merge_operation_stage by explaining what this tool is and is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when not to use the tool: for single-stage or one-shot models, self-weight is handled by merge_operation_stage and this tool is usually not needed. It then states the intended use case: 'Use it only to override which stage accounts for a group's self-weight.' This gives clear when/when-not guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Qiao-MCP MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![Qiao-MCP MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/SorataYang/qiao-mcp/badges/card.svg)](https://glama.ai/mcp/servers/SorataYang/qiao-mcp)

Score Badge

Copy to your README.md:

[![Qiao-MCP MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/SorataYang/qiao-mcp/badges/score.svg)](https://glama.ai/mcp/servers/SorataYang/qiao-mcp)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![Qiao-MCP MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2FSorataYang%2Fqiao-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/SorataYang/qiao-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SorataYang/qiao-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server