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 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?

With no annotations, the description carries the full burden of disclosure. It is transparent about the algorithm (ECDH+HKDF), output fields (derived_key_in_hex and derived_key_length), and limitations (Ed25519 not usable, X25519 usable). It also notes optional salt/info and password handling. It does not discuss error cases, but for a crypto tool this level of transparency is solid.

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 clear breakdown of parameters, output, and limitations. It is slightly verbose but every section earns its place, and the front-loaded purpose statement makes it easy to scan. The use of bullet-like formatting enhances readability without unnecessary fluff.

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 complexity (7 parameters) and lack of an output schema, the description covers the essential aspects: algorithm, parameter purposes, output format, and curve restrictions. It falls short of explicitly marking required parameters and handling edge cases, but overall it is sufficiently complete for an 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 meaningful clarity beyond the schema by explaining roles (own private key vs. other's public key), the condition for the password, and the valid range for derived_key_length. It also explicitly calls out unsupported Sm3, which is useful. This additional context justifies the higher score.

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 purpose: ECDH + HKDF key negotiation, where both parties derive the same symmetric key using their own private key and the other's public key. This specific verb+resource combination distinguishes it from sibling tools like hybrid_kex and ecc_key_sign, making its function unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives clear context: both parties need their own private key and the other's public key, and the output is a derived symmetric key. It also provides exclusions such as Ed25519 not available and Sm3 not supported, plus a conditional for encrypted private keys. However, it does not explicitly mention alternatives like hybrid_kex, so it stops short of a perfect 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 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?

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 full transparency responsibility. It discloses supported algorithms, explicitly excludes SHAKE due to XOF nature, specifies key and plaintext length limits, output structure, and default behavior. However, it does not reconcile contradictions with the input schema (e.g., key_in_hex length references AES keys; required_hash_modes default includes Shake values), which slightly undermines 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 well-structured with sections for algorithms, parameters, output, and typical uses. It is succinct, front-loaded with the main purpose, and every sentence adds necessary detail 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 no output schema, the description thoroughly explains the return format (Results dictionary with hmac_sum_in_hex and hmac_length). It covers algorithm constraints, input limits, defaults, and use cases. Minor omissions include error handling and explicit clarification of schema conflicts, but the description is sufficiently complete for agent 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 coverage is 100%, but the schema descriptions are partly misleading (e.g., key_in_hex referencing AES key sizes, default array containing Shake128/256). The tool description corrects these by providing accurate constraints (16~256 bytes, 1B~16MB, default all 6 algorithms) and adds output semantics. It adds value beyond the schema, though it could more explicitly call out the schema discrepancies.

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 '计算 HMAC（基于哈希的消息认证码）' – a specific verb and resource that clearly defines the tool's function. It further enumerates supported algorithms and typical use cases, distinguishing it from sibling tools like hash_sum (plain hashing) and other cryptographic primitives.

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 contexts for use ('消息完整性验证、API 签名、密钥确认'), but it does not explicitly name alternatives or state when not to use the tool. The use cases are enough to guide an agent, yet the lack of explicit exclusions keeps it from a 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses the fallback to CSPRNG generation, the requirement that ML-KEM keys be provided together, and the HKDF derivation and output fields. It does not mention error behavior, but for a stateless demo this is reasonably transparent.

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 (参数, 流程, 输出, 安全等级) and front-loads the purpose. It is somewhat lengthy and repeats some schema details, but every section contributes useful context without being excessively verbose.

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 demo with 8 parameters and no output schema, the description explains the flow, key formats, output types (including keys_match), and security level. It could be more specific about the exact output structure and error cases, but it is largely sufficient for an agent to understand and invoke 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 description lists key parameters and adds useful constraints like '公钥和私钥必须同时提供' and random-generation fallback. However, most of this is duplicated in the schema's root description and property descriptions, and the description omits the X25519 public key fields entirely, so it adds only marginal 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 opens with a clear action: '执行 X25519 + ML-KEM-768 混合密钥交换全流程演示' and adds the X-Wing draft reference, making the tool's purpose unmistakable and distinguishing it from sibling tools like ml_kem_encap/ml_kem_decap and 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 provides context by explaining the full-process demo, optional key provisioning, and the exact flow and security level. However, it does not explicitly name alternatives or state when not to use this tool versus the separate ml_kem or ecc_key_exchange tools, so it misses 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?

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?

No annotations are provided, so the description carries the full burden. It discloses the ciphertext length requirement (key_size/8 bytes), the need for matching padding mode, and the output format. These add behavioral context beyond a simple 'decrypt' statement, though it does not discuss failure modes or side effects.

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 tightly structured with sections for purpose, parameters, and output. Every line contributes valuable information, and the most important fact (decryption) is front-loaded. No wasted words.

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 complexity of RSA decryption with multiple padding modes and optional password, the description covers the essential inputs, constraints, and output. It does not describe error handling or elaborate on key size, but for a decryption tool with no output schema, this is a solid, complete overview.

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. The description adds meaningful detail for each parameter: PEM format for the key, hex format and length constraint for cipher_data_in_hex, the requirement that padding mode match encryption, and the conditional use of password. This enhances 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 'RSA 私钥解密' (RSA private key decryption), clearly identifying the tool's operation on a specific resource. It distinguishes itself from sibling tools like rsa_encryption and rsa_sign/verify by specifying the decryption function and listing decryption-specific parameters.

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 key usage guidance: padding mode must match encryption, and password is needed if the private key is password-protected. However, it does not explicitly mention alternatives or when to use this tool versus other RSA operations, so it falls 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, the description discloses important behavioral traits: plaintext length limits depending on key size and padding mode, output field names (cipher_data_in_hex, cipher_length), and a security best practice. It doesn't cover error handling or key validation, but it provides meaningful constraints 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 labeled sections for parameters, length limits, output, and security advice. Every sentence carries necessary information 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?

Since there is no output schema, the description lists output fields and provides length constraints and security advice. It is largely complete for an encryption primitive, though it could mention potential errors or key validation steps.

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 all three parameters with descriptions, so the baseline is 3. The description restates parameter names and adds the length-limit context for plain_data_in_hex, but it does not significantly enrich meaning 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 'RSA 公钥加密' (RSA public key encryption), which is a specific verb+resource. It distinguishes from sibling tools like rsa_decryption, rsa_sign, and rsa_verify by explicitly indicating public-key encryption.

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 purpose line makes it clear this tool is for encryption, and the security recommendation to prefer OAEP over PKCS1v1.5 provides parameter-level guidance. It doesn't explicitly mention alternatives like rsa_decryption, but the context is unambiguous and no exclusions are stated.

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 reveals key behaviors: internal hashing based on rsa_sign_raw_data_mode, password handling, and output fields. It does not discuss error cases or side effects, but as a signing operation the essentials are 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-organized into sections for parameters, output, and security advice. It is dense but not padded, with each line contributing useful information. The parameter list duplicates schema content, but the structure aids 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?

For a 5-parameter tool with no output schema and no annotations, the description covers all parameters, lists output names, and adds a security guideline. It could specify signature_length units or error behaviors, but overall it gives sufficient context 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?

Schema description coverage is 100%, so the baseline is 3. The description restates parameter meanings with minor shorthand (e.g., padding enum list) but adds little semantic value beyond the schema's own 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 the tool performs RSA private key signing ('RSA 私钥签名'), specifying the verb and resource. It is unambiguous and distinct from verification or other signing schemes, though it does not explicitly compare against siblings like rsa_verify or 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?

Provides a security recommendation to prefer PSS over PKCS1v1.5 and explains raw data mode, which guides usage. However, it lacks explicit guidance on when to use rsa_sign instead of other signing tools (e.g., ecc_key_sign, sm2_sign), relying mostly on the tool name for differentiation.

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 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.