SooTool

crypto.is_prime

Read-onlyIdempotent

Test whether an integer string is prime using Miller-Rabin, with deterministic results below about 3.8e18 and probabilistic checks above; it does not factor numbers.

Instructions

Miller-Rabin 으로 소수 여부 is_prime(bool)을 판정한다. n 은 정수 문자열(자릿수 한도 2048)이며 2 미만과 음수는 False. 약 3.8e18 미만은 고정 증인이라 결정적이고, 그 이상은 무작위 증인 k 회(기본 20, 1~256)라 확률적이어서 True 가 소수 증명은 아니다. 소인수분해는 하지 않는다.

Input Schema

Name	Required	Description	Default
`k`	No
`n`	Yes

Output Schema

Name	Required	Description
`_meta`	No	서버가 붙이는 영수증(integrity), 엔진, 힌트
`trace`	Yes	계산 근거(tool, formula, inputs, steps, output)
`is_prime`	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?

Annotations already declare readOnlyHint/idempotentHint, and the description adds substantial behavior beyond them: the determinism threshold, the probabilistic tail with witness count, the 2048-digit input ceiling, edge-case handling (n < 2 and negatives return False), and the explicit caveat that True is not a primality proof.

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?

A single dense paragraph with zero filler — algorithm, input format, edge cases, determinism threshold, and caveats in that order. Every clause carries information an agent needs.

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 two-parameter read-only predicate with an output schema, nothing is missing: input format, limits, edge cases, and the interpretation of a True result are all covered, so the agent can call it and read the boolean correctly.

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 coverage is 0%, so the description must carry the load and it does: n is specified as an integer string with a digit limit and defined behavior for values below 2 and negatives; k is given a default (20), a valid range (1–256), and a meaning (random witness count). That fully compensates for the undocumented schema.

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+resource (판정한다 / 소수 여부 is_prime(bool)) plus the algorithm (Miller-Rabin), and explicitly excludes a neighboring capability with '소인수분해는 하지 않는다', so an agent can separate it from a factorization tool 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains precisely when the result is trustworthy: deterministic below ~3.8e18 via fixed witnesses, probabilistic above that with k random witnesses, and that True is not a proof of primality. It doesn't name an alternative sibling tool, which keeps it from a 5.

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

Deploy Server