Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DeBank MCP Server show me the total balance for vitalik.eth"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP (Model Context Protocol) para integração com a API do DeBank, permitindo consultar dados DeFi através de IA.
O DeBank MCP Server é um servidor MCP que conecta a poderosa API do DeBank com assistentes de IA como o Claude Desktop. Com ele, você pode consultar dados DeFi de forma natural através de conversação, incluindo:
💰 Saldos e portfolios de carteiras
🪙 Informações de tokens e preços
🎨 Coleções de NFTs
🏦 Posições em protocolos DeFi
📊 Histórico de transações
🔒 Análise de segurança de approvals
⛽ Preços de gas em tempo real
E muito mais!
Related MCP server: Datai MCP Server
Chains: Lista todas as blockchains suportadas (93+ chains)
Protocols: Informações de protocolos DeFi com TVL
Tokens: Preços, metadados e holders de tokens
Balance: Saldo total de carteiras across chains
User Tokens: Holdings de tokens com paginação
User NFTs: Coleções de NFTs com metadados
User Protocols: Posições DeFi (simple/complex)
User History: Histórico de transações
User Approvals: Análise de segurança de approvals
Net Curve: Tendências de valor em 24h
Pool Info: Analytics de liquidity pools
Transaction Simulation: Simula transações antes de enviar
Gas Prices: Preços de gas por tier
Account Units: Monitoramento de uso da API
User Social: Placeholder para futuro OAuth
Total: 15 ferramentas totalmente funcionais!
Python 3.10 ou superior
Conta no DeBank Cloud (para obter API key)
Claude Desktop (ou outro cliente MCP)
Acesse DeBank Cloud
Crie uma conta ou faça login
Navegue até a seção de API
Copie sua Access Key
# Clone o repositório
git clone https://github.com/caiovicentino/debank-mcp-server.git
cd debank-mcp-server
# Instale as dependências
pip install -e .Crie um arquivo .env na raiz do projeto:
DEBANK_ACCESS_KEY=sua_api_key_aqui⚠️ IMPORTANTE: Nunca compartilhe ou commit sua API key!
# Teste se está funcionando
python -c "from mcp_server_debank.server import mcp; print('✅ Servidor OK!')"Edite o arquivo de configuração:
code ~/Library/Application\ Support/Claude/claude_desktop_config.jsonAdicione o servidor DeBank:
{
"mcpServers": {
"debank": {
"command": "python",
"args": [
"-m",
"mcp_server_debank.server"
],
"cwd": "/caminho/para/debank-mcp-server",
"env": {
"DEBANK_ACCESS_KEY": "sua_api_key_aqui",
"PYTHONPATH": "/caminho/para/debank-mcp-server/src"
}
}
}
}Substitua /caminho/para/debank-mcp-server pelo caminho real
Substitua sua_api_key_aqui pela sua API key do DeBank
Reinicie o Claude Desktop
Edite o arquivo de configuração:
notepad %APPDATA%\Claude\claude_desktop_config.jsonUse a mesma configuração acima, ajustando os caminhos para Windows:
{
"mcpServers": {
"debank": {
"command": "python",
"args": [
"-m",
"mcp_server_debank.server"
],
"cwd": "C:\\caminho\\para\\debank-mcp-server",
"env": {
"DEBANK_ACCESS_KEY": "sua_api_key_aqui",
"PYTHONPATH": "C:\\caminho\\para\\debank-mcp-server\\src"
}
}
}
}Edite o arquivo de configuração:
nano ~/.config/Claude/claude_desktop_config.jsonUse a mesma configuração do macOS
Após configurar, você pode fazer perguntas naturais no Claude:
Qual é o saldo total da carteira vitalik.eth?Me mostre informações sobre o token USDT na EthereumQuais protocolos DeFi a carteira 0x... está usando?Liste os approvals de token da carteira 0x... na EthereumQual o preço do gas na Ethereum agora?Quantos NFTs a carteira 0x... possui?Simule esta transação antes de enviar: {dados da transação}Me dê informações sobre o pool 0x... na Ethereumdebank-mcp-server/
├── src/
│ └── mcp_server_debank/
│ ├── __init__.py
│ ├── server.py # Servidor MCP principal
│ ├── client.py # Cliente HTTP DeBank
│ ├── validators.py # Validação de inputs
│ ├── models.py # Modelos Pydantic
│ ├── portfolio_tools.py # Tools de portfolio
│ └── advanced_tools.py # Tools avançados
├── tests/ # Testes (opcional)
├── pyproject.toml # Configuração do projeto
├── .env.example # Template de configuração
├── .gitignore # Arquivos ignorados
└── README.md # Esta documentação✅ Nunca compartilhe sua API key do DeBank
✅ Use arquivo .env para armazenar credenciais
✅ Adicione .env ao .gitignore
✅ Revogue keys comprometidas imediatamente no DeBank Cloud
✅ Monitore o uso da API regularmente usando a tool debank_get_account_units
⚠️ Não exponha sua API key em commits, logs ou screenshots
⚠️ Use a tool de simulação de transações antes de enviar transações reais
Solução: Certifique-se de que o arquivo .env existe e contém sua API key, ou que a variável de ambiente está configurada corretamente no claude_desktop_config.json.
Solução:
Reinicie o Claude Desktop completamente (Cmd+Q no macOS e reabra)
Verifique se o caminho cwd no config está correto
Verifique se o PYTHONPATH está apontando para o diretório src
Solução: Use os parâmetros de paginação nas ferramentas de portfolio:
limit: Reduzir quantidade de resultados (padrão: 20, máximo: 500)
offset: Paginar através dos resultados
Solução:
Verifique se sua API key está correta
Confirme que a key está ativa no DeBank Cloud
Tente gerar uma nova API key
Solução:
O servidor implementa retry automático com backoff exponencial
Aguarde alguns segundos entre requisições
Considere fazer upgrade do plano no DeBank Cloud para limites maiores
Solução:
Certifique-se de ter executado pip install -e . no diretório raiz
Verifique se o PYTHONPATH no config aponta para o diretório src
Tente reinstalar: pip uninstall mcp-server-debank && pip install -e .
Solução:
Abra o menu Developer no Claude Desktop (View > Developer)
Verifique os logs do servidor na aba MCP
Confirme que o arquivo de configuração JSON está válido (use um validador JSON)
Teste o servidor manualmente: python -m mcp_server_debank.server
Rate Limit: Varia por plano (até 100 req/s no plano Pro)
Paginação: Máximo 500 items por página (configurável)
Chains: 93+ blockchains suportadas
Units: Cada chamada consome units da sua cota (monitore com debank_get_account_units)
Contribuições são bem-vindas! Sinta-se à vontade para:
Fazer fork do projeto
Criar uma branch para sua feature (git checkout -b feature/MinhaFeature)
Commit suas mudanças (git commit -m 'Add: MinhaFeature')
Push para a branch (git push origin feature/MinhaFeature)
Abrir um Pull Request
🧪 Adicionar testes unitários e de integração
📚 Melhorar documentação e exemplos
🐛 Reportar e corrigir bugs
✨ Implementar novas ferramentas baseadas em endpoints do DeBank
🌐 Adicionar suporte para outros idiomas
🔧 Melhorar error handling e validações
✅ 15 ferramentas MCP totalmente funcionais
✅ Suporte a 93+ blockchains
✅ Paginação implementada em todas as tools relevantes
✅ Type safety e validação robusta com Pydantic
✅ Error handling completo com retry automático
✅ Production-ready com logging estruturado
✅ Documentação completa em português
Este projeto está sob a licença MIT. Veja o arquivo LICENSE para mais detalhes.
Desenvolvido por Caio Vicentino
Para as comunidades:
🌾 Yield Hacker - Maximizando yields em DeFi
💰 Renda Cripto - Educação financeira crypto
🏗️ Cultura Builder - Construindo o futuro com AI
DeBank Cloud - Obtenha sua API key
DeBank API Docs - Documentação oficial da API
FastMCP - Framework MCP usado neste projeto
Claude Desktop - Cliente MCP oficial da Anthropic
MCP Protocol - Especificação do protocolo MCP
DeBank Platform - Explore portfolios DeFi
Se este projeto foi útil para você, considere:
⭐ Dar uma estrela no GitHub
🐛 Reportar bugs e sugerir melhorias
🤝 Contribuir com código
📢 Compartilhar com a comunidade
💬 Dar feedback sobre sua experiência
🎓 Criar tutoriais e conteúdo educativo
Feito com ❤️ para a comunidade Web3 brasileira
Check API units balance and 30-day usage from DeBank.
Monitor your API consumption to plan usage and avoid running out of units.
Returns: balance: Remaining units (integer) stats: Array of 30 days usage history usage_analysis: Summary with total usage, daily average, days remaining, peak usage day, and recommendations
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly discloses the output structure (balance, stats, usage_analysis) and implies a read-only operation. It does not mention authentication or rate limits, but for a simple informational tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: two sentences stating purpose and return values. It is front-loaded with the main purpose and uses bullet points for readability without extra fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema, the description sufficiently explains what the tool returns and why to use it. There is no missing critical information for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters and schema description coverage is 100%. Baseline is 3 as description adds no parameter-level info beyond schema, which is fine given no parameters exist. The description instead focuses on return values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Check API units balance and 30-day usage from DeBank' with a specific verb ('Check') and resource ('API units balance and 30-day usage'). It clearly distinguishes from sibling tools (e.g., debank_get_chains, debank_get_user_tokens) which focus on blockchain or user data, not API consumption.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description includes usage guidance: 'Monitor your API consumption to plan usage and avoid running out of units.' This tells when to use the tool explicitly. While it does not mention when not to use or provide alternatives, the sibling list makes the context clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get blockchain network information from DeBank.
This tool retrieves comprehensive information about blockchain networks supported by DeBank, including network details, native tokens, and protocol counts.
Args: chain_id: Optional chain ID. If provided, returns single chain info. If None, returns all supported chains. Examples: "eth", "bsc", "polygon", "arbitrum", "optimism"
Returns: Chain object(s) with the following structure: { "id": "eth", "name": "Ethereum", "logo_url": "https://...", "native_token_id": "eth", "wrapped_token_id": "0xc02...", "is_support_pre_exec": true }
Examples: - Get all chains: debank_get_chains() - Get Ethereum: debank_get_chains(chain_id="eth") - Get Binance Smart Chain: debank_get_chains(chain_id="bsc")
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully carries the behavioral disclosure burden. It accurately describes a read operation that retrieves chain info, with optional filtering. It does not mention side effects or auth requirements, but for a simple read tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Examples sections, making it easy to scan. It is somewhat verbose but every sentence adds value. The examples are helpful. Could be slightly more concise, but overall good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no annotations, but an output schema exists), the description is nearly complete. It covers the parameter, return structure, and examples. Missing details like error handling are minor for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates excellently by explaining the parameter's behavior (optional, single vs all), providing valid examples, and clarifying the return structure. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves blockchain network information from DeBank, with a specific verb and resource. It differentiates well from sibling tools that focus on accounts, gas prices, pools, etc., making the distinct purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the optional chain_id parameter (to get a specific chain vs all chains). However, it does not explicitly state when not to use this tool or compare it with alternatives, though the sibling list implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current gas prices for a blockchain from DeBank.
Monitor gas prices to optimize transaction timing and costs.
Args: chain_id: Blockchain ID (required)
Returns: Gas price tiers (slow, normal, fast, instant) with cost estimates for common transaction types
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavioral traits. It states this is a read operation ('get') and describes return data (gas price tiers). However, it lacks details like real-time freshness, caching, or authorization requirements, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a few sentences to state purpose, usage, arguments, and returns. It is front-loaded with the main action and well-structured with clear sections for args and returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers purpose, usage, parameter meaning, and return structure. Minor gaps include unspecified 'common transaction types' and exact format of chain_id, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter 'chain_id'. The description adds only 'Blockchain ID (required)', which is minimal improvement over the schema's type declaration. It does not provide examples, format hints, or possible values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves current gas prices for a blockchain from DeBank, with a specific verb ('get') and resource ('gas prices'). It is distinct from sibling tools, which focus on user-specific data, pools, or chains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions monitoring gas prices for optimizing transaction costs, providing clear context for when to use. No exclusions or alternatives are mentioned, but no sibling tool offers similar functionality, so no confusion arises.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get liquidity pool information from DeBank.
Analyze liquidity pool metrics including TVL, user counts, and statistics.
Args: pool_id: Pool identifier/contract address (required, must start with 0x) chain_id: Blockchain ID (required)
Returns: Pool object with enhanced summary metrics including TVL, user counts, average deposit size, and valuable user ratio
| Name | Required | Description | Default |
|---|---|---|---|
| pool_id | Yes | ||
| chain_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that pool_id must start with '0x' and lists returned metrics, but does not mention error handling, rate limits, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with Args and Returns sections; purpose is front-loaded. A few redundant phrases ('analyze liquidity pool metrics') could be tightened, but overall clear and reasonably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given presence of output schema, description adequately covers purpose, parameter constraints, and returned metrics. However, lacks details on error conditions or potential edge cases for an external API tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description adds essential semantics: pool_id is a contract address requiring '0x' prefix, chain_id is a blockchain ID. Provides format and purpose beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves liquidity pool information from DeBank and analyzes metrics like TVL and user counts. Distinct from sibling tools which focus on accounts, tokens, or user data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for pool metrics but does not explicitly state when to use this tool over alternatives or when not to use it. No guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get DeFi protocol information from DeBank.
This tool retrieves comprehensive information about DeFi protocols, including TVL (Total Value Locked), supported chains, and protocol metadata.
Args: protocol_id: Optional specific protocol ID (e.g., 'uniswap', 'aave', 'compound', 'curve', 'lido', 'makerdao') chain_id: Optional filter by chain (e.g., 'eth', 'bsc', 'polygon') all_chains: If True, get all protocols across all chains
Returns: Protocol object(s) with the following structure: { "id": "uniswap", "name": "Uniswap", "chain": "eth", "logo_url": "https://...", "tvl": 5234567890, "portfolio_item_list": [...] }
Examples: - Get all protocols on Ethereum: debank_get_protocols(chain_id="eth") - Get specific protocol: debank_get_protocols(protocol_id="uniswap") - Get all protocols: debank_get_protocols(all_chains=True) - Get Aave on Polygon: debank_get_protocols(protocol_id="aave", chain_id="polygon")
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | No | ||
| all_chains | No | ||
| protocol_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description returns the output structure but lacks disclosure of behavioral traits such as authentication requirements, rate limits, error conditions, or side effects. Since no annotations are provided, the description carries full burden but omits these details, though it is clear that the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-line summary followed by Args, Returns, and Examples sections. It is front-loaded with purpose, each section earns its place, and there is no wasted text. It is concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description still provides the output structure, which is helpful. It covers all parameters and use cases. However, it could be more complete by addressing edge cases or behavioral constraints (e.g., empty results, pagination). For a simple get tool with optional params, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by explaining each parameter (protocol_id with examples like 'uniswap', chain_id with chain abbreviations, all_chains as boolean) and providing meaningful examples. This adds significant value beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves DeFi protocol information from DeBank, listing TVL, supported chains, and metadata. It effectively distinguishes from sibling tools like debank_get_user_protocols (user-specific) and debank_get_chains (only chains), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides multiple examples showing different query patterns (by protocol, by chain, all chains), which implies usage contexts. However, it does not explicitly state when to use this tool over alternatives (e.g., when to use debank_get_user_protocols instead), nor does it provide when-not or prerequisite guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top holders of a token from DeBank.
This tool retrieves the largest holders of a specific token, useful for analyzing token distribution and whale activity.
Args: chain_id: Blockchain ID (required). Examples: "eth", "bsc", "polygon" token_id: Token contract address (required, must start with 0x) limit: Number of holders to return (max 100, default 100) offset: Starting position for pagination (max 10000, default 0)
Returns: Object with holder data: { "holders": [ { "address": "0x5853ed4f26a3fcea565b3fbc698bb19cdf6deb85", "amount": "1234567890000000000", "usd_value": 1234567.89 }, ... ], "total_count": 50000 }
Examples: - Get top 100 USDT holders: debank_get_token_holders( chain_id="eth", token_id="0xdac17f958d2ee523a2206206994597c13d831ec7" ) - Get next 50 holders: debank_get_token_holders( chain_id="eth", token_id="0xdac17f958d2ee523a2206206994597c13d831ec7", limit=50, offset=100 )
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| chain_id | Yes | ||
| token_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it returns top holders, supports pagination with limit and offset parameters, and defines maximum values (limit 100, offset 10000). However, it does not cover rate limits, authentication, or potential errors. Without annotations, the description carries full behavioral burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (Args, Returns, Examples). It is somewhat lengthy but every sentence adds value. Could be slightly more concise by combining some points, but overall structure is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a paginated data retrieval tool. It explains purpose, all parameters with examples, return format with a sample object, and includes usage examples. The presence of an output schema (implied by the Returns section) further supports completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description extensively adds meaning to each parameter beyond the input schema: chain_id with examples ('eth', 'bsc', 'polygon'), token_id with requirement to start with '0x', and limit/offset with defaults and maximums. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves top holders of a specific token from DeBank, with explicit mention of analyzing token distribution and whale activity. It distinguishes itself from other debank tools (e.g., account units, chains, pools) by focusing on token holders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example calls but lacks explicit guidance on when to use this tool versus alternatives. It does not state prerequisites, when not to use it, or mention alternative tools for related queries like token info or user balances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get token information and prices from DeBank.
This tool retrieves comprehensive token data including current prices, historical prices, decimals, symbols, logos, and verification status.
Args: chain_id: Blockchain ID (required). Examples: "eth", "bsc", "polygon" token_id: Single token contract address (0x prefixed) token_ids: List of token addresses (max 100, 0x prefixed) date: Historical date in YYYY-MM-DD format for price lookup
Returns: Token object(s) with the following structure: { "id": "0xdac17f958d2ee523a2206206994597c13d831ec7", "chain": "eth", "name": "Tether USD", "symbol": "USDT", "price": 1.0, "decimals": 6, "logo_url": "https://...", "is_verified": true, "is_core": true }
Examples: - Get USDT: debank_get_token_info( chain_id="eth", token_id="0xdac17f958d2ee523a2206206994597c13d831ec7" ) - Get multiple tokens: debank_get_token_info( chain_id="eth", token_ids=["0xdac17f958d2ee523a2206206994597c13d831ec7", "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48"] ) - Get historical price: debank_get_token_info( chain_id="eth", token_id="0xdac17f958d2ee523a2206206994597c13d831ec7", date="2024-01-15" )
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| chain_id | Yes | ||
| token_id | No | ||
| token_ids | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that this is a read-only retrieval with historical price capability, but lacks information on rate limits, authentication, or error handling. The description is adequate but not highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, parameter list, return format, and examples. It is front-loaded but slightly verbose with extended examples; could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but declared) and the detailed parameter/return descriptions, the tool is well-documented. However, it lacks error handling details and edge cases (e.g., invalid chain_id), which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains each parameter (chain_id required, token_id vs token_ids, date format) and gives examples. This compensates effectively for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get token information and prices from DeBank' with specific verb and resource. It distinguishes itself from sibling tools like debank_get_user_tokens (user-specific) and debank_get_pool_info_tool (pool-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for each parameter (chain_id, token_id, token_ids, date) and includes multiple examples. It does not explicitly exclude alternative tools or states when not to use, but the examples effectively illustrate typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user's token/NFT approvals and authorizations from DeBank.
Args: address: User's wallet address (required) chain_id: Blockchain ID (required) approval_type: "token" or "nft" (default: "token")
Returns: For tokens: Array of authorized tokens with spender info and exposure values For NFTs: Object with tokens, contracts, and total approved amounts
Security Note: This shows which contracts have permission to spend user's assets. High exposure values indicate security risk.
Examples: - Token approvals: debank_get_user_approvals(address="0x...", chain_id="eth") - NFT approvals: debank_get_user_approvals(address="0x...", chain_id="eth", approval_type="nft")
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| chain_id | Yes | ||
| approval_type | No | token |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses returns (arrays/objects), mentions security risk, and implies read-only behavior. It could add more about rate limits or authentication, but adequately covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, structured into Args, Returns, Security Note, and Examples. Every sentence is informative and earns its place. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers both token and NFT cases, provides security context, and includes examples. Given the output schema exists and the tool has 3 params (2 required, 1 enum), the description is complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains address, chain_id (with example 'eth'), and approval_type with default. It also describes return differences for token vs NFT. Some details like valid chain_id values are omitted, but overall adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets user's token/NFT approvals, using specific verbs and resources. It distinguishes from sibling tools like debank_get_user_tokens (balances) and debank_get_user_nfts (NFTs owned) by focusing on approvals and authorizations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (checking approvals) and examples, but does not explicitly state when to use this tool versus alternatives or when not to use it. It implies usage but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user's total balance or chain-specific balance from DeBank.
This tool retrieves comprehensive portfolio data for a wallet address, including total balance across all chains or balance on a specific chain.
Args: address: User's wallet address (required, must start with 0x) chain_id: Optional chain ID. If provided, returns balance on that chain. If None, returns total balance across all chains. Examples: "eth", "bsc", "polygon", "arbitrum"
Returns: Balance information: - If chain_id is None: { "total_usd_value": 123456.78, "chain_list": [ { "id": "eth", "usd_value": 98765.43 }, ... ] } - If chain_id is specified: { "usd_value": 98765.43, "chain": "eth" }
Examples: - Get total balance: debank_get_user_balance( address="0x5853ed4f26a3fcea565b3fbc698bb19cdf6deb85" ) - Get Ethereum balance: debank_get_user_balance( address="0x5853ed4f26a3fcea565b3fbc698bb19cdf6deb85", chain_id="eth" ) - Get BSC balance: debank_get_user_balance( address="0x5853ed4f26a3fcea565b3fbc698bb19cdf6deb85", chain_id="bsc" )
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| chain_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description covers behavioral aspects. It explains the difference in behavior when chain_id is provided versus omitted, and includes a constraint on address format. It does not discuss data freshness or rate limits, but for a read-like tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for Args, Returns, and Examples. It is slightly verbose but all content is relevant. The first sentence efficiently states the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete given the tool's simplicity and presence of an output schema. It covers both return formats with examples, includes parameter constraints, and provides multiple usage examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description provides detailed explanations for both parameters. It specifies that address must start with '0x' and provides a list of valid chain_id examples. This adds substantial meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get user's total balance or chain-specific balance from DeBank'. This directly communicates the action and resource. It easily distinguishes from sibling tools like debank_get_user_tokens or debank_get_user_protocols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool, including parameters for total vs. specific chain. It includes examples that demonstrate typical use cases. However, it does not explicitly mention when not to use this tool versus alternatives, which would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user's transaction history from DeBank.
Args: address: User's wallet address (required) chain_id: Optional chain ID. If None, returns history across all chains token_id: Optional filter by specific token start_time: Optional Unix timestamp to start from page_count: Number of transactions to return (default: 20)
Returns: Dictionary with: - history_list: Array of transaction objects - cate_dict: Transaction categories - project_dict: Involved projects/protocols - token_dict: Token metadata - cex_dict: CEX data if applicable
Examples: - Recent history: debank_get_user_history(address="0x...") - Ethereum only: debank_get_user_history(address="0x...", chain_id="eth") - USDT transactions: debank_get_user_history(address="0x...", chain_id="eth", token_id="0xdac17...")
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| chain_id | No | ||
| token_id | No | ||
| page_count | No | ||
| start_time | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the return structure (history_list, cate_dict, etc.) and parameter behavior, but does not mention side effects, rate limits, or pagination behavior. It is transparent for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: purpose line, Args, Returns, Examples. No wasted sentences. Front-loaded with core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and presence of output schema, the description covers inputs, outputs, and examples comprehensively. Missing details on pagination limits or error handling, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates fully. Every parameter (address, chain_id, token_id, start_time, page_count) is explained with type, default, and optionality. Examples clarify usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get user's transaction history from DeBank.' with a specific verb and resource, and the examples differentiate from sibling tools by showing usage patterns for different filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through parameter details but does not explicitly say when to use this tool vs. alternatives like debank_get_user_balance or debank_get_user_protocols. No when-not-to-use or sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user's 24-hour asset value trends from DeBank.
Track portfolio performance over the last 24 hours with time-series data.
Args: address: User's wallet address (required, must start with 0x) chain_id: Optional single chain ID for chain-specific curve chain_ids: Optional comma-separated chain IDs for multi-chain aggregate
Returns: Time series data with summary statistics including start/end values, change amount, change percentage, and trend direction
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| chain_id | No | ||
| chain_ids | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the address must start with '0x' and describes the return values (time series with summary statistics), but does not discuss rate limits, data freshness, or whether the operation is read-only. The behavioral traits are adequately implied but not richly detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a main purpose sentence, a supporting sentence, and then a clear list of arguments and returns. It is concise without wasted words, though the argument list could be slightly more compact. It is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (3 parameters, 1 required) and existing output schema, the description covers the purpose, parameter details, and return value structure (time series with summary statistics). An agent can correctly invoke the tool and understand the output without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining each parameter: address is required and must start with '0x', chain_id is optional for a single chain, chain_ids is optional for multiple chains. This adds meaningful constraints beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 24-hour asset value trends from DeBank, with a specific verb ('Get') and resource ('user's 24-hour asset value trends'). It distinguishes itself from sibling tools that fetch other user data like tokens or history, as it focuses on time-series portfolio performance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for using the tool (track portfolio performance over 24 hours) and explains the parameters, but does not explicitly state when to use this tool versus alternatives or when not to use it. It lacks exclusion criteria or mention of related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user's NFT holdings from DeBank.
Args: address: User's wallet address (required) chain_id: Optional chain ID. If None, returns NFTs across all chains is_all: Include all NFTs (True) or only valuable ones (False, default) limit: Maximum number of NFTs to return (default: 50, max: 500) offset: Number of NFTs to skip for pagination (default: 0)
Returns: Dictionary with NFTs, metadata, content URLs, attributes, valuations, and pagination info
Examples: - All NFTs: debank_get_user_nfts(address="0x...") - NFTs on Ethereum: debank_get_user_nfts(address="0x...", chain_id="eth") - Paginated results: debank_get_user_nfts(address="0x...", limit=10, offset=0)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| is_all | No | ||
| offset | No | ||
| address | Yes | ||
| chain_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains default behavior (is_all=False, so only valuable NFTs), pagination (limit, offset), and return structure. No contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Examples sections. It is concise (about 120 words) and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers necessary details for a list endpoint: parameters, return structure, and examples. It lacks error handling or prerequisites, but given the presence of an output schema, the return description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining each parameter's purpose, defaults, and constraints (e.g., limit max 500, chain_id optional). Examples further illustrate usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get user's NFT holdings from DeBank.' This is a specific verb-resource combination, and it distinguishes the tool from siblings like debank_get_user_tokens which deals with fungible tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Examples show usage for all chains, specific chain, and pagination, indicating appropriate contexts. However, the description does not explicitly compare to alternative tools like debank_get_user_tokens, leaving some ambiguity about when to choose this over similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user's DeFi protocol positions from DeBank.
Args: address: User's wallet address (required) protocol_id: Optional specific protocol ID chain_id: Optional chain ID. If None, returns positions across all chains detail_level: "simple" for balances only, "complex" for full position details (default: "complex")
Returns: Protocol positions with assets, debts, rewards, and portfolio items
Details: - "simple": Returns net_usd_value, asset_usd_value, debt_usd_value per protocol - "complex": Returns full PortfolioItemObject with supply tokens, borrow tokens, rewards, etc.
Examples: - All positions detailed: debank_get_user_protocols(address="0x...") - Simple balance summary: debank_get_user_protocols(address="0x...", detail_level="simple") - Specific protocol: debank_get_user_protocols(address="0x...", protocol_id="aave", chain_id="eth")
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| chain_id | No | ||
| protocol_id | No | ||
| detail_level | No | complex |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details the return structure and explains 'simple' vs 'complex' levels, but does not disclose rate limits, authentication needs, or data freshness. It is read-only by implication but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Details, Examples) and each sentence adds value. It could be slightly more concise by merging example lines, but overall it is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and an output schema, the description explains parameters and return types adequately. However, it lacks edge case handling, error scenarios, prerequisites (like API keys), and does not position itself among sibling tools. Missing contextual completeness for a complex DeBank tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains each parameter: address (required), protocol_id (optional), chain_id (optional, default null meaning all chains), detail_level (enum with defaults). It also explains return values for each detail level and provides concrete examples, adding significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get user's DeFi protocol positions from DeBank.' It specifies the main function with a verb and resource, and examples distinguish it from sibling tools like debank_get_user_balance or debank_get_user_tokens by focusing on protocol-level positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus others. It does not mention when not to use it or suggest alternative tools for specific needs, such as using debank_get_user_tokens for simple token balances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get DeBank Connect social data (OAuth required - not yet implemented).
IMPORTANT: This tool requires OAuth implementation which is not yet available.
Args: access_token: OAuth bearer token (required) social_type: Type of social data - "profile", "followers", or "following" limit: Results per page (max 100, default 20) offset: Starting position (default 0)
Returns: Error message with list of available alternatives and future support details
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| social_type | No | profile | |
| access_token | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns an error message and lists alternatives, but with no annotations, it fails to specify side effects, authorization details beyond OAuth, or behavior when functional. The limitation is transparent, but behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single-purpose sentence, a critical warning, and a clear parameter list. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's non-functional state (OAuth not implemented), the description adequately sets expectations by stating it will return an error. However, it lacks details on the intended social data response and pagination, leaving gaps for when the tool becomes functional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds valuable semantics: explicitly states access_token is required, lists possible values for social_type (though not in schema), and specifies limits (max 100 for limit, defaults). This compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get DeBank Connect social data', clearly specifying the action (getting) and resource (social data). It distinguishes from sibling DeBank tools focusing on other domains like protocols or chains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns that OAuth is not yet implemented, implying the tool should not be used currently, but it does not suggest alternative tools or when to use it otherwise. The mention of 'available alternatives' in the return is vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user's token holdings from DeBank.
Args: address: User's wallet address (required) chain_id: Optional chain ID. If None, returns tokens across all chains token_id: Optional specific token to query is_all: Include all tokens (True) or only valuable ones (False, default) limit: Maximum number of tokens to return (default: 50, max: 500) offset: Number of tokens to skip for pagination (default: 0)
Returns: Dictionary with token holdings, amounts, prices, USD values, and pagination info
Examples: - All tokens across chains: debank_get_user_tokens(address="0x...") - Tokens on Ethereum: debank_get_user_tokens(address="0x...", chain_id="eth") - Specific token balance: debank_get_user_tokens(address="0x...", chain_id="eth", token_id="0xdac17...") - Paginated results: debank_get_user_tokens(address="0x...", limit=10, offset=0)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| is_all | No | ||
| offset | No | ||
| address | Yes | ||
| chain_id | No | ||
| token_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses pagination, filtering (is_all, chain_id, token_id), and return structure. It does not mention rate limits, authentication, or side effects, but for a read operation these are less critical. The description adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but every sentence adds value. It is organized with a clear header, parameter list, return info, and examples. Slightly verbose but still efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and an output schema (though not shown), the description covers all necessary aspects: parameter usage, return values, pagination, and examples. It is fully self-contained and guides correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions), so the description must compensate. It fully defines each parameter, explains defaults, and provides concrete examples. The description adds significant meaning that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('user's token holdings from DeBank'). The tool name is specific, and the description adds scope details like cross-chain vs single-chain. However, it does not explicitly distinguish from sibling tools like debank_get_user_balance or debank_get_user_nfts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit instructions on when to use this tool versus alternatives. The examples imply common use cases, but there is no guidance on when not to use it or which sibling tools to prefer for specific needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-execute and explain a transaction using DeBank's simulation.
CRITICAL SAFETY TOOL: Always simulate transactions before sending to avoid costly mistakes and security issues.
Args: transaction_data: Transaction object with required fields (chainId, from, to, value, data) pending_transactions: Optional array of transactions to simulate first explain_only: If True, only explain the transaction without full simulation
Returns: Simulation results with safety analysis including risk level, warnings, recommendations, and estimated gas costs
| Name | Required | Description | Default |
|---|---|---|---|
| explain_only | No | ||
| transaction_data | Yes | ||
| pending_transactions | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool performs simulation without real side effects, provides safety analysis including risk level, warnings, recommendations, and estimated gas costs. Lacks details on authorization but sufficient for a simulation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a critical safety note front-loaded, followed by an Args section and Returns summary. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers inputs and high-level returns. Since an output schema exists, it does not need to enumerate all return fields. It adequately addresses the complexity of a simulation tool with nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds detailed meanings: transaction_data required fields, pending_transactions as optional simulation queue, explain_only controlling full simulation vs explanation. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Pre-execute and explain a transaction using DeBank's simulation' and emphasizes it as a critical safety tool. It distinguishes from sibling tools that are primarily read-only queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Always simulate transactions before sending to avoid costly mistakes and security issues', implying its use precedes actual transaction execution. It does not explicitly state when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource or operation (e.g., chains, tokens, gas, pools, protocols, user data), and descriptions clearly differentiate them. No two tools appear to serve the same purpose.
Most tools follow a 'debank_get_<resource>' pattern, but some have a '_tool' suffix (e.g., debank_get_gas_prices_tool) while others do not (e.g., debank_get_chains). This inconsistency in suffix usage creates minor confusion.
16 tools is slightly above the typical 3-15 range for a focused server, but the scope (blockchain data, user portfolio, transaction simulation) justifies the count. It borders on heavy but remains manageable.
The server covers core DeBank functionalities: chains, tokens, pools, protocols, user balances, history, approvals, and transaction simulation. The only notable gap is the non-functional social tool, which is a minor dead end.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query real-time blockchain token data across EVM and Solana networks. Access token balances, transfers, prices, holders, NFT ownership, DEX swaps, and liquidity pools. Supports Ethereum, Base, Arbitrum, BSC, Polygon, Solana, and more.
Multi-chain wallet intelligence: balances, transactions, ENS, OFAC screening across 7 chains.
Read-only on-chain intelligence for AI agents on Base: balances, tokens, gas, tx status.
Provide AI agents and automation tools with contextual access to blockchain data including balance…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/caiovicentino/debank-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
