Loading ToolBench
Single tool 'check_balance' has a well-formed input schema with proper types and enum constraints for network parameter. However, the tool lacks output schema documentation, the response structure is not formally defined. Description is adequate (89 chars) but generic. No error handling guidance, no recovery hints, and no documentation of what the tool returns or when to use it. The implementation catches errors but returns them as plain text without actionable recovery steps. Overall, this is a minimal, functional definition that falls short of production quality.
Check the balance of a TRN account for a specific asset
No output schema documented. Tool returns balance as plain text string; LLMs cannot infer structure or plan downstream operations. Per pattern:tool, output schemas must be documented.
Error responses lack recovery guidance. Errors return raw messages like 'Error: <message>' without telling the LLM what to do next (retry, ask user, or fail). Per pattern:recovery-guide, errors must guide the agent's next action.
Tool description does not explain WHEN to use it or what it returns. 'Check the balance of a TRN account for a specific asset' lacks context about return format, prerequisites, or use cases. Per pattern:tool-description, descriptions must state WHAT, WHEN, and WHAT IT RETURNS.
Parameter descriptions are minimal. 'Asset ID to check balance for' and 'Account ID to check balance for' lack format hints, constraints, or examples. Per pattern:tool-description, every parameter needs a description explaining what it controls and its expected format.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
No input validation or constraint documentation. assetId is a number with no min/max bounds; accountId is a string with no format hint. Per review:param-validation-rules, numeric parameters must specify range (e.g. 1 - 1000) and string parameters must specify format or length.