Skip to main content
Glama

CipherHUB Cryptography Toolkit

by io.github.bowenerchen

ecc_key_exchange

[ecc] ECDH + HKDF 密钥协商，双方各用私钥+对方公钥派生相同对称密钥。 【参数】

  • alice_ecc_private_key_in_pem：己方私钥 PEM

  • bob_ecc_public_key_in_pem：对方公钥 PEM

  • hash_algorithm：HKDF 底层哈希（Sha256/Sha384/Sha512 等，不支持 Sm3）

  • salt：HKDF salt Hex（可选）

  • additional_info：HKDF info Hex（可选）

  • derived_key_length：派生密钥长度 16~1024 字节

  • alice_ecc_private_key_password：若私钥加密则传入 【输出】derived_key_in_hex、derived_key_length。 【曲线限制】Ed25519 不可用，X25519 可用。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
saltNoHKDF salt 的十六进制字符串（可选）e5af86e7a081e5ada6e4babae38090436970686572485542e38091
hash_algorithmNo哈希算法名称，可选值：Sha1 / Sha224 / Sha256 / Sha384 / Sha512（ECC 不支持 Sm3）Sha512
additional_infoNoHKDF info 的十六进制字符串（可选）536572696f75732043727970746f6772617068790a20202020437265617469766520536f6c7574696f6e730a202020204d617070696e67204469676974616c205472757374
derived_key_lengthNoHKDF/KDF 派生密钥长度（整数，16~1024 字节；KDF Pbkdf2Sm3 上限 256）
bob_ecc_public_key_in_pemNoBob 侧 ECC 公钥的 PEM 文本
alice_ecc_private_key_in_pemNoAlice 侧 ECC 私钥的 PEM 文本
alice_ecc_private_key_passwordNoAlice 侧 ECC 私钥的加密密码（原始字符串，非编码格式）

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / derived_key_length / description
      Previous value: -"HKDF 派生密钥长度（整数，16~1024 字节）"New value: +"HKDF/KDF 派生密钥长度（整数，16~1024 字节；KDF Pbkdf2Sm3 上限 256）"
  2. Changed8 schema fields changed
    • addedInput schema / properties / additional_info / description
      Added value: +"HKDF info 的十六进制字符串（可选）"
    • addedInput schema / properties / alice_ecc_private_key_in_pem / description
      Added value: +"Alice 侧 ECC 私钥的 PEM 文本"
    • addedInput schema / properties / alice_ecc_private_key_password / description
      Added value: +"Alice 侧 ECC 私钥的加密密码（原始字符串，非编码格式）"
    • addedInput schema / properties / bob_ecc_public_key_in_pem / description
      Added value: +"Bob 侧 ECC 公钥的 PEM 文本"
    • addedInput schema / properties / derived_key_length / description
      Added value: +"HKDF 派生密钥长度（整数，16~1024 字节）"
    • addedInput schema / properties / hash_algorithm / description
      Added value: +"哈希算法名称，可选值：Sha1 / Sha224 / Sha256 / Sha384 / Sha512（ECC 不支持 Sm3）"
    • addedInput schema / properties / hash_algorithm / enum
      Added value: +[
+  "Sha1",
+  "Sha224",
+  "Sha256",
+  "Sha384",
+  "Sha512"
+]
    • addedInput schema / properties / salt / description
      Added value: +"HKDF salt 的十六进制字符串（可选）"
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

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

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

Completeness4/5

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

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

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

Parameters3/5

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

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

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the operation: ECDH + HKDF key agreement using a private key and the counterpart's public key to derive the same symmetric key. This distinguishes it from sibling tools like hybrid_kex and key_derivation by naming the specific protocol and intended outcome.

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

Usage Guidelines4/5

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

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

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

All CipherHUB Cryptography Toolkit toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

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 Consistency3/5

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.

Tool Count2/5

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.

Completeness5/5

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.

Resources