core.mul

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, closed-world), so the description adds genuine value by disclosing the precision contract: products beyond 50 significant digits are rounded to that many digits and no other rounding occurs. This is exactly the kind of numeric-semantics detail annotations cannot express. It stops short of saying anything about failure behavior for malformed input.

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?

Four short sentences, each carrying distinct information: purpose, input format, precision policy, and exclusion. Purpose is front-loaded and nothing 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, the description need not detail return values, and it still notes the result is returned as a string. Input format and rounding policy are fully covered. The only gap is the unexplained trace_level parameter, which is minor for an optional diagnostic field.

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%, so the description carries the full burden and does well on the required 'operands' parameter, spelling out that it is a list of numeric strings with no commas, units, or spaces. The optional 'trace_level' parameter is never mentioned, leaving one of two parameters entirely undocumented in both schema and description.

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 states a specific operation on a specific resource ('Decimal 정밀 곱셈') and names the return type, making it trivially distinguishable from core.add, core.sub, and core.div. An agent can tell what this tool does 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?

It explicitly routes the agent away from this tool for tax and interest calculations ('세금이나 이자 계산에는 전용 도구를 쓴다'), which is a real exclusion against siblings like accounting.vat_add or finance.*. It does not, however, state when to prefer this over core.calc or the other core arithmetic tools, so routing among the core.* family is left to inference.

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