SooTool

engineering.si_prefix_convert

Read-onlyIdempotent

Convert numeric values between SI prefixes using exact Decimal arithmetic; enter a value with source and target prefix names from yocto to yotta.

Instructions

수치를 SI 접두사 사이에서 환산한다. 결과 = value × 10^(from 지수 − to 지수)를 Decimal 로 정확히 계산한다. 접두사는 이름으로 넣고(yocto 부터 yotta 까지, 대소문자 무시, 빈 문자열이나 base 는 접두사 없음) 기호(k, M, µ)는 받지 않는다. 이진 접두사(KiB 등)와 단위 자체는 다루지 않으며 데이터 크기는 units_data_size_convert 를 쓴다.

Input Schema

Name	Required	Description	Default
`value`	Yes
`to_prefix`	Yes
`from_prefix`	Yes

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 29, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent), and the description adds genuinely useful behavior: exact Decimal arithmetic with no floating-point drift, case-insensitive prefix matching, and rejection of symbols/binary prefixes. These are invocation-relevant traits not present in the structured fields.

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?

Four sentences, each carrying distinct information: purpose, formula, valid inputs, exclusions plus sibling pointer. Front-loaded and free of repetition.

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?

An output schema exists so return values need not be documented, and the description fully covers input domain, arithmetic semantics, and the boundary with sibling tools. Nothing needed for correct invocation is missing.

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

Parameters4/5

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

Schema coverage is 0%, so the description must carry the load and largely does: it defines the accepted prefix namespace, case-insensitivity, and the empty-string/'base' convention for from_prefix and to_prefix. It does not clarify that 'value' is a string-typed parameter or its accepted format, leaving a small gap.

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?

States a specific verb and resource ('수치를 SI 접두사 사이에서 환산한다') and immediately gives the exact formula, so the operation is unambiguous. It also explicitly excludes binary prefixes and points to units_data_size_convert, distinguishing it from the nearest sibling.

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?

Clearly says what inputs are accepted (prefix names from yocto to yotta, case-insensitive, empty/'base' = no prefix) and what is not (symbols like k, M, µ; binary prefixes; units themselves). It names units_data_size_convert for data size. Lacks a direct comparison to units.convert, so not a full 5.

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

Deploy Server