CipherHUB Cryptography Toolkit

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

The description discloses automatic PKCS7 padding for encryption and removal for decryption, and notes that decryption requires ciphertext length to be a multiple of 16 bytes. Output fields are listed. No annotations are provided, so the description carries the full burden; it covers key behaviors but could mention error handling or IV requirements.

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 algorithm list, parameters, automatic behavior, output, and a note. It is front-loaded with the main purpose. While efficient, a few lines could be combined without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and moderate complexity (5 parameters, multiple algorithms, padding behavior), the description covers all critical aspects: algorithms, parameter constraints, padding, output fields, and a length constraint. It is missing example usage or error handling, but overall very 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 0%, but the description fully explains each parameter: algorithm name, process type, input data in hex, key in hex, and IV in hex. It specifies hex format, key sizes, and that IV is fixed at 16 bytes. This compensates entirely for the lack of 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 starts with '[symmetric_cipher] 分组密码 CBC 模式加解密' which clearly states it is a symmetric block cipher for CBC mode encryption and decryption. It lists specific algorithms (AES128, AES256, SM4) and key sizes, making it distinct from sibling tools like stream_cipher and zuc_cipher.

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 what the tool does and its parameters but does not explicitly state when to use it versus alternative sibling tools. Usage context is implied by the algorithm and mode description, but no guidance is given on when to choose one algorithm over another or when not to use 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 exist, so description fully shoulders behavioral disclosure. It reveals block size (16 bytes for AES/SM4), output fields (output_data_in_hex, output_length), and the action choices. However, it does not mention potential edge cases (e.g., input size limits) or reversibility, but for a simple padding tool, this is largely 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?

Description is concise (three lines) and well-structured: first line states purpose and category, then lists parameters and outputs. Every sentence adds value 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?

For a straightforward padding tool with no output schema, the description covers input parameters, output fields, block size, and relationship to sibling tool block_cipher. No gaps remain for typical usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description provides clear meanings for both parameters: `padding_action` (DoPadding/UnPadding) and `input_data_in_hex` (data in hex). It also maps `padding_action` values to their functions, adding essential context absent from 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 is for PKCS7 padding/unpadding in symmetric ciphers, with specific verb-resource ('填充/去填充工具'). It distinguishes from sibling tool block_cipher by noting that padding is usually handled internally, making 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?

Explicitly states '通常无需单独调用此工具，block_cipher 内部已自动处理填充' (usually no need to call separately; block_cipher handles it internally), providing clear when-to-use and when-not-to-use. The alternative block_cipher is identified, giving strong 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?

No annotations are provided, so the description carries full burden. It mentions optional private key password and output details, but does not disclose read/destructive nature, rate limits, or other behavioral traits beyond what is implied by a key agreement operation.

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 a single short paragraph followed by a bullet list of parameters and output, all front-loaded with the purpose. Every sentence adds value with no repetition or 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 7 parameters and no output schema, the description fully covers the purpose, parameter meanings, output format, and curve restrictions. There are no missing pieces 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?

Schema coverage is 0%, but the description explains each parameter: private key, public key, hash algorithm (with examples and unsupported Sm3), salt, info, derived key length range, and encrypted key password. This adds significant meaning beyond the schema titles and defaults.

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 ECDH + HKDF key agreement to derive a symmetric key using two parties' keys. It distinguishes from sibling tools like ecc_key_sign or rsa_encryption by specifying the key exchange nature.

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 process and mentions curve restrictions (Ed25519 unavailable, X25519 available). However, it does not provide explicit when-to-use or alternatives compared to other key exchange tools like hybrid_kex.

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

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

No annotations are provided, so the description carries full weight. It explains that sign_raw_data_mode controls whether the input is hashed internally, and that hash_algorithm is ignored for EdDSA. It also lists output fields and a curve restriction. However, it does not disclose authentication requirements or potential 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 well-structured with sections for parameters and output, but it is somewhat verbose with markdown formatting. It front-loads key information (algorithm distinction) and is organized, though each sentence 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?

