Loading ToolBench
MCP server for Fully Homomorphic Encryption (FHE) field-level encryption operations supporting multiple schemes (TFHE, CKKS, BGV, BFV) with homomorphic computation, bootstrapping, and on-chain storage
This FHE Field Encryption server has significant definition quality gaps. While all 10 tools have names and descriptions, the descriptions are often too brief (many under 50 chars), parameter descriptions in the schema are minimal or absent, and output schemas are not documented. Most critically, several tools exhibit poor naming hygiene (verb_noun pattern is inconsistent), and the tool descriptions lack strategic context about WHEN to use each tool vs. similar alternatives. The code shows schema definitions via class-validator decorators but these are not fully visible in the provided source. No error handling patterns are documented, and parameters lack constraints (ranges, format specs) that would guide LLM usage. This is typical of community-built MCP servers that prioritize feature coverage over usability.
Decrypts multiple encrypted fields in a batch with optional parallel processing and error handling
Encrypts multiple fields in a batch with optional packed encryption and compression for efficiency
Creates a new homomorphic computation circuit with specified inputs, outputs, and logic gates
Decrypts a previously encrypted field using user's private key and returns plaintext value
Encrypts a field using FHE with specified scheme and security level, optionally storing encrypted data on-chain
Estimates the noise level of a ciphertext to determine if bootstrapping is required
Executes a previously created homomorphic circuit on encrypted inputs without decryption
Tool descriptions are too brief and lack strategic context. Most are 40-80 characters; they state WHAT but not WHEN to use or prerequisites. E.g., 'Encrypts a field using FHE...' does not explain when to call encryptField vs batchEncryption, or whether the user needs keys first.
Parameter descriptions are missing or generic. The schema shows properties like 'scheme', 'securityLevel', 'allowBootstrapping', but does not explain the tradeoffs, defaults, or implications. E.g., securityLevel enum values [128, 192, 256] are not explained, are these bits? What do they cost in performance?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 34 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Generates FHE key pairs (public, private, and evaluation keys) for a specified scheme and security level
Performs homomorphic operations (add, multiply, subtract, negate, rotate, bootstrap) on encrypted values without decryption
Re-encrypts an encrypted value under a new public key for key delegation or transfer scenarios
Output schemas are not documented. Tools return encrypted values, metadata, or circuit results, but the response structure is not specified. LLMs cannot plan downstream calls (e.g., what fields does encryptField return?) or extract needed data without seeing the schema.
Naming inconsistency: performHomomorphicOperation is wordy and unclear. Better names: 'compute_on_encrypted' or 'operate_encrypted'. Tool names should start with a clear action verb and be ≤25 chars for brevity.
No error handling guidance. If encryptField fails (e.g., noise overflow, key not found, invalid scheme), what should the LLM do? Can it retry? Should it call generateFheKeys first? Descriptions lack recovery hints.
Parameter constraints are implicit or missing. E.g., securityLevel is an enum [128, 192, 256], but descriptions do not explain the cost/benefit. rotationAmount for rotate op has no min/max. maxCircuitDepth is mentioned in constants (20) but not exposed as a tool parameter or validation constraint.
Batch tools (batchEncryption, batchDecryption) accept arbitrary arrays but do not document limits. Constants show MAX_BATCH_SIZE: 50, but tool descriptions do not mention this constraint, so LLMs may pass 1000 items and fail ungracefully.
Dependency chain is not documented. encryptField requires keys (generated by generateFheKeys), but the description does not say 'Call generateFheKeys first if you don't have keys.' This forces LLMs to infer the sequence.