crypto.egcd

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

Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered; the description adds genuinely non-obvious behavior: inputs are constrained to 2048-digit integer strings, the returned gcd is normalized to non-negative, and the Bezout coefficient pair is explicitly non-unique ('계수 쌍은 유일하지 않으며 이 알고리즘이 내는 한 쌍이다'). That non-uniqueness caveat is important for interpreting or comparing results, though the failure mode for inputs exceeding the digit limit is not described.

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, front-loaded with what is computed, then constraints, then the non-uniqueness caveat, then the sibling routing. Every sentence carries information the agent cannot get from the schema or annotations.

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?

An output schema exists, so return structure needn't be explained; the description instead covers what matters and isn't in the schema: input format/limits, output normalization (gcd ≥ 0), non-uniqueness of coefficients, and the alternative tool. For a 2-parameter pure function with full annotations, nothing an agent needs to call it correctly is missing.

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 description coverage is 0% (bare titles 'A'/'B'), so the description must compensate — and it does, stating both parameters are integer strings with a 2048-digit cap. It does not clarify sign handling (e.g. whether negative operands are accepted or how the gcd normalizes for them), leaving a small gap given zero schema help.

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?

States a specific verb and resource ('확장 유클리드 알고리즘으로 gcd(a, b) = a*x + b*y 를 만족하는 gcd 와 Bezout 계수 x, y 를 구한다') and names the identity it satisfies, which lets an agent distinguish it from crypto.gcd and crypto.lcm without opening the schema. The output is named explicitly (gcd plus the Bezout pair), so the purpose is unambiguous.

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?

Explicitly routes the agent to crypto.modinv when a modular inverse is the goal ('모듈러 역원이 목적이면 modinv 가 직접적이다'), which is the main competing sibling. It does not state when to prefer this over plain crypto.gcd (i.e. when only the gcd is needed), so the routing is clear but not exhaustive.

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