With 5 parameters and no output schema or annotations, the description adequately covers inputs and outputs (signature_in_hex, signature_length, curve_name). It also notes curve restrictions. It is complete for a cryptographic signing tool, though it could mention if the operation is reversible or not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no descriptions), but the description adds detailed explanations for each parameter: ecc_private_key_in_pem, plain_data_in_hex (though schema uses data_in_hex), sign_raw_data_mode, hash_algorithm, and ecc_private_key_password. It clarifies behavior for each, significantly adding 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 performs ECC private key signing (ECDSA for SECP*, EdDSA for ED25519). The name itself is self-explanatory, and the description distinguishes it from siblings like ecc_key_verify (verification) and other signing tools such as rsa_sign 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?

The description mentions a curve restriction (X25519 not for signing) but does not provide explicit guidance on when to use this tool versus alternatives like rsa_sign or sm2_sign. The usage context is implied but lacks when-not-to-use or comparison with 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, description carries full burden. It details input constraints, output (verified bool, curve_name), and a critical curve restriction (X25519 forbidden). It does not cover error states or edge cases, but is otherwise 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?

Structured with sections for parameters, output, and restrictions, but somewhat verbose in listing parameters. Could be more concise without losing clarity.

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, description sufficiently explains return values (verified bool, curve_name) and a key restriction. Misses details on error handling or behavior for invalid signatures, but overall complete for the tool's simplicity.

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 has 0% description coverage, so description provides essential meaning for all 5 parameters, including the need for consistency with signing. However, there is a naming discrepancy: 'plain_data_in_hex' in description vs 'data_in_hex' in schema, which may 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?

Description clearly states it's for ECC signature verification, specifies algorithms per curve (SECP* uses ECDSA, ED25519 uses EdDSA), and distinguishes from signing (ecc_key_sign) and exchange (ecc_key_exchange) siblings.

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?

Description notes that hash_algorithm and sign_raw_data_mode must match the signing instance and that X25519 is ineligible. However, it lacks explicit comparison to other verification tools (e.g., rsa_verify, sm2_verify) or when to choose this over 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?

Describes optional password for PEM encryption and output fields. No annotations provided, so description carries full burden; it covers key generation behavior adequately without contradictions.

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?

Well-structured with sections for purpose, curves, parameters, output, and capabilities. Slightly verbose in the curve list but overall concise and informative.

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?

Lists output fields and curve capabilities, compensating for lack of output schema. Missing password length constraints or examples, but sufficient for typical use.

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?

Adds significant meaning beyond the input schema: explains curve default, enumerates possible values, and clarifies private_key_password usage for encryption. Schema coverage was 0%, so description fully compensates.

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?

Clearly states it generates ECC key pairs and lists supported curves, distinguishing it from siblings like generate_rsa and generate_sm2.

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

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

Provides a capability matrix for curves (signing vs ECDH), helping select the right curve. No explicit when-not-to-use or comparison with non-ECC siblings, but implicit from tool names.

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 provided, so the description carries full burden. It discloses the source (CSPRNG), security, input range (1-128), and return fields. Could mention non-determinism but otherwise adequate.

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?

Extremely concise, three sentences with no fluff. Front-loaded tag and clear structure. Every sentence 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 tool with one parameter and no output schema, the description fully explains input constraints and output format. Nothing missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, so the description must compensate. It adds meaning by specifying byte count range (1-128) and explains return encoding (hex), which the schema omits.

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, specifies the parameter and return format, and distinguishes itself from sibling tools like encryption or signing with the [random] tag.

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 does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to use hash_sum for deterministic output). Usage is implied but not comparative.

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 that the tool generates RSA keys, outputs PEM format, and optionally encrypts the private key with AES-256-CBC. It does not contradict annotations. The behavioral traits are 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 concise and well-structured, with clear sections for parameters, output, and subsequent operations. Every sentence adds value 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?

