physics_configure_boundary

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

No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is destructive, overwrites existing conditions, requires a prerequisite physics interface, or has side effects. The return info 'Created boundary condition info' is vague.

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

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

The description contains a clear main sentence but is lengthy due to extensive bullet lists for three physics types (Electrostatics, Solid Mechanics, Heat Transfer). The Args section is well-structured, but the common conditions list could be more concise or referenced via a link to documentation.

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

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

The tool has 5 parameters (3 required) and no output schema. The description explains parameters and provides example values per physics, but lacks details on how properties interact with boundary_condition, error handling, or prerequisites. For a configuration tool, it is moderately complete.

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

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

Schema coverage is 0%, so the description adds parameter meaning via the Args section, listing types and default values. It provides examples for boundary_condition per physics, but lacks allowed values as enums and does not detail the properties dictionary for each condition. Adds moderate value beyond the schema.

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

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

The description clearly states the tool configures a boundary condition for a physics interface, listing common boundary conditions per physics type (Electrostatics, Solid Mechanics, Heat Transfer). It distinguishes from sibling tools like physics_add_* which add interfaces, not configure boundaries.

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

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

The description provides a list of common boundary conditions but does not explicitly guide when to use this tool versus alternative boundary tools (e.g., physics_boundary_selection, physics_setup_flow_boundaries). No when-not-to-use or exclusion criteria are given.

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