DeBank MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency3/5
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.
Tool Count4/5
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.
Completeness4/5
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.
Average 4.1/5 across 13 of 16 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![debank-mcp-server MCP server](https://glama.ai/mcp/servers/caiovicentino/debank-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/caiovicentino/debank-mcp-server)

Score Badge

Copy to your README.md:

[![debank-mcp-server MCP server](https://glama.ai/mcp/servers/caiovicentino/debank-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/caiovicentino/debank-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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