CipherHUB Cryptography Toolkit

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

No annotations are provided, but the description discloses important behaviors: automatic PKCS7 padding on encryption and auto-removal on decryption, fixed 16-byte IV, output fields (output_data_in_hex, output_length, output_sha256, algorithm), and the requirement that decryption ciphertext lengths be multiples of 16 bytes. This goes well beyond what the schema provides.

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?

The description is well organized with labeled sections (算法, 参数, 自动行为, 输出, 注意) and front-loads the core operation. Every section conveys distinct operational information without redundancy or filler.

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?

Even without an output schema, the description specifies the output fields and critical constraints (algorithm-key length mapping, IV length, input size, padding behavior, decryption length requirement). This is sufficient for correct invocation and use of the tool.

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?

The input schema already documents all five parameters with 100% coverage, so the baseline is 3. The description adds useful semantic details such as key length per algorithm (16B vs 32B), IV fixed at 32 hex characters, and the decryption input length constraint, which are not fully obvious from the schema alone.

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 opens with '分组密码 CBC 模式加解密' (block cipher CBC mode encryption/decryption), giving a specific verb and resource. It further distinguishes itself from siblings like stream_cipher and zuc_cipher by naming CBC mode and the supported algorithms AES128/AES256/SM4.

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?

The description labels the tool as a symmetric block cipher in CBC mode and lists algorithm choices, making its intended use clear. However, it does not explicitly compare against sibling tools such as stream_cipher or state when not to use this tool, leaving usage guidance mostly implicit.

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

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

With no annotations present, the description carries the full burden and does it thoroughly: it discloses input size limit, automatic GM OID branch detection, dual fingerprinting, the 'informational only' nature of validity status, library implementation details, and the exact failure error code 'Certificate parse failed.' This goes well beyond minimal safety and operational transparency.

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?

The description is dense and long, yet each sentence serves a purpose: input constraints, output inventory, GM-specific behavior, implementation notes, and error handling. Some implementation/bibliographic detail could be trimmed, but the structure is front-loaded with the core purpose and remains organized, so the length is justified.

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?

There is no output schema, so the description must fully disclose what will be returned. It enumerates all major return fields, specifies GM-only additions, gives exact hex formats for SM2 public keys, states validity status behavior, and provides the failure error code. For a complex certificate parser with one input string, this is complete enough for an agent to call and interpret the result.

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 100%, so the baseline of 3 applies. The description repeats the PEM input and size constraint already in the schema but adds no new parameter-level meaning such as accepted encoding variants or handling of empty input. The schema and description are aligned, but the description does not elevate parameter understanding beyond the schema.

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?

Description begins with a specific verb and resource: parse X.509 certificates, and immediately distinguishes the two supported paths (international vs. GM SM2). The detailed list of returned fields makes the tool's scope unmistakable and differentiates it from sibling cert_verify by framing the operation as parsing rather than validation.

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?

The use case is implied: 'parse X.509 certificate' clearly signals an analysis/parsing task rather than verification. However, the description never explicitly states when to prefer this over cert_verify or any other sibling, and there are no exclusionary conditions. It provides clear context but no formal when/when-not guidance.

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

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

With no annotations provided, the description carries the full burden, and it is exceptionally transparent. It explains the two cryptographic code paths (GmSSL for GM certs, cryptography for RSA/EC/Ed25519), defines verified=false as a successful response with a reason taxonomy, clarifies that validity only affects time_status, and discloses the exact error condition for 'Certificate verify failed'.

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?

The description is front-loaded with the core purpose and scope, then adds dense but relevant implementation and response-semantics details. It is long, but nearly every clause contributes behavioral information an agent needs; there is only minor redundancy with the schema regarding sm2_id.

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?

For a complex verification tool with no output schema and no annotations, the description covers the essential contract: accepted cert types, algorithm selection, response boolean/reason/time_status semantics, and error boundaries. It does not explicitly state that both PEM parameters are mandatory despite schema defaults of '', nor describe the exact output envelope, so a small gap remains.

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 100%, and the schema already documents sm2_id's default, GM-only usage, size range, and PEM formatting for both certs. The prose adds algorithm-path context for sm2_id but does not materially change parameter semantics, so the baseline of 3 is appropriate.

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 opens with a specific verb and resource — '用 CA 证书验证终端实体证书' — and immediately narrows scope to single-level direct issuance. It explicitly excludes chain building and revocation checking, which distinguishes it from cert_parse and any broader validation tool.

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?

The description gives concrete context: use this tool for one-level direct CA issuance verification, and it explicitly states what it does not do (no chain building, no revocation checking). It does not name a sibling alternative or say 'use X instead', so it stops just short of the top score.

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

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

With no annotations, the description fully discloses behavior: encryption and decryption are the same XOR operation, there is no padding, ciphertext is the same length as plaintext, input range is 1B–16MB, and CTR provides no authentication. It also specifies the key-length requirements and the IV semantics, so the agent understands side effects and security limitations.

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?

The description is dense but every sentence contributes: mode semantics, key constraints, security caveat, and return fields. The only minor blemish is the duplicated leading tag '[symmetric_cipher] [symmetric_cipher]', which adds no value.

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?

Despite lacking an output schema, it lists the expected return fields (output_data_in_hex, output_length, output_sha256, algorithm) and covers all operational constraints needed to call the tool correctly. The security caveat and alternative-tool routing make the context complete for an agent.

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?

The schema already covers 100% of parameters, so the baseline is 3. The description adds meaningful beyond-schema detail by specifying exact key byte lengths, implementation origins (cryptography vs GmSSL, same source as eet sm4-ctr), and clarifying that iv_in_hex is the 16-byte initial counter block.

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 immediately states it performs CTR-mode encryption/decryption for AES-256-CTR and SM4-CTR, making the operation and scope explicit. It also distinguishes itself from stream_cipher's AEAD modes by naming them as the alternative when tamper resistance is required.

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 gives explicit guidance: use stream_cipher's AEAD modes when tamper resistance is needed, and use CTR only when there is already an independent authentication layer or an interoperability scenario. This clearly tells an agent when to select this tool versus its siblings.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It specifies the fixed 16-byte block size, the available actions (DoPadding/UnPadding), and the output fields (output_data_in_hex, output_length). It lacks details on edge-case behavior like invalid padding, but the core behavior is well covered.

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?

The description is compact and front-loaded with the tool's purpose. It is organized with clear sections (parameters, output, notes) and contains no fluff. Minor redundancy with the schema parameter descriptions prevents a perfect score.

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?

Given the tool's simplicity (2 parameters, no output schema, no nested objects), the description is reasonably complete. It explains the expected output and provides important context about block size and integration with block_cipher, though it lacks examples or explicit error handling.

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 100%, and the schema already provides detailed descriptions for both parameters. The description mostly restates the same information (e.g., DoPadding/UnPadding definitions) without adding new parameter semantics, so it meets the baseline but does not exceed it.

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 clearly identifies the tool as a PKCS7 padding/unpadding utility with a specific verb ('填充/去填充') and resource (data). It distinguishes itself from sibling tools by noting that block_cipher normally handles padding internally, which clarifies its specialized role.

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?

The description explicitly states when this tool is not needed ('通常无需单独调用此工具') and names the alternative (block_cipher) that already performs padding automatically. This gives clear usage direction, preventing unnecessary invocation.

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

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

No annotations are present, so the description carries full weight. It discloses the algorithm, output fields (derived_key_in_hex and derived_key_length), optional salt/info, length bounds, encrypted-private-key password handling, and unsupported curves. This goes well beyond the schema and gives the agent realistic expectations of behavior.

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?

The description is well-structured with clear section headers, a bullet list of parameters, an output section, and a curve-limitation note. It is front-loaded with the core purpose and every line adds relevant operational information without filler.

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?

