dex-metrics-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools have overlapping purposes with multiple variations of trading volume retrieval by different dimensions (DEX, chain, frontend, etc.), which could cause confusion. However, the descriptions clearly specify the breakdown dimension and timeframe, helping to distinguish them. There is some ambiguity between similar tools like get_weekly_trading_volume_by_dex and get_weekly_solana_trading_volume_by_dex, but the descriptions clarify the scope.
Naming Consistency5/5
All tools follow a consistent snake_case naming pattern with a clear get_<timeframe>_trading_volume_by_<dimension> structure. The naming is predictable and uniform across all 10 tools, making it easy to understand what each tool does based on its name alone.
Tool Count4/5
With 10 tools, the count is reasonable for a metrics server focused on trading volume data. However, there is some redundancy with multiple tools covering similar dimensions (e.g., multiple DEX-focused tools with different timeframes), which makes the set feel slightly heavy but still within appropriate bounds for the domain.
Completeness3/5
The server covers various dimensions (DEX, chain, frontend, aggregator, Telegram bot) and timeframes (daily, weekly, monthly, latest, YoY), but there are notable gaps. For example, there is no tool for creating, updating, or deleting data, and coverage is inconsistent across dimensions (e.g., no monthly data for chains or frontends). The surface is focused on retrieval only, which limits completeness for a full metrics management system.
Average 4/5 across 10 of 10 tools scored. Lowest: 3.2/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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return format ('markdown-formatted table') and error handling, but fails to address critical aspects such as data freshness, rate limits, authentication needs, or whether the operation is read-only or has side effects. This leaves significant gaps for a tool that likely queries live data.
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 and front-loaded with the core purpose, followed by clear sections for arguments and returns. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 lack of annotations and output schema, the description provides basic operational details (purpose, parameter, return format) but is incomplete. It misses behavioral traits like data latency or error conditions, and while it covers the parameter adequately, the overall context for a data retrieval tool in a sibling-rich environment is insufficient.
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?
The description adds meaningful context for the single parameter 'limit' by explaining its purpose ('Maximum number of rows to retrieve') and default value, which compensates for the 0% schema description coverage. However, it doesn't specify constraints like minimum/maximum values or how rows are ordered, leaving minor gaps.
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 ('Retrieve') and resource ('latest 24-hour and 7-day trading volume by aggregator'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_yoy_monthly_trading_volume_by_aggragator' or 'get_latest_trading_volume_by_dex', which would require more precise scope clarification.
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 guidance is provided on when to use this tool versus alternatives like 'get_latest_trading_volume_by_dex' or other volume-related tools. The description lacks context about use cases, prerequisites, or exclusions, leaving the agent without direction for tool selection.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context beyond the schema by specifying the return format ('markdown-formatted pivot table') and error handling ('error message if the query fails'), but lacks details on rate limits, authentication needs, data freshness, or other operational 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 well-structured and front-loaded, with the core purpose stated first, followed by clear sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 moderate complexity (one optional parameter, no output schema), the description is partially complete. It covers the purpose, parameter, and return format, but lacks context on data sources, time ranges, or how it differs from siblings, leaving gaps for effective agent 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?
The description adds meaningful semantics for the single parameter 'limit', explaining it as 'Maximum number of rows to retrieve from the query' with a default value, which compensates for the 0% schema description coverage. Since there's only one parameter, this provides adequate clarity, though it doesn't elaborate on row content or ordering.
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 tool's purpose with 'Retrieve weekly trading volume by blockchain', specifying both the action (retrieve) and resource (weekly trading volume by blockchain). It distinguishes itself from siblings by focusing on weekly data aggregated by chain rather than by DEX, aggregator, or other dimensions, though it doesn't explicitly contrast with them.
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 guidance on when to use this tool versus alternatives. With multiple sibling tools for trading volume data (e.g., get_daily_trading_volume_by_dex, get_monthly_trading_volume_by_dex), there's no indication of whether this tool is preferred for weekly summaries, chain-level analysis, or other contexts, leaving usage unclear.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: data comes from 'Dune Analytics query,' returns 'markdown-formatted pivot table,' and may return 'an error message if the query fails.' However, it lacks details on permissions, rate limits, query execution time, or what constitutes a 'failure.' For a data-fetching tool with zero annotation coverage, this is adequate but leaves gaps.
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 and concise. It opens with a clear purpose statement, elaborates on data source and format, and includes dedicated Args and Returns sections. Every sentence adds value without redundancy, and it's appropriately sized for the tool's complexity.
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 tool's moderate complexity (1 parameter, no annotations, no output schema), the description is reasonably complete. It covers purpose, data source, output format, parameter meaning, and error handling. However, without annotations or output schema, it could benefit from more behavioral details (e.g., query constraints, authentication needs) to be fully comprehensive.
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?
The description adds meaningful semantics beyond the input schema. The schema only documents 'limit' as an integer with default 1000 (0% coverage). The description clarifies it's the 'Maximum number of rows to retrieve from the query,' explaining its purpose. Since there's only one parameter and the description compensates well for the low schema coverage, this earns a high score.
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 tool's purpose: 'Retrieve year-over-year monthly trading volume by aggregator' and 'fetches year-over-year monthly trading volume data for aggregators from a Dune Analytics query.' It specifies the verb (retrieve/fetch), resource (trading volume data), and scope (year-over-year monthly, by aggregator). However, it doesn't explicitly differentiate from sibling tools like 'get_latest_trading_volume_by_aggregator' or 'get_monthly_trading_volume_by_dex' beyond the 'year-over-year monthly' aspect.
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 guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or explain scenarios where this specific year-over-year monthly aggregator data is needed compared to daily, weekly, latest, or dex-focused volume tools. Usage context is implied but not explicit.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It specifies the return format ('markdown-formatted table') and error handling ('error message if the query fails'), which adds useful context. However, it lacks details on rate limits, authentication needs, or data freshness, which are important for a data retrieval 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 appropriately sized and front-loaded, with the core purpose stated first, followed by clear sections for arguments and returns. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 tool's moderate complexity (1 parameter, no output schema, no annotations), the description is fairly complete. It covers purpose, parameter semantics, and return format. However, it could improve by addressing behavioral aspects like data latency or usage compared to siblings, which would enhance completeness for an agent.
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?
The description adds meaning beyond the input schema by explaining that the 'limit' parameter controls the 'maximum number of rows to retrieve from the query' and specifies a default value of 1000. With schema description coverage at 0%, this compensates well for the single parameter, though it could clarify what 'rows' represent (e.g., DEX entries).
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 specific action ('Retrieve'), resource ('latest 24-hour and 7-day trading volume'), and scope ('by decentralized exchange (DEX)'). It distinguishes itself from siblings like 'get_daily_trading_volume_by_dex' by specifying the timeframes (24-hour and 7-day) rather than daily, and from 'get_latest_trading_volume_by_aggregator' by focusing on DEX rather than aggregator.
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 for retrieving recent trading volume data by DEX, but does not explicitly state when to use this tool versus alternatives like 'get_daily_trading_volume_by_dex' or 'get_weekly_trading_volume_by_dex'. No exclusions or prerequisites are mentioned, leaving the context somewhat open-ended.
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 and does well by disclosing key behaviors: it fetches from Dune Analytics, returns markdown-formatted pivot tables with specific structure (dates as index, DEX projects as columns), and may return error messages on query failure. It doesn't mention rate limits, authentication needs, or data freshness, but covers core operational 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 efficiently structured with a clear purpose statement, operational details, and separate Args/Returns sections. Every sentence adds value: first states what it does, second explains source and output format, third documents the parameter, fourth describes return value. No wasted words.
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 single-parameter query tool with no annotations or output schema, the description is quite complete: it explains purpose, data source, output format, parameter semantics, and error behavior. It could mention query execution time or data latency, but covers essential context given the tool's moderate complexity.
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?
The description adds meaningful context for the single parameter: it explains 'limit' controls 'maximum number of rows to retrieve from the query' with a default of 1000. Since schema description coverage is 0% (schema only has title 'Limit'), this compensates well by providing purpose and default value beyond the bare 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 specific action ('retrieve daily trading volume'), resource ('by decentralized exchange'), and data source ('from a Dune Analytics query'). It distinguishes from siblings by specifying 'daily' frequency and 'by DEX' focus, unlike weekly/monthly or by chain/aggregator/frontend alternatives.
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 context through 'daily trading volume' and 'DEX' focus, suggesting when this tool is appropriate. However, it doesn't explicitly state when to use this vs. siblings like get_weekly_trading_volume_by_dex or get_latest_trading_volume_by_dex, nor does it mention prerequisites or exclusions.
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 and adds valuable behavioral context: it specifies the data source ('Dune Analytics query'), output format ('markdown-formatted pivot table'), structure ('dates as index, DEX projects as columns'), and error handling ('error message if query fails'). It doesn't mention 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: first sentence states purpose, second adds behavioral details, and separate Args/Returns sections provide parameter and output specifics without redundancy. Every sentence adds value.
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 single-parameter read tool with no annotations or output schema, the description is quite complete: it covers purpose, data source, output format, parameter semantics, and error handling. Minor gaps include lack of date range parameters or pagination details.
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?
Schema description coverage is 0%, but the description compensates by explaining the 'limit' parameter's purpose ('Maximum number of rows to retrieve'), default value (1000), and optional nature. However, it doesn't clarify what 'rows' refer to in the query context or provide range constraints.
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 specific action ('Retrieve monthly trading volume'), identifies the resource ('by decentralized exchange (DEX)'), and distinguishes it from siblings by specifying 'monthly' frequency and 'by DEX' grouping, unlike daily/weekly or chain/frontend alternatives.
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 implies usage context through 'monthly' and 'by DEX', helping differentiate from daily/weekly siblings or those focused on other entities like chains or aggregators. However, it lacks explicit when-not-to-use guidance or direct alternative naming.
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 of behavioral disclosure. It effectively describes key behaviors: it fetches data from Dune Analytics, returns a markdown-formatted pivot table with dates as index and DEX projects as columns, and may return an error message on query failure. However, it does not cover aspects like rate limits, authentication needs, or data freshness, leaving some gaps.
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 and front-loaded, starting with the core purpose, followed by details on data source and output format, and ending with parameter and return value explanations. Each sentence adds value without redundancy, making it efficient and easy to parse.
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 tool's moderate complexity (1 parameter, no output schema, no annotations), the description is largely complete: it covers purpose, data source, output format, parameter semantics, and error handling. However, it lacks details on behavioral aspects like rate limits or data update frequency, which would enhance completeness for a data-fetching 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?
The description adds meaningful context for the single parameter 'limit' by specifying it as 'Maximum number of rows to retrieve from the query' with a default of 1000, which compensates for the 0% schema description coverage. This clarifies the parameter's purpose beyond the schema's basic type and title, though it could elaborate on implications (e.g., how rows relate to dates or DEXs).
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 specific action ('Retrieve weekly trading volume by decentralized exchange'), resource ('on the Solana blockchain'), and scope ('from a Dune Analytics query'). It distinguishes from siblings by specifying 'weekly' frequency and 'Solana' blockchain, unlike other tools with different frequencies (daily, monthly, yearly) or scopes (by chain, frontend, etc.).
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 for weekly Solana DEX volume data but does not explicitly state when to use this tool versus alternatives like get_weekly_trading_volume_by_chain or get_daily_trading_volume_by_dex. It mentions the data source (Dune Analytics) and output format, which provides some context, but lacks clear guidance on exclusions or specific scenarios favoring this tool over siblings.
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?
With no annotations provided, the description carries the full burden. It discloses key behaviors: data source (Dune Analytics query), output format (markdown-formatted pivot table), and error handling (returns error message on query failure). However, it lacks details on rate limits, authentication needs, or data freshness, which are important for a data-fetching 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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by details on data source, output format, and parameter/return info. Every sentence adds value with no redundancy, making it efficient and well-structured.
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 tool's moderate complexity (data retrieval with one parameter) and no annotations or output schema, the description is mostly complete: it covers purpose, data source, output format, parameter semantics, and error handling. However, it could improve by mentioning potential limitations like query performance or data latency, which are relevant for weekly volume data.
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 adds meaning by explaining the 'limit' parameter as 'Maximum number of rows to retrieve from the query' with a default of 1000, which clarifies its purpose beyond the schema's basic type and title. Since there is only one optional parameter, this is sufficient for a high score.
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 specific action ('Retrieve weekly trading volume by decentralized exchange'), identifies the resource (DEX trading volume data from Dune Analytics), and distinguishes it from siblings by specifying the weekly timeframe and DEX focus, unlike daily/monthly/YoY or chain/frontend/aggregator variants.
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 implies usage context by specifying 'weekly trading volume by DEX,' which helps differentiate from siblings with different timeframes (e.g., daily, monthly) or scopes (e.g., by chain, frontend). However, it does not explicitly state when to use this tool versus alternatives or mention any exclusions, such as handling errors or prerequisites.
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 and adds valuable behavioral context: it specifies the data source (Dune Analytics query), output format (markdown-formatted table), sorting behavior (descending by volume), and error handling (returns error message on query failure). It does not mention rate limits or authentication needs, but covers key operational aspects.
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 and front-loaded: the first sentence states the core purpose, followed by elaboration on behavior, parameters, and returns. Each sentence adds distinct value with zero waste, making it efficient and easy to parse.
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 no output schema, the description provides good coverage: it explains the tool's purpose, behavior, parameter, and return format. It could be more complete by specifying the exact columns in the output table or query details, but for a single-parameter query tool, it is largely sufficient.
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 documents the single parameter 'limit', explaining its purpose ('Maximum number of rows to retrieve'), optional nature, and default value (1000). This fully covers the parameter semantics beyond the basic schema, though it could note that the limit applies to query rows before sorting.
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 specific action ('Retrieve', 'fetches'), resource ('7-day trading volume data for different frontends'), and source ('from a Dune Analytics query'). It distinguishes from siblings by specifying 'by frontend' rather than by dex, chain, or other dimensions present in sibling tool names.
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 context through '7-day trading volume' and 'by frontend', suggesting this is for weekly frontend-level analysis. However, it does not explicitly state when to use this tool versus alternatives like daily or monthly tools, or tools focusing on other dimensions like dex or chain, leaving some ambiguity.
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 of behavioral disclosure. It effectively describes key behaviors: the tool fetches data from an external source (Dune Analytics query), returns markdown-formatted output (a pivot table with dates as index and bot names as columns), and handles errors (returns an error message if the query fails). However, it doesn't mention potential rate limits, authentication requirements, or data freshness details.
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 efficiently structured with zero wasted sentences: a clear purpose statement, elaboration on data source and output format, and separate sections for Args and Returns. Each sentence adds essential information, and the formatting with bullet points enhances readability without unnecessary verbosity.
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 tool with no annotations, no output schema, and minimal parameters, the description provides good completeness: it covers purpose, data source, output format, parameter semantics, and error handling. However, it lacks details on data range (e.g., historical limits), pivot table specifics (e.g., sorting, missing data handling), or performance characteristics that could enhance context for an AI agent.
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?
The description adds meaningful context for the single parameter 'limit' by explaining it controls 'Maximum number of rows to retrieve from the query' and provides the default value (1000). With 0% schema description coverage and only one parameter, this adequately compensates, though it doesn't elaborate on row semantics or query implications beyond the basic definition.
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 specific action ('Retrieve daily trading volume by Telegram bot'), identifies the resource ('daily trading volume data for Telegram bots'), and distinguishes from siblings by specifying the data source ('from a Dune Analytics query') and output format ('markdown-formatted pivot table'). It explicitly mentions bot names as columns, differentiating it from sibling tools that focus on DEX, aggregator, chain, or frontend metrics.
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 when to use this tool: when needing daily trading volume data specifically for Telegram bots from Dune Analytics in a pivot table format. It implicitly distinguishes from siblings by not mentioning alternatives like 'get_daily_trading_volume_by_dex', but lacks explicit guidance on when not to use it or direct comparisons to other tools in the list.
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:

[![dex-metrics-mcp MCP server](https://glama.ai/mcp/servers/kukapay/dex-metrics-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kukapay/dex-metrics-mcp)

Score Badge

Copy to your README.md:

[![dex-metrics-mcp MCP server](https://glama.ai/mcp/servers/kukapay/dex-metrics-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kukapay/dex-metrics-mcp)

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/kukapay/dex-metrics-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server