Loading ToolBench
Standalone MCP server for DeBank data access. Provides tools to query DeFi protocol information, user balances, tokens, transactions, and execute JavaScript against a pre-authenticated DeBank client.
Strong tool definitions with clear naming, comprehensive descriptions, and proper Zod schemas. All 6 tools have verb-noun names (execute, search_docs, debank_resolve, list_endpoints, get_endpoint_schema, invoke_endpoint) and detailed descriptions (100-400 chars). Input schemas are fully defined with Zod and include parameter descriptions. Tool annotations (readOnlyHint) are present. Main gaps: output schemas are not formally documented in the tool definitions themselves (only mentioned in descriptions); error handling is present but could be more prescriptive about recovery paths; no batch variants for common multi-call patterns.
Resolve a human-readable chain name (e.g. 'BSC', 'Binance Smart Chain', 'Polygon') to a DeBank chain ID. Returns { resolved: '<id>' } on success or { resolved: null, error: '...' } on miss.
Run async JavaScript against a pre-authenticated DeBank client. Define `async function run(debank) { ... }` and the return value (JSON-serializable) is sent back to you, plus any console.log output. The debank client mirrors the services: debank.chain, debank.protocol, debank.token, debank.user, debank.transaction, plus debank.resolveChain / resolveChains / resolveWrappedToken helpers. Note: this is JavaScript, not TypeScript — do not use type annotations. Variables do NOT persist between calls. No fs, no network outside the debank client.
Return the full schema for one endpoint: parameters (JSON Schema), response shape (JSON Schema), description, and an example agent call. Use before `invoke_endpoint` to construct correct params and a useful `jq_filter`.
Invoke one DeBank endpoint by qualified name. Returns the JSON response, optionally projected through a jq filter. **When using this tool, always use the `jq_filter` parameter to reduce the response size and improve performance.** Only omit if you're sure you don't need the data. Workflow: 1. Call `get_endpoint_schema` to see params + response shape. 2. Construct `params` matching the schema. 3. Provide `jq_filter` to project only the fields you need. For multi-call workflows (joining, looping, conditional logic), prefer `execute` (sandboxed JS) which gives full programmatic control.
Output schemas not formally documented in tool definitions. While descriptions mention return structure, there is no explicit JSON Schema for response shapes in the tool registration. LLMs cannot reliably plan downstream calls without knowing what fields to expect.
Error handling lacks recovery guidance. Errors return JSON with 'error' field but do not suggest next steps (e.g., 'Unknown endpoint: X. Use list_endpoints to discover available endpoints' is good, but most errors are generic). LLMs need actionable recovery paths.
No batch variants for multi-call patterns. Agents invoking invoke_endpoint in a loop for multiple endpoints waste tokens and latency. A batch_invoke_endpoints tool accepting an array would be more efficient.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | <=2025-11-25 | v2 |
List DeBank API endpoints available via `invoke_endpoint`. Returns an array of `{ qualified, description }` objects. Use the `filter` parameter to narrow by keyword (e.g. "nft", "balance", "transaction"). Typical workflow: 1. list_endpoints({ filter: "nft" }) to discover relevant endpoints. 2. get_endpoint_schema({ name: "debank.user.getUserNftList" }) to see params + response shape. 3. invoke_endpoint({ name: "...", params: {...}, jq_filter: "..." }) to call it. For multi-step workflows (loops, joins, conditional logic), prefer `execute`.
Search DeBank SDK docs to find the right methods, parameters, and example code. Use before writing execute() code when you're unsure of the API.
execute tool accepts arbitrary JavaScript with limited sandboxing guarantees. While isolated-vm is optional, the description does not clearly state the security boundary or what happens if isolation fails. Users need explicit trust model.
Parameter 'detail' enum in search_docs uses lowercase values ('default', 'verbose') but descriptions use title case. Inconsistent casing can confuse LLMs about valid values.