engineering.euler_buckling

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

Annotations already declare readOnly, idempotent, closed-world, so the safety profile is covered. The description adds genuine context beyond that: the validity envelope (slender vs short columns, possible result above yield) and 30-digit π precision. It does not say what happens when both K inputs or neither are supplied, nor how the string-typed numeric inputs are parsed.

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?

Five compact Korean sentences, front-loaded with the formula and units, then the K-selection rule, then the validity caveat. No sentence is redundant.

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 an output schema present, return values need no explanation, and the description covers formula, units, the mutually exclusive K inputs, and validity limits. Only the error/validation behavior for zero-or-two K inputs and numeric string formatting remain unstated.

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 bare `string` properties, so the description carries the full load — and it does well, mapping young/inertia/length to Pa/m⁴/m and enumerating all four K constants for end_condition. The gap is that all numeric parameters are typed as strings yet no accepted numeric string format is described.

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 names the exact physical quantity and formula (P_cr = π²EI/(KL)² in N), which unambiguously separates it from engineering.section_moment_inertia, moment_of_inertia, and beam_deflection. Units (Pa, m⁴, m) are stated for every physical input.

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?

It gives a clear selection rule between the two K paths — set end_condition or pass effective_length_factor, exactly one — plus an applicability caveat that the elastic formula over-predicts for short columns. It does not, however, point to siblings for computing I or for inelastic/Johnson buckling of stubby columns.

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