SooTool

science.faraday_electrolysis

Read-onlyIdempotent

Calculates the mass deposited during electrolysis using Faraday’s law from current, time, molar mass, and number of electrons, assuming 100% current efficiency.

Instructions

패러데이 법칙으로 전기분해 시 석출되는 질량(g)을 계산한다. m = (I * t * M) / (n * F). current_a는 암페어, time_s는 초, molar_mass_g는 g/mol(모두 양수 Decimal 문자열), n_electrons는 양의 정수. F=96485.33212 C/mol이며 반올림하지 않는다. 시간을 분이나 시간 단위로 넣으면 안 되고 전류 효율은 100%로 가정한다.

Input Schema

Name	Required	Description	Default
`time_s`	Yes
`current_a`	Yes
`n_electrons`	Yes
`molar_mass_g`	Yes

Output Schema

Name	Required	Description
`_meta`	No	서버가 붙이는 영수증(integrity), 엔진, 힌트
`trace`	Yes	계산 근거(tool, formula, inputs, steps, output)
`mass_g`	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 the exact formula, Faraday constant value, no-rounding behavior, positivity constraints, and the 100% current-efficiency assumption. These are meaningful behavioral details for correct invocation and interpretation.

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 purpose and formula, then gives parameter units, the Faraday constant, and key constraints. It is compact and every sentence adds useful information.

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 simple calculation tool with an output schema and rich annotations, the description provides everything needed to call it correctly: formula, units, type constraints, constant value, rounding behavior, and efficiency assumption.

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 must carry parameter meaning, and it does: current_a is amperes, time_s is seconds, molar_mass_g is g/mol, and all three are positive Decimal strings, while n_electrons is a positive integer. It also maps parameters to the formula variables.

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 calculation: mass deposited during electrolysis using Faraday's law, and includes the exact formula. This clearly distinguishes it from sibling science tools such as molar_mass, stoichiometry, and battery_capacity.

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 gives clear input constraints, including that time_s must be seconds rather than minutes/hours and that current efficiency is assumed to be 100%. However, it does not explicitly route the agent away from related sibling tools or name alternatives.

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

Deploy Server