Structural analysis and dynamics / 结构求解与动力设置

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

Annotations declare destructiveHint=true and idempotentHint=false; the description earns credit by explaining why: configuration defaults overwrite prior settings, so prior setup is not preserved. It also discloses non-obvious runtime behavior — progress heartbeats, success only on a successful terminal state, read_timeout bounding the wait rather than the solve, and the fact that timeout does not cancel the computation. The disclaimer that neither a completed solve nor a confirmation implies code-check safety adds further value.

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

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

Purpose is front-loaded in the first sentence, and the length is defensible for a ten-operation dispatcher. However, the middle sections are dense and mix sibling routing, sequencing, timeout semantics and safety caveats without strong visual separation, making some sentences carry multiple ideas. Slightly tighter grouping would improve scanability.

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

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

An output schema exists, so return values need no explanation, and the description correctly focuses on what is missing elsewhere: per-operation routing, execution order, the no-solve-vs-solve distinction, and the overwrite caveat. For a dispatcher spanning configuration, dynamic inputs and solving, this covers everything an agent needs to invoke the right branch correctly.

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

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

The single top-level parameter has 100% schema description coverage, and the per-operation sub-schemas document fields, units and defaults in detail, so the schema does the heavy lifting. The description's note that 'request.operation selects its own fields and units' largely restates the discriminator guidance already present in the schema. This meets the baseline for a well-covered schema without adding much beyond it.

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

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

The opening sentence names a specific verb+resource ('Configure and run structural analysis') and enumerates the concrete sub-domains it covers (masses, response spectra, time-history functions/cases, buckling). It also routes explicitly against siblings, noting query_results for solved responses, manage_checks for concrete verification, and access_backend for options lacking a dedicated operation. An agent can place this tool in the workflow without opening the schema.

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

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

States when to use it (after model, loads and stages are ready), when it does NOT act ('These configuration operations do not solve: choose run_analysis explicitly'), and names alternatives for adjacent concerns (configure_analysis, update_bulking_setting, query_results, manage_checks). Practical sequencing guidance is included ('read them first when preserving an existing setup', 'Check inspect_bridge before retrying').

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