Loading ToolBench
MCP server for interacting with Hyperledger Fabric blockchain networks
The server registers 12 tools with explicit descriptions and Zod schemas. However, there are critical gaps in parameter documentation, missing output schema specifications, and inconsistent error handling. Tool names are action-oriented (invoke_, query_, get_, list_, check_) which is positive. Descriptions are present but vary in quality, most are 10-100 chars, below the 50-200 char ideal for LLM optimization. Several tools accept parameters but lack validation constraints (e.g., blockNumber has no range; chaincodeName has no format). Output schemas are never documented, LLMs cannot plan downstream calls without knowing what fields each tool returns. Error handling is minimal; there are no recovery guides or error categorization patterns evident in the code.
Check if a chaincode definition is ready to be committed
Get the approved chaincode definition for an organization
Get information about a specific block
Get blockchain information including total block count, current block hash, and previous block hash
Get information about a specific channel
Get the committed chaincode definition on the channel
Get list of chaincodes installed on the peer
No output schemas documented. LLMs cannot plan multi-step invocations or extract specific fields from responses. Each tool description says what it returns in natural language only (e.g., 'Get blockchain information including total block count, current block hash, and previous block hash') but the actual structured response format is invisible to the LLM.
Numeric parameters lack constraints. blockNumber has no min/max documented; LLMs can pass negative, zero, or absurdly large values without guidance. sequence parameter in check_commit_readiness similarly unconstrained.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Get the transaction history for a specific asset
Invoke a transaction on the Hyperledger Fabric chaincode
List all channels the peer has joined
List all identities enrolled in the wallet
Query the Hyperledger Fabric chaincode (read-only)
No enumeration constraints on string parameters. chaincodeName accepts any string; no indication of valid format, length, or naming convention. LLMs cannot distinguish a valid chaincode name from an invalid one without trial and error.
Tool descriptions are too brief (55-65 chars on average, below 50-200 char LLM-optimized range). Descriptions lack context about when to use each tool. For example, 'Get the approved chaincode definition for an organization' does not explain: What is the difference between approved, committed, and installed? When should I call this vs. get_committed_chaincode? What does 'for an organization' mean in the context of Fabric channels?
No error handling guidance visible. Handlers do not validate inputs or return structured error messages with recovery hints. If a chaincode invocation fails, the LLM gets no indication of whether it should retry, ask the user, or abandon the task.
invoke_chaincode modifies blockchain state but tool descriptions do not highlight this is a WRITE operation with side effects. No dry-run, confirmation, or undo mechanism. Agents should know invoke is irreversible; query is safe to retry.
No pagination support visible on list tools (list_enrolled_identities, get_installed_chaincodes, list_channels). If a peer has many identities or chaincodes, the response could exceed LLM context. No limit or offset parameters.