Given no annotations and no output schema, the description compensates by specifying both outputs and key constraints. It covers all parameters, encryption-password behavior, and curve support. The only notable gap is lack of explicit comparison with sibling key-derivation or hybrid-key-exchange tools, though this is not essential for basic invocation.

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 100%, so the schema already documents all parameters. The description largely restates parameter meanings (e.g., private key, public key, hash algorithm, salt, info), adding only minimal extra context such as '不支持 Sm3' and '若私钥加密则传入'. This is useful but not a substantial semantic expansion beyond the schema.

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 explicitly states the operation: ECDH + HKDF key agreement using a private key and the counterpart's public key to derive the same symmetric key. This distinguishes it from sibling tools like hybrid_kex and key_derivation by naming the specific protocol and intended outcome.

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?

Clear context is provided: it is for two parties performing ECDH key exchange, with each side using their own private key and the other's public key. Curve restrictions are explicitly noted (Ed25519 unavailable, X25519 available), but no explicit guidance is given about when to prefer this over related siblings such as hybrid_kex.

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

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

With no annotations provided, the description explains internal behavior: raw mode triggers server-side hashing, digest mode expects a precomputed hash, and algorithm selection is curve-dependent. This goes beyond the basic purpose and helps predict behavior, though it omits edge cases or error handling.

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?

The description is well-structured with sections for parameters, output, and restrictions. It is front-loaded with purpose, though it repeats some schema details and could be slightly more concise.

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?

For a crypto signing tool with no annotations and no output schema, the description covers parameters, output fields, and curve restrictions. It could be more complete by describing the signature format or error conditions, but it provides enough for a competent agent to invoke the tool correctly.

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 100%, so the baseline is 3. The description adds some value by clarifying that EdDSA ignores hash_algorithm, but it introduces a mismatch by referring to 'plain_data_in_hex' while the schema defines the parameter as 'data_in_hex', which could confuse an agent.

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 opens with '[ecc] ECC 私钥签名', clearly identifying the operation as ECC private-key signing. It further specifies algorithm choice by curve (ECDSA vs EdDSA), which distinguishes it from sibling tools like ecc_key_verify or ecc_key_exchange.

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?

The description gives practical usage context: it explains raw vs digest mode, notes that EdDSA ignores hash_algorithm, and warns that X25519 cannot be used. However, it does not explicitly name alternative tools or state when to prefer this over ecc_key_verify.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses the output (verified bool, curve_name), algorithm behavior (ECDSA for SECP*, EdDSA for ED25519), and the constraint that sign_raw_data_mode and hash_algorithm must match the signing parameters. It also notes the X25519 limitation. However, it does not describe error scenarios or failure behavior, which prevents a perfect score.

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?

The description is well-structured with clear sections (purpose, parameters, output, limitation), and the purpose is front-loaded. It is concise but includes a parameter list that duplicates schema information and contains an inconsistency (plain_data_in_hex vs data_in_hex), which is a structural flaw. Overall, it is effectively organized but not flawless.

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?

The description covers purpose, parameter constraints, output format, and a curve restriction, which is a good level of detail for a tool with no output schema. However, the parameter name mismatch (plain_data_in_hex vs data_in_hex) creates a completeness gap that could lead to incorrect invocation. The tool has 5 parameters and moderate complexity, and the description should be more accurate to be fully complete.

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 100%, so the baseline is 3. The description adds some meaning (e.g., parameters must match signing values) but also introduces a critical mismatch: it lists 'plain_data_in_hex' while the schema defines 'data_in_hex'. This discrepancy undermines the added value and could mislead the agent. The description does not significantly enhance the parameter understanding beyond what the schema already provides.

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 clearly states the tool's function: 'ECC 公钥验签' (ECC public key signature verification). It distinguishes this from sibling tools like ecc_key_sign by focusing on verification, and adds algorithm-specific context (SECP* uses ECDSA, ED25519 uses EdDSA), making the purpose unambiguous and well-scoped.

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?

The description implies usage (verify an ECC signature) but does not explicitly state when to use this tool versus alternatives like rsa_verify or sm2_verify. The curve limitation (X25519 not usable) provides a limited exclusion, but there is no clear guidance on when to prefer this tool over other verification tools. The 'must be consistent with signing' notes hint at usage context but do not fully address alternative selection.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly lists the output fields (public_key_in_pem, private_key_in_pem, curve), mentions optional password protection for the private PEM, and details each curve's capabilities. This provides a solid picture of what happens when the tool is called, though it doesn't cover edge cases like error behavior or key format details.

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?

The description is well-structured with clear sections for curve list, parameters, output, and capability matrix. Each line serves a purpose, and the format is front-loaded with the primary action. It is dense but not bloated, efficiently conveying necessary information.

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?

Given the tool has no output schema, the description compensates by explicitly listing the three output fields. It also covers all curve options, capability restrictions, and parameter details. The tool's complexity is fully addressed, and the description provides enough information for an agent to invoke it correctly without ambiguity.

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 100%, so parameters are already documented. The description adds value by explaining the meaning of the curve parameter through the capability matrix and clarifying that private_key_password provides PEM encryption protection. This goes beyond the raw enum values in the schema.

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 begins with '生成 ECC 密钥对' (generate ECC key pair), which is a specific verb+resource statement that clearly identifies the tool's purpose. It distinguishes from sibling tools like ecc_key_sign, ecc_key_verify, and ecc_key_exchange, which perform subsequent operations rather than generation.

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?

The description provides a capability matrix mapping each curve to its supported operations (e.g., ED25519 only signing, X25519 only ECDH), giving clear context on when to use each variant. While it doesn't explicitly state 'use this instead of generate_rsa', the matrix effectively guides curve selection, which is the main usage decision for this tool.

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

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

No annotations are provided, so the description carries the burden. It discloses the source (OS CSPRNG), output encoding (Hex), and length limit. However, it does not mention error behavior on invalid input or other edge cases, leaving some behavioral opacity.

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?

Two compact sentences that front-load the core purpose with a '[random]' tag, followed by parameter and return field details. No filler or redundant information.

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?

The description covers purpose, parameter, and return fields, which is sufficient for a simple one-parameter tool without an output schema. It lacks error-handling details but is otherwise complete.

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 100% with a description already covering the byte count range (1-128). The tool description repeats this and adds return field semantics, adding marginal value beyond the schema but not significantly clarifying parameter meaning.

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 clearly states it 'generates secure random bytes using OS CSPRNG' with a specific verb and resource, and specifies the data_length range and return format. This distinguishes it from sibling key generation and crypto operation tools.

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?

The description implies usage for generating random byte strings via '[random]' and details the length and output format. It does not explicitly state when not to use it or mention alternatives, but the sibling context makes its purpose clear.

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

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

With no annotations, the description carries the full burden. It discloses that setting private_key_password encrypts the private key with AES-256-CBC, enumerates exact output field names, and explains the intended downstream use—behavior beyond what the schema provides.

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?

The description uses clear labeled sections (parameters, output, follow-up) and every phrase provides necessary context. No filler or redundancy, and the main purpose is front-loaded.

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?

For a tool with two optional parameters and no output schema, the description is fully self-contained: it lists all output fields, explains parameter effects, and links to related operations. An agent can select and invoke this tool without needing external documentation.

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?

The schema already covers both parameters with 100% description coverage, but the description adds the crucial encryption behavior for private_key_password (AES-256-CBC) that is absent from the schema. key_size is adequately described in both, though the description adds no new semantics for it.

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 explicitly states '生成 RSA 密钥对' (generate RSA key pair), naming the exact resource and action. It distinguishes itself from sibling key generation tools like generate_ecc and generate_sm2 by specifying RSA and identifying the output keys as PEM.

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?

Provides clear context by mapping the public key to rsa_encryption/rsa_verify and the private key to rsa_decryption/rsa_sign, telling the agent when this tool is appropriate. However, it does not explicitly contrast with alternative key generation tools or state when not to use it.

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

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

