crypto.lcm

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

Annotations cover the safety profile (readOnly, idempotent, closed-world), and the description adds behavior those annotations cannot express: sign is ignored, inputs are capped at 2048 digits, big integers are computed exactly, and either operand being 0 yields 0. What's missing is any note on error behavior for malformed or over-limit 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 with the core operation front-loaded, then constraints, then the zero edge case, then the use case. Dense and waste-free, though the fraction-reduction sentence is slightly tangential relative to the core definition.

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-format explanation is optional (the description mentions the integer-string result anyway), and the input contract, size limit and zero case are all stated. Only failure modes for invalid input are left unspecified.

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% (only bare 'A'/'B' titles), so the description must carry the load — and it does, stating both a and b are integer strings, that signs are ignored, and the 2048-digit limit. It doesn't say whether leading zeros or whitespace are tolerated, keeping it just below a 5.

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?

Names a specific verb+resource ('두 정수의 최소공배수(LCM)를 구한다') and pins down input/output types. It is clearly distinct from crypto.gcd / crypto.crt in practice, but never explicitly contrasts with those siblings, so an agent must infer the boundary.

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?

Gives a concrete usage context (fraction common denominators via the LCM of denominators) and one explicit exclusion ('소수 입력은 받지 않는다'). It does not name an alternative tool to use when the LCM is not what's wanted, so it stops short of full when/when-not routing.

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