cst_set_solver_tool

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

No annotations are provided, so the description carries the full behavioral burden. 'Select' implies a state mutation, but the description never says whether it requires an open project, whether switching solvers discards mesh/frequency settings, or whether it is idempotent. This is a significant gap for a state-changing operation with zero annotation coverage.

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

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

A single short sentence, front-loaded with the verb and resource. Nothing extraneous, though it is arguably under-specified rather than genuinely tight.

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 not be explained. However, for a mutation tool with no annotations and 0% parameter coverage, the description omits accepted solver identifiers, prerequisites, and side effects — the essentials an agent needs to call it correctly.

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

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

Schema coverage is 0% with a single untyped string parameter, so the description must compensate. It partially does by naming solver families in prose, but gives no exact accepted token values or spelling, so an agent still cannot reliably construct the argument.

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?

Specific verb 'select' plus resource 'solver', with concrete examples (time domain, frequency domain, eigenmode) that let an agent distinguish it from neighbors like cst_run_solver_tool or cst_configure_td_solver_tool. The trailing '...' leaves the value space open-ended, and it never states how it differs from cst_get_solver_tool.

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

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

No when-to-use guidance, no prerequisites (e.g., project must be open), and no routing to alternatives such as cst_get_solver_tool for reading the current selection or the configure_*_solver tools for tuning parameters. The agent must infer everything about timing.

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