[symmetric_cipher] PKCS7 填充/去填充工具。 【参数】
padding_action：DoPadding（填充到 16 字节对齐）或 UnPadding（去填充）
data_in_hex：待处理数据 Hex 【输出】output_data_in_hex、output_length。 【说明】块大小固定 16 字节（AES/SM4 块大小）。通常无需单独调用此工具，block_cipher 内部已自动处理填充。
| Name | Required | Description | Default |
|---|---|---|---|
| data_in_hex | Yes | 数据的十六进制字符串。RAW 模式为消息原文 Hex，DIGEST 模式为哈希摘要 Hex | |
| padding_action | No | 填充操作，可选值：DoPadding（填充到 16 字节对齐）/ UnPadding（去填充） | DoPadding |
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.
Add one secure layer between your agents and this server.
Most tools target a distinct algorithm+operation pair (e.g., rsa_sign vs sm2_sign vs ml_dsa_sign), and descriptions are detailed. However, block_cipher and stream_cipher both perform symmetric encryption, and ecc_key_exchange and hybrid_kex overlap as key exchange, requiring careful reading to distinguish.
Naming is inconsistent across algorithm families: key generation mixes generate_ecc/generate_rsa with ml_dsa_keygen/ml_kem_keygen, and encryption mixes rsa_encryption/sm2_encryption with block_cipher/stream_cipher. Within each family (e.g., rsa_sign/rsa_verify, ml_dsa_sign/ml_dsa_verify), names are predictable, but the overall pattern is not uniform.
32 tools is far above the typical 3-15 range for a well-scoped server. While every tool has a distinct function, the large surface makes the set heavy and harder to navigate, especially with multiple algorithm families and niche utilities.
The toolkit gives comprehensive coverage: key generation, encryption/decryption, signing/verification for RSA, ECC, SM2, ML-DSA, ML-KEM, plus symmetric ciphers, hashing, and key exchange. Full workflows are supported with no dead ends, and even helper tools for debugging are included.