Loading ToolBench
Production-ready Model Context Protocol (MCP) server for Casper Network
This MCP server provides 8 well-intentioned tools for Casper Network blockchain operations, but falls short of production quality due to inconsistent parameter documentation, missing output schemas, and incomplete error guidance. Tool naming follows verb_noun conventions well (create_wallet, transfer_cspr, get_balance, etc.), which is a strength. However, parameter descriptions lack specificity about formats, ranges, and constraints. Output schemas are entirely undocumented, we can infer what the code returns (publicKey, deployHash, etc.) but the tool definitions do not formally declare these. Error handling is present in code (handleError function) but the error recovery guidance is not propagated to tool definitions. Security is problematic: private keys are accepted as parameters, which violates pattern:secret-injection; these should be server-side only. The create_wallet tool lacks any input parameters, which is appropriate, but other tools show inconsistent parameter validation documentation. Most tools are READ_ONLY or require permission checks, but no explicit scope declarations or permission gates are visible in the tool definitions.
Creates a new Casper Network wallet with ED25519 key pair. Generates public key, account hash, and private key for mainnet use.
Delegate CSPR tokens to a validator for staking rewards on Casper Network mainnet. Creates, signs, and broadcasts the delegation transaction.
Get detailed account information from Casper Network mainnet including associated keys, action thresholds, main purse, and named keys.
Get CSPR balance for a wallet address on Casper Network mainnet. Queries the current balance from the blockchain.
Get staking rewards and delegation information for an account on Casper Network mainnet. Shows total staked amount, validators, and delegation details.
Get detailed information about a Casper Network validator including stake amounts, delegation rate, delegator count, and performance metrics.
Private keys exposed as tool parameters (fromPrivateKeyPem in transfer_cspr, delegatorPrivateKeyPem in delegate_stake, undelegate_stake) violate secure credential handling. Private keys should NEVER be passed as parameters; they must be server-side injected via environment variables only.
Output schemas completely undocumented. Tools return structured objects (deployHash, publicKey, accountHash, explorerUrl, etc.) but these are inferred from code, not formally declared in tool definitions. LLMs cannot plan downstream operations or extract return values confidently.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | 2024-11-05+ | v1 |
Transfer native CSPR tokens to another address on Casper Network mainnet. Creates, signs, and broadcasts the transfer deploy.
Undelegate CSPR tokens from a validator on Casper Network mainnet. Creates, signs, and broadcasts the undelegation transaction. Tokens go through ~14 days unbonding period.
Parameter descriptions lack format constraints and ranges. Examples: 'publicKey' param says 'hexadecimal format (e.g. 01abc123...)' but no max length or validation pattern documented. 'amount' lacks min/max bounds (1 CSPR? 1,000,000 CSPR?). These omissions force LLMs to guess valid input ranges.
No error recovery guidance in tool descriptions. Code includes handleError() and error messages, but tool definitions do not describe failure modes, retryability, or next steps. LLMs cannot self-correct or recover from errors intelligently.
No permission declarations. Tools like transfer_cspr and delegate_stake modify blockchain state and require authorization, but no explicit scope declarations (e.g. 'write:stake', 'write:transfer') or permission gate patterns are documented. This prevents least-privilege agent configuration.
Destructive operations (transfer_cspr, delegate_stake, undelegate_stake) lack confirmation or dry-run capability. Agents can accidentally send funds or delegate tokens without user confirmation, with irreversible consequences. No confirmation_before_execute pattern.
Numeric parameter bounds undefined. 'amount' in transfer_cspr and delegate_stake accepts any number > 0, but no documentation of realistic min (dust amounts?) or max (account balance?) constraints. This invites out-of-range errors or wallet draining.
get_balance, get_account_info, get_staking_rewards, and get_validator_info have optional publicKey/validatorPublicKey parameters that default to environment variables. This is a good pattern, but the fallback behavior is not documented in descriptions, LLMs may not realize they can omit the param.