Loading ToolBench
An MCP server for RISC Zero zkVM proof generation and verification, enabling zero-knowledge computations through MCP tools
This MCP server provides 18 RISC Zero zkVM tools with consistent schema structure but significant quality gaps. All tools have descriptions and input schemas present, but descriptions are often generic and lack depth required for LLM tool selection. Parameter descriptions are sparse or missing entirely for several critical fields. The schema definitions use proper JSON Schema with types, but lack granular validation constraints (enums, min/max bounds). Tools are well-separated by concern (addition, multiplication, etc.) but many follow repetitive patterns without optimization. Error handling is not visible in the provided source, making recovery guidance assessment impossible. Security considerations around arbitrary Rust execution (tools 8-9) are not adequately documented in parameter descriptions.
Verify a RISC Zero proof from a .bin file and extract the computation result
Verify a RISC Zero proof from base64 encoded binary data and extract the computation result
Perform addition of two numbers using RISC Zero zkVM and return the result with ZK proof receipt
Perform addition with cryptographic signature proving authenticity using stored private key
Perform modular exponentiation with cryptographic signature proving authenticity using stored private key
Perform multiplication with cryptographic signature proving authenticity using stored private key
Missing or incomplete parameter descriptions. The 'inputs' array parameter in zkvm_run_rust_file and zkvm_run_rust_code lacks description of what format inputs should be in. The 'items: {}' schema is completely untyped, leaving LLMs guessing about input serialization format.
No input validation constraints. Numeric parameters (a, b, n, base, exponent, modulus) lack min/max bounds. This allows LLMs to pass undefined values like negative numbers for sqrt or unreasonably large exponents that will fail at runtime. Descriptions mention non-negative for sqrt but lack formal constraint (JSON Schema minimum property).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Prove that a secret number is within a range with cryptographic signature proving authenticity using stored private key
Compute square root with cryptographic signature proving authenticity using stored private key
Perform K-means clustering computation using RISC Zero zkVM
Perform linear regression computation using RISC Zero zkVM
Perform logistic regression computation using RISC Zero zkVM
Perform modular exponentiation (a^b mod n) using RISC Zero zkVM and return the result with ZK proof receipt
Perform multiplication of two numbers using RISC Zero zkVM and return the result with ZK proof receipt
Execute neural network computation using RISC Zero zkVM
Prove that a secret number is within a specified range using RISC Zero zkVM without revealing the secret number
Execute arbitrary Rust code from text input using RISC Zero zkVM and return the result with ZK proof
Execute arbitrary Rust code from a file using RISC Zero zkVM and return the result with ZK proof
Compute square root of a decimal number using RISC Zero zkVM and return the result with ZK proof receipt
Critical security concern: Tools zkvm_run_rust_file and zkvm_run_rust_code allow arbitrary Rust code execution without any documented security guardrails, sandboxing limits, or execution timeouts. Descriptions do not mention that LLMs can be tricked into generating malicious code. No rate limiting, resource limits, or audit trail guidance documented.
Repetitive tool design. The 8 authenticated_* tools duplicate the 5 basic computation tools with only a keyId parameter difference. This violates the single-concern principle and forces LLMs to reason about which variant to call. Consider consolidating via an optional authentication parameter.
Missing output schema documentation. Tool definitions show input schemas but provide no description of what these tools return. An LLM cannot plan follow-up steps without knowing whether the result is a number, a proof receipt object, verification status, etc. Return structure must be documented for each tool.
Array parameter items lack type specifications. ML-focused tools (zkvm_k_means: data array, zkvm_linear_regression: xData/yData arrays, zkvm_neural_network: input/weights arrays, zkvm_logistic_regression: xData/yData arrays) have 'items: {}' which provides no type hint to LLMs. Should specify 'items: {"type": "number"}' or similar.
No error handling or recovery guidance documented. The source code does not show error responses, validation logic, or guidance for LLMs on what to do when a tool fails (e.g., if a Rust file is not found, if proof verification fails, if computation times out). LLMs cannot plan retries or fallbacks.
Untyped array items in ML computation tools. zkvm_neural_network 'weights' parameter has 'items: {}', leaving LLM guessing whether to pass a flat array of numbers, a 2D array, or a nested structure. Parameter description states 'Network weights' but does not specify structure (e.g., [layer1_weights, layer2_weights] or flattened array).