Loading ToolBench
Resolve Solana .sol names and check *.threews.sol agent-identity availability from any AI agent. sns_resolve maps a .sol name to its owner wallet, sns_reverse maps a wallet to its primary name, and threews_availability checks whether a three.ws agent handle is free to claim. No key, no signer, no payment.
Three tools with clear, domain-specific naming (sns_resolve, sns_reverse, threews_availability) and comprehensive descriptions (150 - 250 chars each). All tools are read-only with explicit risk annotations. Input schemas present with type definitions and parameter descriptions. However, output schemas are not documented in the visible code, tool handlers return JSON but the expected response structure is not formally specified. Error handling returns structured payloads with code/message/status, which is good, but recovery guidance is minimal. Tool composition is clean (each does one thing), and parameter naming is consistent (label, address, name). Missing: documented output schemas, per-parameter constraints (enums, ranges), and explicit error classification (retryable vs fatal).
Resolve a Solana Name Service (.sol) name to the base58 wallet address that owns it. Accepts a bare label, a subdomain, or the full name with or without the trailing ".sol". Returns the owner address, or resolved:false when the name is unregistered. Mainnet only. Read-only.
Reverse-lookup a Solana wallet to the primary .sol name it has set as its favorite. Returns the name, or resolved:false when the wallet has no favorite domain (a routine, expected answer — not an error). Mainnet only. Read-only.
Check whether "<label>.threews.sol" is available to claim as a three.ws agent identity. Returns the full domain, availability, the current owner wallet if taken, the on-chain check status ("ok" or "unavailable" if the Solana RPC was degraded), and the public showcase URL for a claimed handle. Minting the subdomain is an authenticated write on the HTTP API; this tool is the public read. Read-only.
Output schemas not documented. Tool handlers return JSON (resolved, owner, status, url fields inferred from descriptions), but no formal schema is visible in code or README. LLMs cannot reliably extract fields or plan downstream calls without documented response structure.
Parameter constraints not formalized. 'label' parameter in threews_availability states '1 - 63 chars of [a-z0-9-]' in description text, but no regex pattern or minLength/maxLength in schema. LLMs cannot validate before calling; server must reject invalid input and return actionable error.
Error responses lack recovery guidance. Handler returns {ok: false, error, message, status}, but does not tell LLM what to do next (retry? ask user? try alternative tool?). E.g., 'RPC degraded' should suggest 'Retry in 10s' or 'Try again later'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Tool annotations present (readOnlyHint) but incomplete. All three tools are read-only, which is correctly marked. However, no idempotentHint is declared, and no destructiveHint (correct, since none are destructive). Annotations are minimal but adequate for this domain.
No pagination or result limits documented. threews_availability returns a single domain availability check (not a list), so pagination is N/A. sns_resolve and sns_reverse are 1:1 lookups (not lists). However, if future tools return lists, no guidance on limits or pagination is visible.