No output schema exists, so the description compensates by listing output fields (public_key_in_pem, private_key_in_pem, key_size). It also links to related tools for further operations. The description is complete for a key generation 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 has 0% description coverage, so the description adds critical meaning. It explicitly lists allowed key sizes (2048, 3072, 4096 bits) and explains that the private_key_password is optional and uses AES-256-CBC encryption. This is far beyond what the schema 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 generates RSA key pairs, specifies the resource (RSA), and the verb (generate). It distinguishes from sibling tools like generate_ecc and generate_sm2 by explicitly mentioning 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 mentions subsequent operations (e.g., rsa_encryption, rsa_sign) but does not provide explicit guidance on when to use this tool versus alternatives like generate_ecc or generate_sm2. Usage context is implied but not explicitly 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 provided, the description fully carries the burden. It explains the optional password for PEM encryption, lists all outputs, and indicates subsequent usage. However, it does not mention side effects or auth requirements, but for key generation these are minimal.

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 concise, using bullet points to list parameters, outputs, and subsequent steps. Every sentence adds value, and the key 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?

Despite no output schema, the description lists all six output fields. With only one optional parameter and straightforward generation logic, the description is complete and provides context for subsequent cryptographic operations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must add meaning. It explains the single parameter 'private_key_password' as optional for PEM encryption, which the schema lacks. This fully compensates for the low 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 generates an SM2 key pair, specifying the curve (SM2P256V1). It differentiates from siblings like generate_ecc and generate_rsa by naming the specific 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 lists subsequent operations for public and private keys, implying use cases, but does not explicitly state when to use this tool versus alternatives like generate_ecc or 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, the description carries full burden. It discloses input size limits, output format (dictionary with hex and length), and special SHAKE behavior. It does not mention error handling or safety, but for a read-only hash tool, this is adequate.

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 supported algorithms, parameters, output, and SHAKE note. It is concise yet comprehensive, with 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 tool's simplicity (3 optional parameters, no output schema), the description covers input constraints, algorithm list, output format, and special SHAKE behavior. 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 description coverage is 0%, so the description must compensate. It explains plain_in_hex as hex string, required_hash_modes as array with default all algorithms, and shake_output_length with explicit constraints. It adds significant 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 the tool computes message digests (hash), supports multiple algorithms, and batch calculation. It distinguishes itself from sibling tools like hmac_sum and block_cipher by focusing on pure hashing.

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 hashing with multiple algorithms but does not explicitly state when to use over alternatives like hmac_sum or when not to use. No exclusions are provided.

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 describes the echo behavior and return fields, which is sufficient for a simple health check. No side effects or destructive actions are implied, and nothing contradicts annotations.

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 sentences long, front-loads the purpose, and contains no extraneous information. Every sentence is necessary and to the point.

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 health-check tool, the description covers the main behavior and return fields adequately. It lacks error conditions or limits, but those are minor for this use case. Given no output schema, return fields are specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should compensate. However, it only restates 'client_msg string' without adding any constraints, examples, or additional semantics 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 it is a health check/echo tool, specifies the exact behavior (echo client_msg and attach server_msg), and distinguishes itself from sibling cryptographic 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 explicitly states the purpose is to verify MCP channel connectivity, which provides clear usage context. However, it does not mention when not to use it or provide alternatives, though siblings are all crypto tools making misuse unlikely.

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?

The description discloses some behavioral traits like supported algorithms and output format, but there is a major contradiction with the input schema: the description states SHAKE is not supported, yet the schema default for 'required_hash_modes' includes Shake128 and Shake256. This inconsistency would mislead an agent. Annotations are absent, so the description carries full burden but fails to be accurate.

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 front-loaded with purpose. While slightly verbose, every sentence 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?

Given no output schema and no annotations, the description covers many aspects like input constraints, output, and typical uses. However, the inconsistency regarding supported algorithms and the parameter mismatch leaves gaps that undermine completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning for key_in_hex and plain_in_hex by specifying length constraints, but it misnames the third parameter (hmac_mode vs required_hash_modes) and contradicts the schema's default values. With 0% schema description coverage, the description partially compensates but is inaccurate.

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 computes HMAC with a list of supported algorithms, and provides typical use cases such as message integrity verification and API signing. It distinguishes itself from sibling tools like hash_sum by specifying it uses a key.

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

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

The description lists typical uses that imply when to use this tool, such as message integrity verification and API signing. However, it does not explicitly state when not to use it or contrast with alternatives like hash_sum.

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?

