add_remote_force

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

No annotations are provided, so the description carries the full burden of behavioral disclosure for a mutation tool. It never says what the load is applied to, whether it is reversible or how to remove it, what permissions or model state are required, or whether the call mutates the active analysis — a substantial gap for a write operation.

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 definition is short and front-loaded, which is good, but the 'Args:' list consumes the entire body while adding nothing the schema does not already show. Half the text is dead weight.

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 described, but the definition omits the semantics of units, the meaning of analysis_index, requirements on the named selection, and how this tool relates to add_force and the other load-creation siblings. For a 5-parameter mutation tool with zero annotation and zero schema-description coverage, this is not enough 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 description coverage is 0%, so the description must compensate for five undocumented parameters. It merely repeats the parameter names verbatim; it does not explain that fx_n/fy_n/fz_n are force components (presumably in Newtons, implied only by the '_n' suffix) or what analysis_index selects.

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?

States a specific verb and resource ('Add Remote Force load'), so an agent knows it creates a remote force load. However, it does nothing to distinguish itself from siblings like add_force, add_reaction_force, or add_remote_displacement, leaving the choice between force variants to inference.

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?

There is no when-to-use or when-not-to-use guidance, no mention of prerequisites (an existing named selection, an active analysis), and no reference to alternative force tools. The only content beyond the title sentence is a bare list of argument names, which is not usage guidance.

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