No annotations are present, so the description carries the full burden. It transparently discloses the algorithm/curve, the optional private_key_password for PEM encryption, and enumerates all output fields. It does not mention side effects, but for a key generation operation this is sufficient.

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?

The description is structured with clear sections for parameters, outputs, and follow-up operations. Every line provides useful information without redundancy or fluff, making it appropriately concise and front-loaded.

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?

For a tool with no output schema and no annotations, the description is quite complete: it lists all six outputs and explains how the keys will be used. Minor details like the exact PEM format are omitted, but the description covers the essential context for an AI agent to invoke the tool correctly.

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?

The schema already provides 100% coverage of the single parameter, so the baseline is 3. The description adds meaningful context by specifying that the password protects the private key PEM ('私钥 PEM 加密保护'), which clarifies the parameter's purpose beyond the schema's generic '加密密码'.

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 clearly states the verb+resource: "生成 SM2（SM2P256V1 / 国密曲线）密钥对" (generate SM2 key pair). It names the specific curve, distinguishing it from sibling tools like generate_ecc and generate_rsa.

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?

The description includes a【后续操作】section explaining that the public key is used for sm2_encryption/sm2_verify and the private key for sm2_decryption/sm2_sign, providing downstream context. However, it does not explicitly state when to select this tool over alternatives like generate_ecc or generate_rsa; usage is implied rather than directly instructed.

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

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

With no annotations, the description carries the behavioral disclosure burden. It clearly reveals that the public key is plaintext, the private key is ENCRYPTED, there is no plaintext private-key export, and the private key is KGC-held. It does not cover return mechanics like whether files or strings are emitted, but it covers the most critical operational constraints.

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?

The description is compact and information-dense, covering standard, key kinds, outputs, and password constraints. The duplicated '[sm9_ibc] [sm9_ibc]' prefix is redundant clutter and keeps it from a perfect score.

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?

For a security-sensitive generation tool with no annotations and no output schema, it explains inputs, outputs, and private-key encryption constraints well. It falls short on exact return payload shape, whether the tool writes files, and resolving the required/optional password contradiction.

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?

The description adds useful meaning to key_kind and specifies password length/encoding. However, it directly contradicts the schema and context signals by declaring private_key_password as required, while the schema marks it optional with default '' and indicates zero required parameters.

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 it generates SM9 identity-based master keys (GM/T 0044), which is a specific verb and resource. It further distinguishes Sign vs Enc key kinds, making it easy to differentiate from siblings like sm9_extract_key or generate_sm2.

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 gives clear guidance for choosing key_kind (Sign vs Enc), states the default, and describes who holds the public key. However, it does not explicitly mention when to prefer this tool over sibling tools such as sm9_extract_key.

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

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

No annotations are provided, so the description carries the full burden. It fully discloses the output structure (Results dictionary with hash_sum_in_hex and hash_length), explains the SHAKE XOF behavior with variable output length and key derivation usage, and describes the conditional activation of shake_output_length. This goes far beyond the schema.

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?

The description is well-structured using sections for algorithms, parameters, output, and SHAKE notes. It is front-loaded with purpose and every listed item adds value without unnecessary verbosity.

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?

Given no annotations and no output schema, the description provides a complete standalone reference: it covers input constraints, default behaviors, conditional parameters, exact output format, and edge-case explanations for SHAKE. Very few gaps remain.

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 100%, providing baseline 3. The description adds extra meaning: required_hash_modes defaults to all algorithms, shake_output_length only takes effect when SHAKE modes are requested, and plain_in_hex has a size range. These enrich parameter understanding beyond the schema.

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 explicitly states the tool '计算消息摘要' (computes message digest) and lists all supported algorithms (Sha1, Sha224, Sha256, etc.), clearly distinguishing it from sibling tools like hmac_sum which focus on HMAC. It has a specific verb and resource.

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 provides clear context for when to use the tool (computing hashes) and describes batch computation and algorithm selection. However, it does not explicitly contrast with alternatives like hmac_sum or state when not to use this tool, so it lacks explicit exclusions.

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

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

With no annotations provided, the description fully discloses the tool's behavior: it echoes client_msg and appends server_msg. It also explicitly lists the return fields (client_msg, server_msg), providing transparency beyond the schema alone. It does not explicitly state there are no side effects, but the utility nature is implied.

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?

The description is extremely concise: two well-structured sentences. It front-loads the tool type [utility] and health check purpose, then details the behavior and return fields. Every sentence earns its place with zero waste.

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?

For a simple echo utility with one parameter and no output schema, the description is complete. It explains the purpose, the exact behavior, the parameter's role, and both return fields. An agent can confidently invoke this tool correctly based on the provided information.

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 100%: client_msg is already described as '任意字符串，服务端原样回显（原始字符串，非编码格式）'. The tool description reiterates this same meaning without adding new parameter-level details, so it provides no additional value beyond the schema.

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?

Description clearly states it is a health check / echo interface, with a specific verb ('回显' - echo back) and resource (client_msg). It explicitly distinguishes itself from sibling crypto tools by describing its utility purpose (verifying MCP channel connectivity).

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?

The description explicitly states the intended use case: '用于验证 MCP 通道连通性' (to verify MCP channel connectivity). It provides clear context for when to use the tool, though it doesn't describe exclusions or alternatives, which is acceptable given the sibling tools are unrelated crypto functions.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses important behaviors such as RFC 2104 key handling, key size limits, the '超块大小会先哈希' behavior, default computation of all 6 algorithms, and the output dictionary structure. It does not, however, state behavior when key_in_hex or plain_in_hex are omitted despite the schema marking all parameters optional.

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?

The description is well-structured with clear sections for algorithms, parameters, output, and typical uses. It is concise for the complexity involved, with no redundant filler; every section contributes actionable information.

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?

Given the absence of an output schema, the description properly explains the return structure, algorithm options, input size constraints, and default behavior. The main gap is that required parameters are not explicitly marked as mandatory, which is especially relevant because the schema reports 0 required parameters; a caller might attempt an invalid call without plain_in_hex.

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 100%, so baseline is 3, but the description adds substantial meaning: key hex ranges, SM3-specific 64-byte limit, plain data range, default modes, and explicit rejection of SHAKE. The value is slightly reduced because the schema's key_in_hex description incorrectly references AES/SM4 key lengths, creating cross-source confusion that the description does not directly reconcile.

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 opens with a specific action and resource: '计算 HMAC（基于哈希的消息认证码）' and lists supported algorithms, making it unmistakable that this tool produces keyed HMAC digests. This clearly differentiates it from sibling tools such as hash_sum, which likely produces plain hashes.

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?

The description provides clear use context through '典型用途' (message integrity, API signing, key confirmation) and explicitly excludes SHAKE algorithms with a reason. However, it does not name alternatives like hash_sum or give explicit when-not-to-use guidance beyond the SHAKE exclusion.

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

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

With no annotations provided, the description carries the full burden, and it does so thoroughly: it discloses that blank keys are generated via CSPRNG, that ML-KEM public and private keys must be provided together, accepted encodings, the HKDF-SHA256 derivation flow, output including keys_match, and the claimed security level. It even warns that this is not the X-Wing combiner itself, preventing misuse.

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?

The description is well-structured with clear sections: summary, design note, parameters, flow, output, and security level. It front-loads the purpose and keeps each section dense and relevant; the X-Wing caveat and security statement earn their place for a cryptographic demo tool.

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?

For a complex 8-parameter tool with no output schema, the description covers the flow, input optionality, key-format constraints, derivation process, and result verification through keys_match. It is slightly vague about exactly which 'intermediate values' are returned, but overall an agent has enough context to invoke the tool correctly.

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?

