select_by_axis

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

With no annotations, the description carries the behavioral burden and does disclose key semantics: sign meaning (POS/NEG/ALIGN), extend behavior (add vs replace), and the return summary ('how many elements were selected'). It omits prerequisites like object/edit mode requirements and error behavior when no geometry lies on the chosen side.

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?

Front-loaded with purpose and usage before parameter details. The Args and Returns sections are efficient, though the Returns line is mildly redundant since an output schema exists.

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?

Complete enough for a mesh selection tool: purpose, usage, all parameters, extend behavior, and return count are covered. Minor gaps remain around execution context (mode, active object prerequisites) and edge cases, but they don't prevent correct invocation.

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; it fully does. It defines each parameter's meaning, including the non-obvious sign values (ALIGN = geometry lying in the plane) and extend's selection semantics, adding real value beyond the bare enum listings.

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 ('Select') and resource ('vertices, edges and faces on one side of a mesh along an axis'), which is distinct from siblings like select_objects or select_all_geometry. The first sentence alone lets an agent identify the operation 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?

Explains the canonical use case ('the usual way to say the top, the front or the left half of one object') and explicitly routes whole-object selection to select_objects. This gives both when-to-use and a concrete alternative.

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