Loading ToolBench
Model Context Protocol server for Cardano blockchain integration with documentation parsing, repository indexing, and prompt execution capabilities
The Cardano MCP server has significant gaps in definition quality. While all 5 tools have names and descriptions, most lack complete parameter type information visible in the source code. Tool schemas are defined using Zod in the implementation but descriptions are present. However, tool parameter descriptions are minimal, and output schemas are not formally documented. The repository tools (index-repository, repository-status, search-repository) have basic descriptions but lack guidance on when to use them or what downstream actions they enable. The wallet and contract tools (generate-wallet-connector, validate-contract) have even more minimal documentation. Error handling returns text responses but lacks structured error classification or recovery guidance.
Wallet connector code generation for specified wallet type and network
Index a repository by owner and name, registering it if not already in the registry
Check the indexing status of a repository and retrieve its metadata and content information
Search repository content by query string with optional file type filtering
Contract validation for Cardano smart contract code
generate-wallet-connector and validate-contract have minimal descriptions (under 50 chars) that do not explain when to use them, prerequisites, or what fields to expect in the response. LLMs cannot determine correct tool selection without clearer intent guidance.
No output schemas are documented in the tool definitions. Tools return text content via the MCP result format, but the structure of returned data (JSON fields, pagination, references for downstream tool calls) is not formally described. LLMs cannot plan multi-step tool sequences without knowing what fields to extract.
Parameters like 'walletType' and 'network' in generate-wallet-connector lack enums or valid value documentation. LLMs will hallucinate wallet types and network names rather than selecting from a known set. Descriptions should specify: 'One of: ethereum, cardano, solana' or similar.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Error handling returns unstructured text in the response body with isError flag, but does not categorize errors as retryable/user-fixable/fatal, nor provide recovery guidance. A failed validation returns 'Error validating contract' without telling the LLM whether to retry, ask the user for fixes, or abandon the path.
Tool descriptions for repository tools are functional but generic. 'Check the registration and indexing status' does not explain the difference from index-repository, when to call this instead, or what use cases it unblocks. Descriptions should answer: What does it do? When should I call it instead of similar tools?
The 'domain' parameter in index-repository is optional but its purpose is unclear. Description says 'Optional domain categorization' without specifying valid values or use cases. Is it for filtering? Tagging? Routing? The vague description invites misuse.
search-repository accepts a 'fileType' parameter described as 'Optional file type filter (e.g., "ts", "md")' but does not specify whether to use extensions without dots, whether it is case-sensitive, or whether wildcards are supported. The example suggests '.ts' but description shows 'ts', ambiguous for LLM input.