The description adds meaning by organizing the eight parameters by Alice/Bob side, explaining raw vs SPKI/PKCS#8 Base64 formats, and emphasizing the paired public/private key requirement. Much of this is already present in the schema description, so the added value is mostly consolidation and clearer framing rather than entirely new semantics.

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 clearly states a specific verb and resource: '执行 X25519 + ML-KEM-768 混合密钥交换全流程演示'. It distinguishes itself from sibling single-algorithm tools like ml_kem_encap, ml_kem_decap, and ecc_key_exchange by describing a hybrid full-flow demo. It also clarifies that it implements a generic concatenation combiner rather than the X-Wing specification.

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?

The description strongly implies usage as a full hybrid key-exchange demo and explains the flow, but it never explicitly states when to prefer this tool over siblings such as ml_kem_encap/ml_kem_decap or ecc_key_exchange. It includes setup conditions, like 'all parameters optional' and 'keys generated randomly if blank', but lacks explicit when-to-use/when-not-to-use guidance.

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

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

无任何 annotations，描述承载了全部行为披露责任。它详细说明了 HKDF 的 extract-then-expand 过程、Pbkdf2Sm3 空盐时服务端生成随机盐并在响应回显、RFC 5869 空盐补零行为、iterations 受 8s 网关约束、输出字段等。行为透明度和副作用说明远超一般工具描述。

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?

描述结构清晰：先一句话概述目的，再用“【支持算法】【参数】【输出】【典型用途】”分节。内容密度高但每一条都有具体指导价值，没有任何冗余空话。虽长度可观，但鉴于工具本身涉及三种算法和 8 个参数，这种详尽程度是合理且必要的。

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?

工具复杂度高（8 参数、3 算法、算法间参数互斥），且无输出 schema，但描述提供了完整的输出字段清单（derived_key_in_hex、salt_used_in_hex、salt_generated 等），并补充了跨参数约束、长度范围、错误行为（错配被拒）和性能上限。即使没有输出 schema，智能体也能据此预期返回值并正确调用。

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 描述覆盖率为 100%，但描述在 schema 基础上补充了大量语义，如每个参数适用的算法（hash_algorithm 仅 HKDF、password 仅 Pbkdf2Sm3）、输入长度限制、默认值说明、Pbkdf2Sm3 空盐的服务端回显行为、iterations 的互通测试建议区间等。这些信息对正确构造参数至关重要，远非重复 schema 可替代。

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?

明确以动词“执行密钥派生（KDF）”开头，点明核心资源与目标（从高熵秘密或口令派生对称密钥材料），并列出三种支持算法。与同组工具（如 hash_sum、hmac_sum、sm2_decryption 等）明显区分，无歧义。

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?

描述给出了清晰的使用场景与算法选择依据，如“HKDF（默认）”“Sm3Kdf 适合对 SM2 ECDH 共享秘密派生密钥”“Pbkdf2Sm3 用于口令拉伸”，并提及“典型用途”和“参数按算法适用，错配会被拒”。虽未显式与兄弟工具做“何时不用”的对比，但对一个独立 KDF 工具而言，使用指引已足够充分。

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

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

No annotations are provided, so the description takes on the full burden. It thoroughly discloses behavior: the exact formula, input validation (OID/length consistency check), constraints (max message 2048 bytes, max context 255 bytes), and all output fields. This is well beyond a mere 'compute mu' statement.

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?

The description is well-structured with sections for purpose, usage, formula, parameters, and output. Every sentence adds value, and the most important information (what it does) is front-loaded. Length is justified given the technical complexity.

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?

Given there is no output schema, the description appropriately lists all output fields. It covers the formula, input requirements, constraints, and purpose, making the tool fully usable without external documentation. This is a complete description for a computation tool.

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?

The schema already covers 100% of parameters with basic descriptions, but the tool description adds meaningful semantics: public key can be SPKI DER or bare, message empty string means empty message, and size limits for message and context. This adds real value beyond the schema.

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 clearly states the tool's function: independently compute the 64-byte mu value for ML-DSA per FIPS 204 Section 6.2. It also distinguishes itself from siblings like ml_dsa_sign and ml_dsa_verify by specifying it is for EXTERNAL_MU mode intermediate values.

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?

