SooTool

engineering.beam_deflection

Read-onlyIdempotent

Calculates maximum beam deflection for standard point or uniform load cases from length, Young's modulus, inertia, and load inputs to support engineering checks.

Instructions

표준 하중 조건의 보 최대 처짐 δ_max 를 계산한다. case: cantilever_point_end(PL³/3EI), cantilever_uniform(wL⁴/8EI), simply_supported_point_center(PL³/48EI), simply_supported_uniform(5wL⁴/384EI). length m, young Pa, inertia m⁴, load 는 점하중 N 또는 등분포하중 N/m(모두 0 초과)이며 처짐은 m. 하중 종류와 case 가 어긋나면 값이 틀리고 전단 변형은 무시한다. 반올림 없이 50자리 유효숫자.

Input Schema

Name	Required	Description	Default
`case`	Yes
`load`	Yes
`young`	Yes
`length`	Yes
`inertia`	Yes

Output Schema

Name	Required	Description
`_meta`	No	서버가 붙이는 영수증(integrity), 엔진, 힌트
`trace`	Yes	계산 근거(tool, formula, inputs, steps, output)
`deflection`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses important behavioral assumptions: shear deformation is ignored, inputs must be positive, and results are returned without rounding to 50 significant digits. It also warns that load-type/case mismatch yields a wrong value.

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

Conciseness5/5

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

The description is front-loaded with the purpose, followed by case definitions, units, constraints, and precision behavior. Every sentence adds necessary information, and there is no filler.

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

Completeness5/5

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

For a five-parameter engineering calculation with an output schema and safety annotations, the description supplies the formula cases, units, positivity constraints, ignored effects, and precision behavior. Nothing essential for correct invocation is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden and does so well. It defines every parameter's meaning and units, lists all valid case values with their formulas, and explains that load is either a point load in N or a distributed load in N/m.

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

Purpose5/5

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

The description states a specific verb and resource: calculating a beam's maximum deflection δ_max under standard load conditions. It even names the four supported case formulas, which makes the tool's scope unambiguous and separates it from neighboring engineering calculators.

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

Usage Guidelines4/5

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

It clearly defines supported cases and warns that mismatching the load type with the case produces an incorrect value. It does not name alternative tools, but it gives enough context to select and use the correct calculation path.

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

Deploy Server