Loading ToolBench
An stdio MCP server with built-in Suiware AI Tools for interacting with Sui Network
The Suiware MCP server defines 6 blockchain-specific tools with basic structure, but has significant quality gaps. Tool naming is descriptive (verb_noun pattern observed), but parameter descriptions are sparse or missing entirely. Most critically, several tools have incomplete or malformed schema definitions, and descriptions lack the depth needed to guide LLM tool selection. For example, 'transfer-coin' has a confusing parameter named 'coin' that is described as 'The target address' (contradicting its own name), indicating broken input schema design. Output schemas are not documented. Error handling is absent from visible code. The server appears to prioritize blockchain domain logic over agent-friendly interface design.
Get Sui address
Get non-zero wallet balances. Note that the nUSDC balance should be displayed as USDC.
Stake Sui
Swap coins
Transfer the amount of the specified coin to the specified address
Unstake Sui
transfer-coin has a critical schema error: parameter 'coin' is described as 'The target address' and parameter 'address' is described as 'The target address. Suins names starting with @ or ending with .sui are supported.' This indicates the parameter descriptions are swapped or malformed, creating ambiguity about what each parameter controls.
All tool descriptions are extremely brief (10-60 characters) and lack context about WHEN to use each tool or WHAT happens when called. For example, 'Swap coins' does not explain whether this is instant, incurs fees, has slippage, or requires confirmation. LLMs need 50-200 character descriptions explaining the action, prerequisites, and side effects.
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract return values without knowing what fields to expect. For example, get-wallet-balance returns 'non-zero wallet balances' but the response structure (array? object with coin types as keys? paginated?) is invisible.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Parameter descriptions are missing or trivial. 'swap-coin' has no description for its parameters beyond names (amount, sourceCoin, targetCoin). For example, is 'amount' in SUI or the source coin? Does it accept decimals? What is the minimum? Maximum? Undocumented parameters force LLMs to guess.
No error handling visible in tool code. If an address is invalid, a transaction fails, or an insufficient balance error occurs, there is no guidance on what the LLM should do next. Error responses must categorize failures as retryable, user-fixable, or fatal and suggest recovery steps.
No distinction between read-only and destructive operations in tool annotations. Tools like swap-coin, transfer-coin, and stake-sui modify blockchain state and should be marked with destructiveHint or require explicit confirmation before execution. Current MCP spec supports tool annotations (destructiveHint, readOnlyHint, idempotentHint) but they are not present.
Parameter types in swap-coin and transfer-coin are inconsistent or unclear. 'sourceCoin' and 'targetCoin' are strings, but are they coin symbols (SUI, USDC), full object IDs, or type identifiers? Without format constraints or enums, LLMs will invent coin names that don't exist.
No parameter validation rules documented. For example, stake-sui accepts an 'amount' but no minimum or maximum is specified. Can you stake 0 SUI? 1 billion SUI? Without constraints in the description, LLMs will pass invalid amounts that fail at runtime.