The description explicitly names the two use cases: verifying/debugging EXTERNAL_MU mode intermediate values and integrating with AWS KMS EXTERNAL_MU signing flow. It does not explicitly state when not to use it compared to sibling signing/verification tools, but the use cases are clear enough.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly details all output fields and their formats (SPKI DER hex for public key, PKCS#8 DER hex for private key, base64 encodings, etc.). However, it does not explicitly state that a new random key pair is generated each time or discuss any side effects, though for a keygen tool the generation semantics are largely implicit.

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?

The description is well-organized with clear labeled sections (e.g., algorithm selection, security level reference, output, typical usage). It is dense but every sentence adds unique value, and nothing is redundant or filler. The structure makes the information easy to scan.

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?

For a tool with only one optional parameter and no output schema, the description is remarkably complete: it lists all return fields, explains the algorithm variants, and connects to the typical key life-cycle with related tools. There are no significant informational gaps that would prevent correct invocation.

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?

The input schema already provides full coverage of the single `algorithm` parameter with enum values and a default. The description adds meaningful context by mapping each algorithm to NIST security levels and AES equivalents, which helps an agent choose an appropriate value. This goes beyond the schema's bare enum labels.

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 clearly states the tool generates ML-DSA key pairs per FIPS 204, using a specific verb ('generates') and resource ('ML-DSA key pair'). It also differentiates from sibling tools by naming related sign/verify tools and other key generation tools, making its purpose unmistakable.

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?

The description provides concrete usage context: 'after generating, the private key is used for ml_dsa_sign and the public key for ml_dsa_verify'. It also explains algorithm choices and security levels. It does not explicitly name alternatives or when NOT to use this tool, but the integration with sibling tools offers clear practical guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure and does so excellently. It reveals the exact message-length limits, the auto-switch behavior between RAW and EXTERNAL_MU, the acceptance of empty messages, the algorithm options, and the full output field set. This goes well beyond a simple 'sign' statement and gives the agent a reliable mental model.

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?

The description is relatively long but well-structured with clear section headers and bullet points. It is front-loaded with the tool's purpose, then systematically covers modes, length policy, algorithm, parameters, and output. While some redundancy exists (e.g., length limits repeated for each mode), every sentence contributes necessary information, making it concise enough for its complexity.

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?

Given six parameters, dual modes, length constraints, and no output schema, the description is remarkably complete. It explicitly lists all output fields, describes when each parameter is needed, covers edge cases like empty messages and oversize rejection, and even adds domain context (FIPS 204 and AWS KMS equivalence). There are no obvious missing pieces that an agent would need for successful invocation.

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?

Though schema coverage is 100%, the schema descriptions are generic (e.g., '十六进制字符串'). The tool description adds crucial semantics: private_key_in_hex is sourced from ml_dsa_keygen, public_key_spki_in_hex is mandatory only for EXTERNAL_MU, context_in_hex is capped at 255 bytes, and sign_mode values are explained with their behavioral consequences. This is essential for correct invocation.

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 opens with '使用 ML-DSA 私钥对消息签名（FIPS 204）', which is a clear and specific verb+resource statement. It distinguishes the tool from siblings like ml_dsa_verify and ml_dsa_compute_mu by clearly marking it as the signing operation, and even elaborates the two signing modes, leaving no doubt about its primary function.

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?

The description provides explicit usage guidance: RAW mode for messages up to 256 bytes, EXTERNAL_MU for up to 2048 bytes, an automatic switching rule for 256–2048 bytes, and a rejection rule above 2048 bytes. It also states that public_key_spki_in_hex is required only in EXTERNAL_MU mode, giving the agent clear when-to-use and prerequisite information.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses byte limits (256/2048), legal empty messages, key format flexibility (SPKI DER or raw), OID/length validation, OpenSSL 3.5+ dependency for EXTERNAL_MU, and the exact output fields. This is rich, actionable behavioral context.

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?

The description is well-structured with clearly labeled sections (双模式, 算法, 参数, 输出) and uses bullet points for readability. Every sentence carries important information with no repetition or fluff, making it efficient despite its length.

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?

For a tool with 6 parameters, multiple modes, and algorithm variants, the description covers all essential aspects: purpose, mode semantics, algorithm options, parameter details, constraints, and output structure. Since there is no output schema, it even lists output fields. This is a complete standalone reference.

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?

Although the schema covers 100% of parameters, the description adds critical semantics beyond field names: public_key_spki_in_hex accepts SPKI or raw and is validated against algorithm, message_in_hex empty means empty message, context_in_hex must match signing context, and sign_mode behavior is explained with byte limits. This elevates the parameter understanding well above the baseline.

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 clearly states '使用 ML-DSA 公钥验证签名' (verify signature using ML-DSA public key) and references FIPS 204. It distinguishes this tool from siblings like ml_dsa_sign and ml_dsa_compute_mu by explicitly scoping it to verification, and provides specific mode and algorithm details that reinforce its unique purpose.

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?

The description gives explicit guidance on when to use each sign_mode (RAW vs EXTERNAL_MU), including a concrete use case (AWS KMS EXTERNAL_MU signatures) and constraints like message size limits. It doesn't explicitly name alternative tools for exclusion, but the sibling list and algorithm scope make the intended usage clear.

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

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

With no annotations, the description fully discloses key behavioral traits: implicit rejection on tampered ciphertext (returns deterministic pseudo-random value, no exception), IND-CCA2 security, and no private key leakage. It also explicitly lists all output fields. This is rich behavioral context that goes well beyond the schema.

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?

The description is well-structured with clear sections for algorithm, parameters, output, security, and full process. Every sentence adds value, and the purpose is front-loaded. It is appropriately sized for the tool's complexity.

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?

Despite having no output schema, the description enumerates all output fields and covers algorithm variants, parameter origins, security behavior, and the overall workflow. This is complete enough for an agent to understand and use the tool correctly.

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?

Although schema coverage is 100%, the description adds critical provenance semantics: it specifies that algorithm must match keygen/encap, secret_key_in_hex comes from ml_kem_keygen, and ciphertext_in_hex from ml_kem_encap. This greatly aids correct tool invocation.

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 explicitly states the tool performs key decapsulation using an ML-KEM private key (FIPS 203), naming the specific algorithms (ML-KEM-512/768/1024). This clearly distinguishes it from sibling tools like ml_kem_encap and ml_kem_keygen.

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?

The description provides the complete flow (keygen → encap → decap) and states that parameters must align with keygen/encap outputs. This gives clear context for when to use the tool, though it doesn't explicitly mention when not to use it or name alternatives.

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

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

With no annotations provided, the description discloses crucial runtime behavior: each encaps produces a different ciphertext due to randomization, and the shared secret is always 32 bytes. It also lists the exact output fields, which goes beyond a simple 'performs encapsulation' statement.

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?

The description is dense yet concise, front-loading the purpose, then organizing parameters, outputs, and usage notes in clearly labeled sections. Every sentence contributes value, with no redundant wording or filler.

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?

The tool is complex (post-quantum KEM) and has no output schema, but the description enumerates all output fields, explains the randomized behavior, and states the intended usage with ml_kem_decap. This gives the agent everything needed to understand the tool's role within the sibling set.

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 100%, so the parameters are already documented, but the description adds critical cross-tool semantics: algorithm must match the keygen step, and public_key_in_hex is specifically the output of ml_kem_keygen. This connects the parameters to the actual workflow, exceeding the schema's generic descriptions.

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 the exact action: '使用 ML-KEM 公钥执行密钥封装（FIPS 203）', specifying the algorithm variant (ML-KEM-512/768/1024) and naming the standard. It clearly distinguishes from siblings by explicitly referencing ml_kem_decap as the counterpart and ml_kem_keygen for key generation.

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?

The description gives clear context: algorithm '必须与 keygen 时一致' and public_key_in_hex comes from 'ml_kem_keygen 返回的公钥 hex'. It also describes the intended workflow (send ciphertext, counterpart uses ml_kem_decap), but does not explicitly state when to use this tool instead of other key exchange or encryption tools.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses deterministic generation via a provided seed, the CSPRNG option when use_random_seed is true, and the complete set of output fields. It also names the standard and NIST security levels. However, it omits potential error conditions and side-effect behavior, which would be useful for a tool that generates sensitive key material.

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?

The description is well-organized into labeled sections (algorithm, parameters, outputs, subsequent operations), with every sentence contributing necessary information. It is compact enough for an agent to parse quickly while providing a complete overview of the tool's behavior.

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?

Given there is no output schema, the description compensates by enumerating all nine output fields and explaining the downstream workflow. It covers algorithm selection, parameter semantics, and output formats. Minor gaps include lack of error-handling details, but overall the tool description is contextually complete for a key generation operation.

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?

The schema already describes all three parameters with high coverage (100%), so the baseline is 3. The description adds value beyond the schema by noting that seed_in_hex enables deterministic generation, that use_random_seed overrides the seed, and by mapping each algorithm choice to a NIST security level—additional context not present in the schema descriptions.

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 clearly states its core function with a specific verb and resource: '生成 ML-KEM 密钥对' (generate ML-KEM key pair) and names the FIPS 203 standard. This distinguishes it from sibling operations like ml_kem_encap and ml_kem_decap, which are explicitly referenced as downstream uses for the generated keys.

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?

The description provides clear guidance on when to use this tool by explaining the algorithm options (with a recommendation for ML-KEM-768) and specifying that the public key is used for ml_kem_encap and the private key for ml_kem_decap. It does not offer explicit 'when-not-to-use' exclusions, but the downstream workflow makes the usage context unmistakable.

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

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

With no annotations provided, the description carries the behavioral disclosure burden and does well by specifying cipher length requirements ('长度 = key_size/8 字节'), the need for padding-mode consistency, conditional password use, and the output fields ('plain_data_in_hex、plain_length'). It does not discuss failure modes, but the disclosed operational constraints are meaningful.

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?

The description is compact, front-loaded with the core purpose, and uses a clear structured parameter/output layout. Every line adds either a parameter meaning or an operational constraint, with no redundant filler.

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?

Given there is no output schema, the description correctly specifies the return values (plain_data_in_hex, plain_length). It also clarifies key constraints such as cipher length and padding consistency. A minor gap is that it does not explicitly mark which parameters are mandatory despite the schema listing all 4 as optional, but the purpose and parameter notes largely compensate.

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 100%, so the baseline is 3. The description adds value beyond the schema by explaining that rsa_padding_mode must match encryption, that password is only needed for protected private keys, and that cipher_data_in_hex length must equal key_size/8 bytes.

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 opens with 'RSA 私钥解密', a specific verb and resource that clearly identifies this as a private-key decryption tool. It does not explicitly differentiate itself from siblings like rsa_encryption, rsa_sign, or rsa_verify, but the operation is clear enough to avoid confusion.

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?

The description implies usage: use this when RSA private-key decryption is needed, and it adds important operational guidance such as 'rsa_padding_mode 必须与加密时一致' and '若私钥有密码保护则传入'. However, it does not explicitly name alternatives or state when not to use the tool.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals output fields (cipher_data_in_hex, cipher_length), documents plaintext length limits per padding mode, and explains the trade-off between PKCS1v1.5 and OAEP. This is substantial operational detail beyond the schema, though it stops short of describing error behavior on invalid PEM or oversized 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?

The description is well organized into labeled sections: parameters, length limits, output, and security advice. Every section delivers actionable information with no filler, and the most important purpose is front-loaded in the first sentence. It is detailed yet compact.

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?

Given there is no output schema, the description compensates by naming the output fields. It covers all three parameters and adds operationally critical length constraints. The only notable omission is that it does not state that all three parameters are effectively required for the operation, while the schema lists required parameters as 0.

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 100%, so the baseline is 3. The description adds meaningful semantics by tying parameters to behavior: it explains how rsa_padding_mode interacts with plaintext length limits and gives concrete byte caps (e.g., RSA-4096 + OAEP-SHA256 = 446 bytes). It reinforces the meaning of rsa_public_key_in_pem and plain_data_in_hex beyond the schema text.

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 'RSA 公钥加密' (RSA public-key encryption), a specific verb-resource pair that immediately distinguishes this tool from siblings like rsa_decryption and rsa_sign. The scope is unambiguous: encrypt plaintext with a PEM public key. This clearly differentiates it without needing to inspect sibling schemas.

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?

The description explicitly frames the tool as public-key encryption, providing clear context for when to invoke it versus decryption/signing siblings. It also gives concrete guiding advice on padding choice ('推荐使用 OAEP 而非 PKCS1v1.5'). It does not explicitly name alternatives or exclusions, but the encryption-specific wording is sufficient.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It explains the raw-data-mode behavior (internal hashing vs. pre-digest), the optional password handling, and the outputs signature_in_hex and signature_length. It does not discuss failure cases or side effects, but for a signing tool the disclosed behavior is substantial.

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?

The description is well-structured with labeled sections for parameters, output, and security advice, and every section carries useful information. It avoids narrative padding and uses a compact notation for the padding-mode variants, making it easy for an agent to scan.

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?

Despite having no annotations or output schema, the description covers the key parameters, explains the raw-data distinction, lists outputs, and gives a security guideline. It could be slightly stronger by explicitly stating which parameters are mandatory (e.g., private key and data are logically required even though the schema marks all as optional), but it is otherwise complete enough for correct invocation.

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?

The input schema already describes all five parameters at 100% coverage, so the baseline is 3. The description restates the parameter meanings in a compact reference format and adds the output section, but it does not materially add semantic meaning beyond the schema's existing parameter descriptions.

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 opens with a specific operation, 'RSA 私钥签名' (RSA private-key signing), which clearly identifies both the algorithm and the action. This distinguishes it from sibling tools like rsa_verify, rsa_encryption, and rsa_decryption without needing to inspect their schemas.

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?

The description gives clear context that this tool is for signing with an RSA private key and even adds a security recommendation to prefer PSS over PKCS1v1.5. It does not explicitly name alternatives or when-not-to-use conditions, so it stops short of a 5, but the usage context is clear enough.

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

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

Description discloses the output format 'verified (bool, True=验签通过)' and the matching constraint. With no annotations, it does not describe behavior on invalid input (e.g., whether exceptions are thrown or simply returns False).

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?

The description is compact, using a bulleted list to organize parameters and output. It contains no redundant prose and is easily scannable.

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?

The tool is relatively simple and all parameters are documented in the schema. The description provides the output type and key constraints, but lacks explicit error handling or return-code details. Given no output schema, it partially compensates with the bool output note.

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?

Input schema has 100% coverage, but the description adds a critical constraint that rsa_sign_padding_mode and rsa_sign_raw_data_mode must match the signing parameters, which is not in the schema. It also succinctly restates each parameter's purpose.

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?

Description clearly states 'RSA 公钥验签' (RSA public key signature verification), which is a specific verb+resource. It distinguishes from sibling tools like rsa_sign (signing) and ecc_key_verify/sm2_verify (other algorithms).

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?

The description notes that padding mode and raw data mode '必须与签名时一致' (must match signing time), which is important usage guidance. However, it does not explicitly state when to choose this tool over other verification tools (e.g., ecc_key_verify, sm2_verify).

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the output fields (plain_data_in_hex, plain_length) and warns that a mismatch in cipher_format leads to failure. It also covers the condition for providing a password, which is useful behavioral context beyond a bare function signature.

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?

The description is highly structured with sections for parameters, output, and notes. It is concise, with no wasted words, and front-loads the purpose. Each line serves a distinct function, making it easy to scan.

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?

For a cryptographic tool with 4 parameters and no output schema, the description covers the essential aspects: purpose, parameter formats, output fields, and a critical failure condition. It is sufficient for an AI agent to invoke the tool correctly.

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 100%, so the baseline is 3. The description adds value by emphasizing that cipher_format is mandatory ('必须指定'), clarifying that the key is in PEM format, and explaining when the password is required. These details go beyond the schema descriptions.

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 clearly states 'SM2 私钥解密' (SM2 private key decryption), specifying the exact operation and resource. It distinguishes from siblings like sm2_encryption and sm2_sign by focusing on decryption with private key.

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?

Provides clear usage context: cipher_format must be specified and must match the encryption format, otherwise decryption fails. It also notes when the private key password is needed. However, it does not explicitly mention alternatives like sm2_encryption for the reverse operation, so it lacks explicit exclusions.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It explains the output dictionary structure with four encoding formats and explicitly warns that ciphertexts vary due to a random k, which is a key behavioral trait. It does not mention potential input length limits or error cases, but the core behavior is well covered.

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?

The description is well-structured with clear sections for parameters, output, and notes. It is concise, front-loads the purpose, and every sentence provides useful information without redundancy.

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?

Given the absence of an output schema, the description thoroughly explains the return format (a dictionary with four encoding options) and highlights the non-deterministic nature of encryption. For a tool with two parameters and no output schema, this is complete enough for an agent to invoke and interpret results correctly.

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?

The input schema already provides complete descriptions for both parameters (100% schema coverage). The description reiterates the parameter names and formats but adds little beyond the schema. It does not introduce constraints or additional semantics, so it meets the baseline for high schema coverage.

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 clearly states 'SM2 公钥加密' (SM2 public key encryption), specifying the verb (encrypt) and resource (SM2 public key). It effectively distinguishes this from sibling tools like sm2_decryption and sm2_sign.

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?

The description provides clear context that this tool performs SM2 public key encryption and explains the output formats. However, it does not explicitly mention when to use it versus alternatives (e.g., sm2_decryption) or any exclusions, so it lacks direct usage guidance relative to siblings.

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

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

With no annotations provided, the description carries the full burden. It clearly discloses that the tool does not reveal the private key value (a critical safety behavior), returns a JSON view of ASN.1 structure, and lists expected fields (OID, salt, iteration count). This goes beyond simple tautology and gives meaningful behavioral context.

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?

The description is two short, front-loaded sentences. It starts with the tool's purpose, then covers safety and return format without any redundant or verbose language. Every sentence earns its place, making it highly concise and well-structured.

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?

Since there is no output schema, the description appropriately explains the return field 'structure' with details about its contents. It covers the input format (PEM), the tool's purpose, and a key safety guarantee. Minor gaps like error handling on malformed PEM are not addressed, but for a single-parameter parse tool, the description is sufficiently complete.

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 100% for the single parameter, so the baseline is 3. The tool description does not add any parameter semantics beyond what the schema already provides; it only mentions the PEM format implicitly. No additional meaning or usage details are given.

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 specifies the verb '解析' (parse), the resource 'SM2 加密私钥 PEM 结构', and the outcome '返回 ASN.1 内部字段的 JSON 视图'. It clearly distinguishes this tool from sibling crypto operations by focusing on structural parsing rather than encryption/decryption/signing. The scope is well-defined and specific.

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?

The description states the intended usage context ('用于调试与教学') and implies it is not for extracting private key values ('不会解出私钥值'). However, it does not explicitly name alternative tools for key extraction or decryption, which would earn a 5. Still, the context is clear and the exclusion is present.

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

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

With no annotations available, the description carries the full burden and does well by disclosing the output format (130 hex chars, 65 bytes) and the 04||X||Y structure. It does not mention error behavior or input validation, but for a stateless conversion tool this is a minor gap.

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?

Two short sentences deliver all core information without redundancy. The description is appropriately front-loaded and every clause adds value.

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?

For a simple one-parameter conversion tool with no output schema, the description is nearly complete: it names the return field, gives the exact hex length, and specifies the encoding. It could optionally note that the input must be a valid SM2 key, but this is implied by the tool name and purpose.

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?

The schema already documents the single parameter with a complete description (PEM text with BEGIN/END headers). The tool description adds no further parameter-level meaning, aligning with the baseline for 100% schema coverage.

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 clearly states the tool converts an SM2 PEM public key into raw hex encoding (uncompressed point 04||X||Y), specifying the exact output field and byte length. This specific verb+resource+outcome strongly distinguishes it from sibling SM2 tools like sm2_sign or sm2_verify.

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?

No explicit when-to-use guidance or alternatives are mentioned. The usage is implied from the description, but there is no comparison with similar tools (e.g., sm2_private_key_structure_parse) or exclusions for other key formats.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It fully explains that RAW mode performs an internal SM3 hash (e = SM3(ZA||M)) while DIGEST mode does not, describes output formats (RS and RS_ASN1), and warns that verification must use RS_ASN1 and the same mode. No annotation contradictions exist.

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?

The description is well-structured with a parameter list and output section, using bold and bullets for readability. However, it repeats parameter names and schema descriptions, adding some redundancy. Still, it is compact enough and each section carries meaningful detail, hence a 4.

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?

For a cryptographic signing tool with no output schema, the description is remarkably complete: it covers all input parameters, both operation modes, the exact output structure (RS and RS_ASN1), and a verification caveat. There is no missing behavioral context that an agent would need to invoke this tool correctly.

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?

Although schema coverage is 100%, the description adds critical meaning beyond the schema: it specifies that data_in_hex must be exactly 64 hex characters in DIGEST mode, clarifies that sm2_private_key_password is only needed if the key is encrypted, and explains how sign_raw_data_mode changes the interpretation of data_in_hex. This is substantial added value.

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 begins with 'SM2 私钥签名' (SM2 private key signing), clearly stating the operation and algorithm. It distinguishes from sibling tools like ECC/RSA signing by specifying SM2 and detailing the signing modes, leaving no ambiguity about scope.

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?

The description provides clear guidance on when to use RAW vs DIGEST modes, explicitly explaining the behavior of sign_raw_data_mode and the semantics of data_in_hex in each. It references that DIGEST mode aligns with other tools' DIGEST mode, but does not explicitly name alternative tools or state when NOT to use this tool, so it is not a full 5.

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

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

With no annotations provided, the description carries full responsibility and does an excellent job. It discloses that RAW mode triggers the server to internally compute e = SM3(ZA || M) before verification, while DIGEST mode performs no implicit SM3 and directly verifies the provided digest. It also specifies the fixed signature format and the boolean output, giving complete insight into the tool's behavior.

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?

The description is well-structured with clear labels for parameters, output, and workflow. While it is longer than a simple two-liner, the complexity of the two-mode behavior justifies the length. The core purpose is front-loaded in the first sentence, and the bullet-style formatting improves readability. Some redundancy with the schema exists, but it remains tightly organized.

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?

The tool has 5 parameters and no output schema, yet the description compensates fully. It states the output is 'verified (bool)' explicitly, covers all parameters with mode-specific explanations, and provides a complete workflow reference. For a cryptographic verification tool with this level of complexity, the description is exceptionally complete.

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 100%, setting the baseline at 3. The description significantly enhances the schema by explaining the exact hex length requirement for DIGEST mode (64 hex characters for a 32-byte SM3 digest), the internal transformation e = SM3(ZA || M), and the critical constraint that sign_raw_data_mode must align with the signing mode. These details add substantial practical meaning beyond the parameter titles.

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 starts with 'SM2 公钥验签' (SM2 public key verification), clearly stating the tool's specific action and resource. It distinguishes itself from sibling tools like sm2_sign and sm2_encryption by mentioning the complete flow 'generate_sm2 → sm2_sign → sm2_verify', placing it definitively as the verification step.

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?

The description explains the two operating modes (RAW and DIGEST) and explicitly warns that sign_raw_data_mode must match the mode used during signing. It also notes that DIGEST mode is semantically consistent with KMS/ECC/RSA DIGEST mode, providing comparative guidance. The '完整流程' line gives a clear usage sequence, though it doesn't explicitly state when to avoid this tool in favor of alternatives.

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

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

With no annotations, the description carries the full behavioral burden. It states the failure result for wrong password or identity, imposes a ciphertext size bound, lists the successful outputs, and describes the cryptographic relationship between inputs. This goes well beyond a bare operation name, though it does not cover every edge case such as invalid ciphertext structure.

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?

The description is information-dense and front-loaded with the operation type, but it carries a redundant duplicate '[sm9_ibc] [sm9_ibc]' prefix and is a long single run-on sentence. It is concise overall, but the waste and lack of structure prevent a higher score.

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?

For a crypto tool with no output schema and no annotations, the description is quite complete: it covers inputs, expected key origin, consistency constraints, ciphertext size, outputs, and a known error string. The main gap is that the schema marks all parameters optional while the description implies all are needed, leaving required-ness ambiguous.

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 100%, so the baseline is 3. The description adds meaningful cross-parameter context: user_private_key_in_pem must be an SM9ExtractKey output, the password must match extraction, the identity must match encryption, and cipher_data_in_hex is DER ciphertext limited to 367 bytes. This adds semantics the schema does not express.

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 clearly identifies the operation as SM9 identity decryption, states the receiver role, and names all required inputs and outputs. The verb '解密' distinguishes it from sibling tools like sm9_encryption and sm9_sign.

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 gives explicit usage context: the receiver uses the KGC-issued user key, the key must come from SM9ExtractKey with key_kind=Enc, the password must match extraction, and the identity must match the encryption. It does not explicitly name when not to use it or enumerate alternatives, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden and does so well: it discloses that the operation is public-key encryption by anyone, binds the ciphertext to the identity, enforces a 1-255 byte plaintext limit due to KDF counter constraints, and specifies the output as DER-encoded C1/C3/C2 structure up to 367 bytes. This is rich behavioral context beyond a simple 'encrypt' statement.

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?

The description is compact and front-loaded with the key action and access model. However, it begins with a duplicated '[sm9_ibc] [sm9_ibc]' tag that adds noise and no informational value.

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?

For a non-destructive encryption tool with no output schema and no annotations, the description is remarkably complete: it covers all three parameters, their constraints, the output fields, the output encoding, and the output size limit. An agent has enough context to call it correctly without extra lookups.

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 100%, so the baseline is 3, but the description adds meaningful semantics: master_public_key_in_pem must be the Enc-kind public key, identity is tied to the ciphertext, and plain_data_in_hex has explicit size limits and KDF constraints. This goes beyond the schema descriptions without fully replacing them.

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 clearly identifies the operation as SM9 identity-based encryption ('SM9 标识加密') and states that anyone holding the master public key can encrypt, which distinguishes it from sibling operations like sm9_decryption, sm9_sign, and sm9_verify. It also specifies the required inputs and output format.

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?

The description gives clear usage context: encrypt for a specific identity using the Enc-type master public key. It does not explicitly name alternative tools or provide exclusion criteria, but the identity-based encryption workflow is sufficiently clear for an agent to select it.

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

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

With no annotations provided, the description carries full behavioral disclosure and does so thoroughly. It reveals that GmSSL encrypted PEM import has no password check, that wrong passwords may silently produce garbage keys, that a built-in N-1 probe performs a sign/encrypt round-trip verification (probe_verified=true) before output, and that a wrong password yields the error 'SM9 extract user key failed'. This is far beyond a typical description.

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?

The description is dense but front-loaded with purpose and standard, then lists inputs, then explains the verification probe and outputs. Every sentence adds non-redundant information. It is slightly marred by the duplicated '[sm9_ibc]' prefix, which is a minor formatting flaw, but overall it is efficiently structured.

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?

For a crypto key-extraction tool with no annotations and no output schema, the description is remarkably complete: it covers input semantics, the prerequisite relationship to GenerateSm9, the verification mechanism, the output (user_private_key_in_pem), and the failure mode. Nothing needed for a caller to use the tool 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 coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: master_private_key_in_pem must be GenerateSm9 output, private_key_password is reused to encrypt the extracted user key, and identity is the being-issued user's identifier bounded to 1-63 UTF-8 bytes. These extra details clarify parameter relationships that schema descriptions do not fully convey.

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 specifies a clear verb and resource: KGC extracts SM9 user private key by identifier (GM/T 0044). It differentiates from siblings by explicitly sourcing master_private_key_in_pem from GenerateSm9 output and by positioning the tool as the key-issuance step, distinct from sm9_sign/verify/encryption/decryption which consume the key.

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?

The description conveys clear usage context: it is the KGC-side step to derive a user key from an already-generated encrypted master key, with identity and key_kind as the distinguishing inputs. It implicitly distinguishes from generate_sm9 by naming the master key as a required input, though it does not explicitly state when not to use this tool or name alternatives.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It goes beyond the basic operation by revealing that SM3 digesting is performed internally, processing is streaming, only original-message mode is supported, and the output is a DER-encoded signature fixed at 104 bytes in hex or base64. This gives an agent meaningful operational expectations without an output schema.

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?

The description is compact and packs purpose, input semantics, processing behavior, and output format into a single dense paragraph. The duplicated '[sm9_ibc] [sm9_ibc]' prefix is unnecessary noise, but the content is otherwise efficiently organized with the standard first, then inputs, then behavior, then outputs.

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?

Given no annotations and no output schema, the description is reasonably complete: it states the purpose, required input source, processing mode, and output characteristics. Minor gaps include not explicitly mentioning that the private key password may be required for encrypted keys despite the schema marking it optional, and not covering error scenarios. Still, an agent has enough to select and invoke the tool correctly.

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?

Even though schema description coverage is 100%, the description adds important meaning: user_private_key_in_pem is specifically the output of SM9ExtractKey with key_kind=Sign, data_in_hex is the raw message (not a digest), and private_key_password is the user key passphrase. It also clarifies the output encoding and length, which the schema does not cover. This is a meaningful supplement to the schema fields.

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 verb and resource: SM9 identity-based signature (GM/T 0044), and clearly distinguishes this from sibling operations such as sm9_verify, sm9_encryption, and sm9_extract_key. It names the exact signer role and the KGC-issued user private key, so an agent can determine this tool is for signing, not verification or key extraction.

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?

The description specifies how to use the tool: provide the user private key in PEM from SM9ExtractKey with key_kind=Sign, the private key password, and raw message hex. It also includes an important exclusion: only raw message mode is supported, with SM3 digest computed internally, which prevents misuse with pre-hashed digests. It does not explicitly name alternatives like sm9_verify, but the context is clear enough.

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

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

With no annotations, the description carries the disclosure burden and does a strong job: it warns that verified=false is the normal response for a mismatching signature/identity, and that only malformed input raises the 'SM9 verify failed' error. This is genuinely useful, though the phrasing 'verified=false 是成功响应' is slightly ambiguous and it does not describe the full output shape.

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?

The description is dense and mostly front-loaded, with the operation stated first and input constraints following. The repeated '[sm9_ibc] [sm9_ibc]' prefix is redundant but does not meaningfully harm readability.

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?

Given no output schema and no annotations, it covers the essential call context: required inputs, exact signature length, success-vs-error behavior, and the error code string. It omits explicit mention of what verified=true indicates, but the agent can infer the boolean semantics from the verification context.

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?

The schema already describes all four parameters at 100% coverage, so the baseline is 3. The description adds high-value constraints not in the schema: master_public_key_in_pem must be the key_kind=Sign public key and signature_in_hex must be exactly 104 bytes (208 hex characters).

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 names a specific operation, 'SM9 标识验签（GM/T 0044）', and immediately scopes it by stating that verification only requires the master public key and signer identity. This makes it clearly distinct from sm9_sign and the other verify siblings even without explicitly naming them.

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 gives a clear usage context: use when verifying an SM9 identity signature with only the master public key and signer identity. It does not name alternatives or state when not to use it, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses output fields, key sizes, fixed nonce length, the 16-byte auth tag inclusion, and error behavior on tamper detection. However, it omits important crypto-behavioral guidance like nonce uniqueness requirements or explicit statement that ciphertext input for decryption includes the auth tag.

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?

The description is well-structured into [algorithm], [parameters], [output], and [notes] sections. Every sentence provides essential information—algorithm variants, key lengths, nonce format, output fields, and tamper-detection behavior—with no filler or redundancy.

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?

For a cryptographic tool with no output schema and no annotations, the description is quite complete: it covers input formats, output fields, authentication behavior, and error conditions. It falls short only in edge-case guidance (e.g., nonce uniqueness, exact handling of the auth tag during decryption), but overall it gives an agent enough context to invoke the tool correctly.

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 100%, so the baseline is 3, but the description adds extra meaning beyond the schema: it maps each algorithm to its required key byte length (AES256GCM=32B, ChaCha20Poly1305=32B, SM4GCM=16B), states the nonce is exactly 24 hex characters, constrains input size to 1B~16MB, and clarifies that associated data participates in MAC but is not encrypted.

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 clearly identifies this as a symmetric AEAD streaming encryption/decryption tool ('AEAD 流式加解密'), lists concrete algorithms (AES256GCM, ChaCha20Poly1305, SM4GCM), and distinguishes it from sibling tools like block_cipher and zuc_cipher by specifying the operation types (Encrypt/Decrypt) and algorithm families.

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?

The description implies usage through the '[symmetric_cipher]' label and the word 'AEAD', suggesting it is for authenticated streaming encryption, but it does not explicitly state when to choose this over alternatives such as block_cipher or zuc_cipher, nor does it provide exclusion criteria.

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

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

With no annotations provided, the description carries the full burden and does well by disclosing that encryption and decryption are identical operations, key and IV are fixed at 16 bytes, input length is 1B-16MB, and the return fields are output_data_in_hex and output_length. Missing details like output length equivalence or lack of authentication are left unstated, but the provided traits are valuable.

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?

The description is compact and information-dense, covering algorithm type, operational symmetry, key/IV sizes, data length bounds, and return fields in a few sentences. No redundant wording or filler; every part earns its place.

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?

Given the tool has no output schema, the description appropriately explains the return fields (output_data_in_hex, output_length) and states key length constraints. It does not provide an example or discuss error cases, but the core details are sufficient for a crypto utility with clear technical constraints.

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?

Although the schema already has 100% description coverage, the tool description clarifies a key ambiguity: the schema's key_in_hex description suggests variable lengths depending on algorithm (AES256=64, AES128/SM4=32), while the tool description fixes it to 16 bytes (32 hex chars) for ZUC-128. It also adds the input data length range and return fields, enhancing schema meaning.

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 explicitly states this is a ZUC-128 stream cipher, a specific Chinese commercial algorithm, and clarifies that encryption and decryption are the same operation. This clearly identifies the tool's function and distinguishes it from generic siblings like stream_cipher by naming the algorithm.

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?

The description provides clear context that this tool is for ZUC-128 symmetric stream cipher operations, implying when to use it. However, it does not explicitly discuss exclusions or alternative tools, such as when to prefer the generic stream_cipher or block_cipher, so it falls short of the highest guidance level.

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