Loading ToolBench
3D AI Agent Avatar — MCP server that spawns a textured GLB avatar, inspects/validates/optimizes any 3D model, gives the agent a Solana wallet + a voice, and ships full pump.fun powers (atomic Jito-bundled launches + creator-fee collection). Powered by three.ws.
Server has 20 tools with inconsistent quality. Most tools lack visible input schemas in the provided source code, only tool names and descriptions are shown. Descriptions are present but vary widely in quality (10 - 200 chars). No parameter-level documentation visible. Error handling is basic (code/message/status fields). Tool annotations (readOnlyHint/destructiveHint) are declared in index.js but actual annotation values not visible in tool definitions. Naming follows verb_noun convention (inspect_glb, validate_glb, spawn_avatar, wallet_send, pump_buy) which is good. However, without seeing actual schema definitions, parameter descriptions, and output structures, scores are conservative. STDIO transport caps protocol readiness at 50.
Add accessories to an avatar session
ens_sns_resolve for .eth / .sol names
generate_avatar text/image-to-3D via Replicate
inspect_glb returns mesh/material/animation/bbox stats
List available animation poses for avatars
List available avatar presets from the three.ws catalog
optimize_glb runs dedup/prune/weld/Draco and returns the smaller GLB inline
pump_buy via Jupiter, optional Jito bundle
No input schemas visible in source code. All 20 tools show only name and description; actual JSON Schema definitions for parameters are not provided in the code sample. This violates the critical requirement that every tool must declare its input schema with parameter types and descriptions.
Parameter descriptions missing. No evidence of per-parameter documentation in tool definitions. LLMs cannot infer what 'token', 'pose', 'expression', 'funder', or 'creator' parameters mean without explicit descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2025-06-18+ | v2 |
pump_collect_fees drains pump.fun creator-fee vaults atomically
pump_launch is an atomic Jito-bundled launch with separate funder + creator
pump_snapshot for live market data (token="three" for $three)
render_avatar (pose + camera orbit + ARKit-52 expression → real PNG)
Spawn an avatar session with a preset or custom GLB URL
Generate speech audio for the avatar using TTS
thumbnail_glb renders any GLB to a PNG via three.ws's hosted three-light rig (the same pipeline that generates OG cards)
validate_glb runs the official Khronos validator
viewer_url builds a three.ws/viewer link + iframe embed
Get the SOL balance of a Solana wallet
Create a Solana wallet for the avatar, optionally with vanity grinder
Send SOL from one wallet to another
Output schemas not documented. Tool descriptions do not specify what fields are returned or their types. E.g., inspect_glb returns 'mesh/material/animation/bbox stats' but no schema shows the structure. Agents cannot plan downstream calls without knowing return types.
Destructive tools (wallet_send, pump_buy, pump_launch, pump_collect) lack confirmation/dry-run patterns. No evidence of a confirmation step before irreversible operations. Agents can accidentally drain wallets or launch tokens without user approval.
Secrets and credentials not addressed. Tools like wallet_create, wallet_send, pump_buy, and pump_launch interact with Solana/pump.fun APIs. No evidence of server-side secret injection or credential management. If API keys are passed as parameters, they will leak into logs.