Loading ToolBench
Two tools with complete input schemas and descriptions, but neither output schema is documented. Tool naming uses action verbs (mx-query-*, mx-sdk-*) which is good, but descriptions lack strategic context for when to use them vs alternatives. Parameters are well-typed with enums where appropriate (network), but descriptions are functional rather than LLM-optimized. No error handling guidance visible in source. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite both being read-only operations.
Query MultiversX account information including balance, nonce, transactions, and guardian status for any network (mainnet, testnet, devnet)
Fetch the MultiversX SDK-DAPP v5 guide, including setup and usage for React, TypeScript, JavaScript, Angular, login/logout, signing, sending, tracking transactions, signing messages, and creating custom providers. Optionally, provide a section name to extract a specific section.
Output schemas not documented for either tool. LLMs cannot plan downstream calls or extract required fields from responses.
Tool descriptions lack strategic context. They state WHAT the tool does but not WHEN to use it instead of a similar tool or what it returns. Descriptions should be 50-200 characters and LLM-optimized.
No tool annotations despite both tools being read-only (one queries account state, one fetches guide). Adding readOnlyHint=true would clarify to agents these are safe to call repeatedly.
mx-sdk-dapp-guide tool description is weak (65 chars). 'Fetch the MultiversX SDK-DAPP v5 guide' lacks guidance on when to call this vs performing an inline search or lookup. Should explain: when you need comprehensive SDK documentation, this tool retrieves the official guide; use section parameter to focus on specific topics like Installation or Transactions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter descriptions in mx-query-account are functional but terse. E.g., 'Include transaction count in the response' does not explain why an agent might want this (e.g., to assess account activity level or detect suspicious patterns). Richer descriptions help LLMs reason about which optional flags to request.
No error recovery guidance visible. If address is invalid (wrong format), what should the agent do? Error responses should guide: 'Invalid address format. MultiversX addresses start with erd... and are 62 characters. Try search_accounts() if you have a partial name.'
timestamp parameter in mx-query-account lacks constraints and use-case explanation. When would an agent use this? What format (epoch, ISO8601)? What happens if timestamp is in the future or before account creation?