remove_boundary

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.

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.

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.

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.

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.

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.