Explains the entire process: random generation for missing keys, HKDF derivation, output includes keys_match boolean and final key. Security level mentioned. No annotations provided, so description carries full weight.

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?

Well-structured with sections (standard reference, parameters, flow, output, security level). Slightly lengthy but all information 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?

Covers all aspects: purpose, parameters, flow, output description, security level. Without output schema, description adequately describes return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description adds comprehensive details: key formats (PEM, raw, SPKI DER, PKCS#8 DER), requirement to provide ML-KEM keypair together, and optional generation. Adds significant meaning beyond schema 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?

Clearly states it performs X25519 + ML-KEM-768 hybrid key exchange. Distinguishes from siblings like ml_kem_encap/decap and ecc_key_exchange by being a hybrid combination.

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?

Describes the full flow and parameter options. Does not explicitly state when not to use or list alternatives, but context is clear for hybrid key exchange.

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 provided, so description carries full burden. It explains the computation steps and output fields, but does not explicitly state side-effect-free nature or permission needs. Since it's a pure computation, transparency is adequate.

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?

Well-structured with bullet points, clear sections for purpose, formula, parameters, and output. Every sentence provides essential information, no redundancy. Front-loaded with key purpose and usage.

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?

Complex tool with 4 parameters and no output schema. Description covers computation formula, parameter constraints, and output fields. Lacks error handling details but sufficient for expected usage. Could be more comprehensive on edge cases.

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 has 0% coverage, but description fully compensates: specifies format (hex), constraints (max 2048 bytes, max 255 bytes), validation (OID/length check for public key), and default algorithm. Adds significant meaning beyond 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?

Explicitly states it computes the 64-byte mu value for ML-DSA, referencing FIPS 204 Section 6.2. Differentiates from sibling tools like ml_dsa_sign by specifying it's for EXTERNAL_MU mode verification or debugging, clearly identifying the unique 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?

Provides clear usage context: for verification/debugging of EXTERNAL_MU mode or AWS KMS integration. While it doesn't explicitly mention when not to use, the specialized purpose implies alternatives (normal signing via ml_dsa_sign). Good but could be more precise about 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 provided, but the description discloses output fields (public/private key formats, algorithm, security level, byte sizes) and the standard reference. It does not mention side effects or permissions, but the detail on outputs 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?

Description is front-loaded with purpose and structured in clear sections. While somewhat verbose, each part adds value. Could be slightly tighter but overall well-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?

Given one optional parameter and no output schema, the description is thorough: covers algorithm selection, security level reference, output formats, and typical usage. Fully sufficient for an agent to invoke 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?

Only one parameter 'algorithm' with no schema description. The description explains the three algorithm options and their NIST security levels, adding significant meaning beyond the schema's default 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?

Description clearly states the tool generates ML-DSA key pairs per FIPS 204, with specific verb and resource. It distinguishes from sibling tools like ml_dsa_sign and ml_dsa_verify by focusing on 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?

Description mentions typical use case (private key for signing, public key for verification) but does not explicitly state when not to use or compare to other key generation tools (e.g., generate_rsa, ml_kem_keygen).

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 provided, but description fully compensates by detailing signing modes, message length constraints, required keys per mode, and output fields. No contradictions.

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?

Well-structured with sections and bullet points, but slightly verbose. Key information is front-loaded. Efficient for a complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters, no output schema, and no annotations, the description is highly complete. Covers all parameters, modes, constraints, and output fields. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% but description thoroughly explains each parameter: role, format, defaults, and conditionality (e.g., public_key_spki_in_hex required for EXTERNAL_MU). Adds significant meaning beyond 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?

Clearly states it signs a message using ML-DSA private key (FIPS 204). Distinguishes from sibling tools like ml_dsa_keygen and ml_dsa_verify by specifying signing action.

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 detailed guidance on when to use RAW vs EXTERNAL_MU modes based on message length. Mentions equivalence with AWS KMS. However, does not explicitly guide choosing between this and other sign tools (ecc_key_sign, rsa_sign).

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 behavioral traits: dual modes, max message sizes, empty message validity, context consistency, output fields, and algorithm options.

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, but could be slightly more concise without losing essential 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 moderate complexity, no output schema, and no annotations, the description covers all necessary details: parameters, modes, constraints, and output, making it 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 0%, but the description explains all 6 parameters in detail, including accepted formats, constraints, and defaults, fully compensating for the schema gap.

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 verifies signatures using ML-DSA public key, distinguishing it from signing tools and other verify tools by specifying the algorithm and dual modes.

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 explicit guidance on when to use RAW vs EXTERNAL_MU modes and algorithm selection, but lacks explicit exclusion of alternatives or when not to use 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?

With no annotations, the description fully discloses behavioral traits: it explains ML-KEM Implicit Rejection (no exception on tampered ciphertext, returns deterministic pseudorandom value, IND-CCA2 security). This goes beyond basic 'decapsulate' and is critical for security-aware usage.

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 (algorithm, parameters, output, security, complete flow). It is slightly verbose but each section adds value. Could be tightened, but overall effective.

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 a post-quantum KEM, no output schema, and no annotations, the description covers all necessary aspects: input sources, output fields, security properties, and integration with sibling tools. It provides a complete picture.

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 has 0% description coverage and only defaults. The description remedies this by explaining that algorithm must match keygen/encap, and the hex inputs are outputs from those steps. It adds essential context missing from 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 performs 'key decapsulation' using ML-KEM private key (FIPS 203), and it is categorized under [pqc_kem]. It distinguishes itself from sibling tools like ml_kem_encap and ml_kem_keygen by defining its role in the complete flow.

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

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

The description specifies that inputs must come from specific prior steps (keygen, encap) and that the algorithm must be consistent. It implies when to use (after encap) but does not explicitly state when not to use or alternatives, though siblings provide context.

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, but description details randomization, output formats, shared secret size, and algorithm naming. Lacks error conditions and side effects, but sufficient for a stateless crypto operation.

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?

Well-structured with Chinese headers, front-loaded purpose. Concise but includes all key points. Some redundancy in output listing.

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?

Covers inputs, outputs, randomization, and usage flow. Lacks error handling and input validation specifics. For a two-param tool with defined outputs, fairly 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 has 0% description coverage. Description adds meaning: algorithm must be consistent with keygen, public_key_in_hex from keygen output, and algorithm names (ML-KEM-512/768/1024). However, no exact allowed values or format details for public_key_in_hex.

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?

Clearly states it performs key encapsulation using ML-KEM public key (FIPS 203). Specifies algorithm variants and distinguishes from sibling tools like ml_kem_keygen and ml_kem_decap.

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 context: algorithm must match keygen, public_key_in_hex from ml_kem_keygen, randomization property, and output usage. Could explicitly state prerequisites, but flow is implied.

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 full burden. It discloses the deterministic vs random seed behavior and lists all output fields. However, it does not mention any side effects (e.g., whether generation is stateless), authentication needs, or potential errors (e.g., invalid algorithm). This is sufficient for a simple key generation tool but leaves minor gaps.

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?

Description is structured with clear sections for algorithm selection, parameters, output, and subsequent operations. It is front-loaded with the main purpose. Every sentence adds value, though the Chinese formatting could be slightly optimized for machine parsing.

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 (3 parameters, no output schema), the description covers purpose, parameter details, output fields, and usage sequence. It is complete enough for an agent to correctly invoke the tool and understand the subsequent steps (encap/decap).

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 has 3 parameters with no descriptions (0% coverage), so the description must compensate. It adds meaning: 'algorithm' is the algorithm name with options listed, 'seed_in_hex' is 64-byte hex (128 chars), 'use_random_seed' overrides the seed. This clarifies the purpose beyond the raw schema defaults.

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 generates ML-KEM key pairs per FIPS 203, enumerates the three algorithm variants (512/768/1024), and distinguishes from sibling tools (ml_kem_encap, ml_kem_decap) by specifying the output usage. The verb '生成' (generate) and resource '密钥对' (key pair) are specific and 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 recommends ML-KEM-768 as preferred and notes the public key is for ml_kem_encap and private key for ml_kem_decap, guiding the agent on subsequent tool use. It lacks explicit 'when not to use' but the context and alternative tools (e.g., hybrid_kex) are implied by the sibling list.

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 provided, so description carries full burden. It explains the decryption process and parameter requirements, but does not mention error handling 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?

Description is structured with bullet points and front-loaded with purpose. No wasted words, though slightly verbose for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, description includes output fields (plain_data_in_hex, plain_length). Covers inputs and outputs adequately for a decryption 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?

Schema coverage is 0%, so description compensates by explaining each parameter: private key (PEM), ciphertext (hex), padding mode, and optional password. Adds meaning beyond 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 private key decryption' with a specific verb 'decrypt' and resource 'private key'. It distinguishes from siblings like rsa_encryption, rsa_sign, etc.

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 when decrypting RSA-encrypted data, noting that padding mode must match encryption, but lacks explicit when-not or alternative 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?

No annotations provided, so description carries full burden. It discloses plaintext length constraints, padding modes, and a security recommendation (prefer OAEP). However, it does not cover error behavior, authentication requirements, or side effects beyond encryption.

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?

Description is well-structured with clear sections (purpose, parameters, constraints, output, security advice). Every sentence adds value; no redundancy or 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 no output schema, description provides output fields (cipher_data_in_hex, cipher_length) and constraints (key size, padding). It covers the essential info for a security-critical 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?

Schema has 0% description coverage, but description fully explains all three parameters: rsa_public_key_in_pem (PEM format), plain_data_in_hex (hex plaintext), and rsa_padding_mode (enum values listed). This adds critical 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?

Description clearly states it performs RSA public key encryption (RSA 公钥加密). It lists specific inputs and outputs, distinguishing it from siblings like rsa_decryption. The verb and resource are 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?

No explicit guidance on when to use this tool versus alternatives (e.g., sm2_encryption, stream_cipher). The description implies use for RSA encryption but does not mention prerequisites, exclusions, or contextual trade-offs.

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?

Discloses key behaviors such as raw data mode (whether data is pre-hashed), password support, and output format. Without annotations, the description carries the full burden and does so well, though it could mention destructive potential (none) or rate limits.

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?

Structured with clear sections for parameters, output, and safety advice. Slightly verbose but every sentence adds value. Could be more concise by removing redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description explains all input parameters, the output format (signature_in_hex, signature_length), and provides security recommendations. Complete enough for an agent to use 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?

Input schema has 0% coverage beyond titles; the description adds essential meaning for each parameter, including the meaning of rsa_sign_raw_data_mode, padding mode options, and password usage. This significantly aids 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?

Clearly states it is for RSA private key signing, lists parameters and output. Distinguishes from sibling tools like rsa_verify and ecc_key_sign by specifying RSA and signing.

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 detailed parameter explanations and a security recommendation to use PSS over PKCS1v1.5. However, does not explicitly state when to use this tool versus alternatives like ecc_key_sign or ml_dsa_sign.

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 provided. Description implicitly indicates read-only operation by returning a boolean; no mention of side effects. Clear enough for this tool type.

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?

Concise with bullet-like listing. A bit redundant for the two 'must match' notes, but overall efficient for 5 parameters and output.

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?

Covers purpose, all parameters, key usage requirement (modes must match), and output type. No output schema, so output description is sufficient.

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 has 0% description coverage, but description lists each parameter with its meaning (e.g., PEM format, hex data, output boolean). Adds significant value beyond 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 'RSA public key signature verification' and specifies parameters and output. Distinct from siblings like rsa_sign and other verification 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?

No explicit guidance on when to use this tool versus alternatives among many sibling tools. Mentions that padding and raw data modes must match signing, but does not compare to other verification methods.

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 explains the decryption process, required input formats, and output fields. It notes a critical failure condition (cipher_format mismatch). However, it does not discuss potential errors, idempotency, or whether the operation is read-only.

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 concise and well-organized with labeled sections for parameters, output, and a note. Every sentence provides necessary information without 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 the lack of annotations and output schema, the description covers the essentials: parameter details, output, and a key constraint. It is complete enough for an agent to use the tool correctly in most cases.

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 has 0% description coverage, so the description must compensate. It explains each parameter's format and constraints (e.g., PEM for key, hex for ciphertext, specific cipher_format values, optional password). This adds significant 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 clearly states it performs SM2 private key decryption, which is distinct from related tools like 'sm2_encryption' on the same server. The verb '解密' (decrypt) and resource 'SM2 私钥' are specific and 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 does not explicitly compare to alternatives or state when to use this tool vs. other crypto tools. However, the name and context imply its use case. A brief mention of related tools (e.g., 'sm2_encryption') would improve 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 full transparency burden. It discloses a critical behavior: each encryption produces a different ciphertext because of random k. It also details all four output formats. It does not mention error conditions or permissions, but for a public-key encryption tool, this is acceptable.

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 concise and well-structured, covering purpose, parameters, output details, and a behavioral note in a few sentences. Every sentence adds value, and the structure is easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking annotations and an output schema, the description thoroughly explains the input, output (four encoding formats), and a key behavioral trait. It is nearly complete, though it could benefit from mentioning error handling or key validation prerequisites.

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 has 0% description coverage, but the tool description compensates by clearly explaining both parameters: sm2_public_key_in_pem expects a PEM-format public key, and plain_data_in_hex expects hex-encoded plaintext. This adds significant meaning beyond the bare 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 this tool performs SM2 public key encryption, specifying the resource ('SM2 公钥加密') and the two input parameters. It is distinct from sibling tools like sm2_decryption, sm2_sign, etc., so an agent can clearly identify its 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 provides key usage context: it recommends the ASN1 DER format (C1C3C2_ASN1) and advises that ciphertext varies due to random k. However, it does not explicitly contrast with alternatives like rsa_encryption or specify when to prefer this tool over others. The context from sibling names partially compensates.

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?

Explicitly states it does not extract private key value ('不会解出私钥值'), indicating non-destructive read-only behavior. No annotations provided, so description carries the burden and does well.

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 sentences, no fluff. First sentence states action and output format; second sentence covers purpose, safety guarantee, and return field example.

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 one parameter and no output schema, description covers input format, output nature, purpose, and a key behavioral guarantee. Missing exact ASN.1 structure details but acceptable for a debug 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?

Single parameter 'private_key_in_pem' has no schema description (0% coverage). Description clarifies it expects SM2 encrypted private key in PEM format, adding critical 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?

Description clearly states it parses SM2 encrypted private key PEM structure and returns ASN.1 internal fields as JSON. Purpose is specific and distinct from sibling tools like sm2_decryption or sm2_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?

Implied usage for debugging and teaching, but no explicit when-to-use or when-not-to-use guidance. No alternatives mentioned despite sibling tools existing.

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 output format and field name but does not discuss error handling or edge cases (e.g., invalid PEM). This is adequate for a simple conversion tool but lacks full 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 extremely concise: one short sentence plus a note on the return field. It is front-loaded with the key operation and efficient with no superfluous 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 no output schema, the description compensates by specifying the return field name and format. It covers the core functionality well, though it could add more context about error conditions or input validation for full completeness.

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?

With 0% schema description coverage, the description should compensate. It implies the parameter is the PEM key but does not specify its format, constraints, or what happens with an empty default. This omission limits the agent's ability to use the tool correctly.

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 to hex encoding (uncompressed point format). It specifies the exact operation and the output format, distinguishing it from other cryptographic tools in the same server.

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 does not provide explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of prerequisites or scenarios where this tool is appropriate, leaving the agent to infer usage from context.

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 burden. It discloses internal behavior (SM3 digest, ZA concatenation) and output formats, but lacks details on side effects, permissions, or error conditions. For a signing tool, this is adequate but not exhaustive.

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 fairly detailed but structured: purpose, parameter list, output description. It front-loads the main purpose. A bit lengthy but each part serves a purpose, though minor trimming could improve readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations or output schema, the description adequately covers input parameters and output format, including a recommendation for verification. It addresses the complexity of SM2 signing with internal digest 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?

Schema coverage is 0%, yet the description explains each parameter's meaning and purpose: sm2_private_key_in_pem, plain_data_in_hex (note: schema uses data_in_hex), sign_raw_data_mode, and sm2_private_key_password. It also describes the output dictionary structure, adding significant value beyond the bare 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 performs SM2 private key signing with built-in SM3 digest and ZA concatenation. It uses a specific verb 'sign' and identifies the resource 'SM2 private key', differentiating it from siblings like sm2_verify or ecc_key_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 explains when to use the tool: for signing data with an SM2 private key. It clarifies the role of 'sign_raw_data_mode' for raw data vs. pre-digested data. While it does not explicitly list when not to use it, the context is clear enough for typical signing scenarios.

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 explains that the tool verifies a signature, outputs a boolean, and notes format constraints (RS_ASN1 fixed, raw data mode must match). No destructive behavior is implied, and the behavior is clear for a read-only verification tool.

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, parameters, output, and full flow. It is concise, using bullet-like formatting, though the parameter mismatch adds minor clutter.

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 SM2 verification and the lack of an output schema, the description adequately explains the output (boolean) and provides the recommended flow. However, it does not cover edge cases, error handling, or parameter validation details, leaving some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must add value. It lists the key parameters and explains their purpose (e.g., PEM public key, hex data, hex signature, fixed format, raw data mode). However, there is a naming discrepancy: the description refers to 'plain_data_in_hex' while the schema uses '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 clearly states 'SM2 公钥验签' (SM2 public key signature verification), specifying the verb (verify) and resource (SM2 public key). It distinguishes from sibling tools like sm2_sign and ecc_key_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?

The description provides explicit usage context, including the complete flow 'generate_sm2 → sm2_sign → sm2_verify' and notes that parameters must match those used during signing. It does not explicitly state when not to use or compare to alternatives, but the guidance is sufficient.

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

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

No annotations exist, so the description must disclose behavioral traits. It mentions that encryption output includes a 16-byte auth tag and that decryption fails on tamper detection. However, it lacks details on streaming behavior, performance implications, or statefulness, which are relevant for a streaming cipher.

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 (algorithm, parameters, output, note). It is front-loaded with purpose and algorithm list. While thorough, it uses a bullet-like format that is efficient. Minor redundancy in parameter duplication could be trimmed.

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 input parameters, output fields (output_data_in_hex, output_length, output_sha256, algorithm), and important notes (auth tag, error on tamper). Given no output schema, this is fairly complete, though it omits details on whether streaming implies chunked processing or memory usage.

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?

With 0% schema coverage, the description provides all parameter meanings, formats (Hex), constraints (nonce fixed 12 bytes, input size 1B-16MB), and optionality (associated_data). This fully compensates for the schema's lack of documentation.

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 identifies the tool as a symmetric cipher for AEAD streaming encryption/decryption, listing supported algorithms and parameters. It clearly distinguishes itself from sibling tools like block_cipher by emphasizing 'streaming' and 'AEAD' properties.

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 guidance on when to use versus alternatives (e.g., block_cipher vs stream_cipher). The description does not specify when-not to use or provide comparative context, leaving the agent to infer usage from the tool's name and description alone.

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 provided. The description discloses the stream cipher property (encryption=decryption), key/IV length constraints, data size limits, and return fields. It does not mention authentication, rate limits, or error handling, but covers essential behavioral characteristics for a crypto tool.

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?

Three sentences in Chinese, front-loaded with algorithm type. Efficiently covers purpose, constraints, and return fields. Could be slightly more concise, but no unnecessary 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 no output schema, the description adequately covers key details: algorithm type, operation equivalence, fixed key/IV lengths, data size bounds, and output fields. Lacks explanation of padding or error states, but complete for a specific cipher 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?

Schema has 0% description coverage. The description adds critical meaning: key_in_hex and iv_in_hex must be 32 hex characters (16 bytes), input_data_in_hex length 1B-16MB. This compensates for the bare schema, providing necessary constraints beyond field names.

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 implements ZUC-128 symmetric cipher, explains encryption/decryption equivalence (stream cipher), specifies key/IV sizes (16 bytes each), data length range (1B-16MB), and return fields. This distinguishes it from siblings like block_cipher and stream_cipher.

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 it is a Chinese commercial algorithm, implying use for Chinese standards, but it does not explicitly state when to use this tool vs alternatives like stream_cipher or block_cipher. No when-not-to or exclusionary guidance is provided.

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