Loading ToolBench
MCP server for interacting with Aevo testnet, providing tools to transfer coins and cancel orders
Server has 2 tools with basic parameter definitions visible in the source code. Both tools have descriptions and input schemas present, but the schemas lack proper structure, descriptions for parameters, and default value documentation. Parameter descriptions are minimal (under 30 chars), and there is no output schema documentation. Error handling is minimal and does not guide the agent on recovery paths. The server lacks security best practices (credentials are referenced but validation of injection is not visible), and tool composition is adequate but basic.
Cancel an existing order by order ID on Aevo testnet
Transfer coins to a specified address on Aevo testnet with optional asset type
Parameter descriptions are too short and lack format/constraint guidance. 'to_address' is just 'The recipient wallet address' (27 chars), does not explain format (0x prefix?, length, checksumming). 'amount' has no mention of precision, decimals, or limits. 'asset' default is 'USDC' but no enum of valid assets is provided.
No output schema documented. Both tools return a dict with 'status', 'via', and 'response' fields, but the structure of the 'response' field is completely undocumented. LLMs cannot plan downstream calls or extract structured data without knowing what fields the response contains.
Error handling is generic and does not guide agent recovery. Errors like 'SDK transfer failed: {e}' or 'REST transfer failed: {e}' do not tell the LLM whether to retry, ask the user, or consider the operation unrecoverable. Missing recovery guidance per pattern:recovery-guide.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 33 | - | v1 |
No input validation before making API calls. LLMs could pass negative amounts, invalid addresses, or malformed asset types. Tool should validate early and return structured error messages like 'Invalid amount: must be > 0' not a raw exception.
cancel_order accepts only 'order_id' (a string) with no description of expected format. Is it a UUID, integer ID, or API-assigned string? No constraint documentation. Similar to transfer_coins, this invites invalid input from LLMs.
Tool descriptions do not explain WHEN to use each tool or distinguish them from similar operations. 'Transfer coins to a specified address on Aevo testnet with optional asset type' is vague, does 'transfer' mean a withdrawal, a payment, or an internal move? No guidance on prerequisites (minimum amount, wallet state, etc.).
No permission-gating or audit trail visible. Both tools perform write operations (WRITE risk level) but do not log caller identity, timestamp, or parameters in a structured audit format. Agents calling these tools cannot be traced for compliance.
No idempotency guarantees documented. If an LLM retries transfer_coins with the same parameters due to a network timeout, will it create a duplicate transfer? The tool should either guarantee idempotence or return a clear 'already processed' response.
Credentials (AEVO_API_KEY, AEVO_API_SECRET, AEVO_SIGNING_KEY) are correctly injected via environment variables and NOT exposed as tool parameters, this is good. However, the fallback REST call includes these credentials in request headers with no validation that they are actually set. The try/except silently falls through without clear error messages.