Desk3 MCP Server

Official

by desk3

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes focused on specific crypto metrics or data types, such as get_bitcoin_dominance for market share, get_fear_greed_index for sentiment, and get_token_price for pricing. However, some overlap exists: get_cycle_indicators and get_cycles both cover market cycle analysis, and get_pi_cycle_top and get_puell_multiple are subsets of these, which could cause confusion in selection.
Naming Consistency5/5
All tool names follow a consistent 'get_' prefix with descriptive snake_case nouns, such as get_altcoin_season_index, get_bitcoin_dominance, and get_token_price. This uniform pattern makes the tool set predictable and easy to navigate, with no deviations in naming conventions.
Tool Count3/5
With 16 tools, the count is borderline high for a crypto data server, as it includes many specialized indicators like get_pi_cycle_top and get_rainbow_chart that might be overly granular. While comprehensive, it risks feeling heavy compared to a more streamlined set of core metrics.
Completeness4/5
The tool set provides broad coverage for crypto market analysis, including prices, trends, dominance, sentiment, and cycle indicators. Minor gaps exist, such as no tools for historical data beyond trends or portfolio management features, but agents can perform most common analysis tasks without significant dead ends.
Average 3/5 across 16 of 16 tools scored. Lowest: 2.3/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, the description carries the full burden but lacks behavioral details. It mentions 'publicly available signals' and return fields, but doesn't disclose traits like data freshness, rate limits, authentication needs, or whether it's a read-only operation. The description adds some context about the indicator's purpose but misses 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is poorly structured and verbose. It starts with a rhetorical question and promotional language ('Discover...'), which doesn't efficiently convey the tool's function. The return fields are listed but buried in the text. It could be more front-loaded and concise, such as by stating the action first and removing fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial indicators and no output schema, the description is incomplete. It lists return fields but doesn't explain their meanings (e.g., what 'likelihood' represents) or format. With no annotations and a vague purpose, it fails to provide enough context for an agent to use the tool effectively, especially compared to siblings with clearer functions.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics beyond the schema, but this is acceptable given the lack of parameters. A baseline of 4 is appropriate as it doesn't detract from the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague about the tool's actual function. While it mentions 'discover the cryptocurrency market cycle indicator' and references Pi Cycle and Puell Multiple data, it doesn't clearly state what the tool does (e.g., 'retrieves current cycle indicator data' or 'returns Bitcoin four-year cycle status'). It distinguishes from siblings like get_pi_cycle_top and get_puell_multiple by combining signals, but the purpose is more explanatory than action-oriented.
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 guidance on when to use this tool versus alternatives is provided. It implies usage for identifying bull market tops with combined indicators, but doesn't compare to siblings like get_cycle_indicators or specify scenarios (e.g., 'use this for aggregated signals instead of individual ones'). The description is more promotional than instructional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description explains what Bitcoin dominance is but doesn't describe how the tool behaves: whether it returns current/latest data, historical data, real-time updates, calculation methodology, data sources, refresh rates, or error conditions. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise (two sentences) but structurally problematic. It's entirely conceptual explanation without front-loading the tool's function. The first sentence should state what the tool does, not just define the metric. While not verbose, it's inefficiently structured for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and zero parameters, the description should fully explain what the tool returns and how it behaves. Instead, it only defines the metric conceptually without specifying that this tool retrieves/returns that metric. For a tool in a server with 15+ sibling cryptocurrency tools, this leaves the agent guessing about the tool's actual function and output.
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 tool has zero parameters (schema coverage 100%), so there are no parameters needing semantic explanation. The description doesn't need to compensate for any parameter documentation gaps. A baseline of 4 is appropriate since there's nothing to document and nothing is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explains what Bitcoin dominance is conceptually but doesn't state what the tool actually does. It describes the metric itself rather than specifying that this tool retrieves/calculates/returns the current Bitcoin dominance value. The name 'get_bitcoin_dominance' suggests a retrieval function, but the description doesn't confirm this action.
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 about when to use this tool versus alternatives. With multiple sibling tools like get_fear_greed_index, get_altcoin_season_index, and get_btc_trend that provide related cryptocurrency metrics, the description offers no context about when Bitcoin dominance is the appropriate metric versus other indicators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'real-time and historical data' and an 'easy-to-use API,' but fails to specify critical details such as data freshness, rate limits, authentication requirements, error handling, or whether the tool performs any computations. This leaves significant gaps in understanding how the tool behaves operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and avoids excessive fluff, but it includes marketing language like 'powerful tool' and 'easy-to-use API' that don't add functional value. It could be more front-loaded with core functionality (e.g., 'Retrieves the Fear and Greed Index for cryptocurrency markets') to improve clarity without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a market sentiment indicator with no parameters) and lack of annotations or output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., a numeric score, timestamped data, or metadata), how to interpret the index, or any limitations (e.g., data sources, update frequency). This makes it inadequate for an agent to use the tool effectively without additional context.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, which is efficient and avoids redundancy. A baseline of 4 is applied since the schema fully covers the lack of parameters, and the description doesn't add unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides 'Fear and Greed Index' data for analyzing market sentiment, which gives a general purpose. However, it's vague about what the tool actually returns (e.g., a numerical index, chart data, or sentiment breakdown) and doesn't clearly distinguish it from sibling tools like 'get_btc_trend' or 'get_cycle_indicators' that also provide market analysis indicators.
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 mentions using the index for 'crypto investment decisions' and 'stay ahead of market trends,' which implies a context of market analysis. However, it provides no explicit guidance on when to use this tool versus alternatives like 'get_altcoin_season_index' or 'get_bitcoin_dominance,' nor does it specify prerequisites or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states what the tool does but lacks critical behavioral details such as whether this is a read-only operation, rate limits, authentication requirements, or what the output format looks like (e.g., JSON structure, error handling). This leaves significant gaps for an agent to use it effectively.
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 sentence that directly states the tool's function and key parameter support. It is front-loaded with the core purpose and wastes no words, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 is incomplete for effective tool use. It doesn't explain the return values (e.g., what 'mini ticker info' includes), error conditions, or behavioral constraints. For a data-fetching tool with no structured output documentation, this leaves the agent with insufficient context.
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?
The description mentions that the tool 'supports symbol parameter,' which aligns with the input schema's single parameter. However, with 100% schema description coverage, the schema already fully documents the parameter's purpose, format, examples, and optionality. The description adds minimal value beyond what the schema provides, meeting the baseline for high coverage.
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 action ('Get') and resource ('24-hour mini ticker info'), making the purpose understandable. It specifies the scope of data (24-hour ticker info) but doesn't distinguish this tool from potential sibling tools that might also provide ticker or market data, which prevents a perfect score.
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 mentions that the tool 'supports symbol parameter,' which implies optional filtering, but provides no explicit guidance on when to use this tool versus alternatives. Given the sibling tools include various market indicators (e.g., get_fear_greed_index, get_exchange_rate), there's no indication of when this ticker data is preferred over other market metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the chart's limitations (not suitable for short-term predictions) which is helpful context, but doesn't describe what the tool actually returns - whether it's an image, data points, or some other format. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 efficiently structured in two sentences that each serve distinct purposes: first explaining what the chart is, then stating its limitations and utility. There's no wasted text, though it could be slightly more front-loaded about the tool's specific function.
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 has no parameters, no annotations, and no output schema, the description provides adequate context about what the Bitcoin Rainbow Chart represents and its analytical purpose. However, it doesn't specify what format the tool returns (visual chart, data values, etc.), which is a significant gap for a tool with no structured output documentation.
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 tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on explaining the chart's purpose and limitations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explains what the Bitcoin Rainbow Chart is (a logarithmic growth curve with color bands for market sentiment) and its purpose (identifying overvaluation/undervaluation), but it doesn't explicitly state what the tool *does* - presumably it retrieves or displays this chart. The description is informative about the chart concept but vague about the tool's specific function.
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 some context about when the chart is useful (not for short-term predictions, helps identify valuation extremes) but offers no explicit guidance on when to use this tool versus the 15 sibling tools. There's no comparison to alternatives or specific use cases for this particular tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool returns ('estimated gas info') but doesn't describe the return format, whether it's real-time or cached data, rate limits, error conditions, or authentication requirements. The description is minimal and leaves critical behavioral aspects unspecified.
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 sentence that communicates the core purpose and key requirement. There's no wasted language or unnecessary elaboration, making it efficiently front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 and no output schema, the description is insufficiently complete. It doesn't explain what 'estimated gas info' includes (base fee, priority fee, etc.), doesn't mention typical use cases, and provides no context about the data source or reliability. Given the complexity of blockchain gas estimation, more contextual information would be helpful.
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 100%, with the single parameter 'chainid' well-documented in the schema. The description adds minimal value beyond the schema by mentioning 'chainid required,' which is already clear from the required field. This meets the baseline for high schema coverage scenarios.
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 action ('Get') and resource ('EIP1559 estimated gas info'), making the purpose understandable. However, it doesn't differentiate this tool from its many siblings (like get_exchange_rate or get_token_price), which all appear to retrieve different types of cryptocurrency/blockchain data but share similar naming patterns.
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 mentions 'chainid required' as a parameter requirement, but doesn't explain use cases, prerequisites, or how this differs from other gas estimation tools that might exist outside this server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions 'real-time' which implies current data, but doesn't disclose behavioral traits like rate limits, data sources, update frequency, error handling, or authentication needs. For a price-fetching tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 a single, efficient sentence that front-loads the core purpose. However, it could be slightly more structured by separating the parameter note into its own clause for clarity. No wasted words, but minor room for improvement in flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple parameter, the description is incomplete. It doesn't explain what 'price info' includes (e.g., price, volume, change), return format, or error cases. For a tool fetching financial data, more context on data scope and reliability is needed to be fully helpful.
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 100%, so the schema fully documents the single parameter (symbol). The description adds minimal value beyond the schema by mentioning 'supports symbol parameter' but doesn't provide additional semantics like examples of common symbols beyond what's in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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: 'Get real-time token price info' specifies the action (get) and resource (token price info). It distinguishes from siblings like get_exchange_rate (likely fiat-focused) or get_token_circulating_supply (different metric). However, it doesn't explicitly differentiate from all siblings (e.g., get_mini_24hr might also provide price-related data).
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 mentions 'supports symbol parameter' but doesn't explain when to use it with or without the symbol, or when to choose other tools like get_exchange_rate for different price types. There's no context about prerequisites, timing, or sibling tool comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 explains the indicator's logic and historical timing (peak within ~3 days), but lacks critical behavioral details: whether it returns current status or historical data, data sources, update frequency, or error conditions. This is inadequate for a tool with zero annotation coverage.
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 a single, well-structured sentence that efficiently explains the indicator's methodology and historical context. It's front-loaded with the core purpose and avoids redundancy, though it could be slightly more concise by trimming 'historically typically'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 is incomplete. It explains the indicator's logic but omits essential context: what the tool returns (e.g., current crossover status, timestamps, confidence scores), data recency, or how to interpret results. For a financial indicator tool, this leaves significant gaps.
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 tool has 0 parameters with 100% schema coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information beyond the empty schema.
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 what the tool does: it uses the Pi Cycle Top indicator with specific moving averages (111DMA and 2x350DMA) to identify Bitcoin market tops. It specifies the resource (Bitcoin market tops) and mechanism (moving average crossovers), though it doesn't explicitly distinguish from siblings like 'get_cycle_indicators' or 'get_btc_trend'.
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 mentions the indicator's historical significance but doesn't specify use cases, prerequisites, or comparisons to sibling tools like 'get_cycle_indicators' or 'get_fear_greed_index' for market analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It describes the output fields but doesn't disclose critical traits like whether this is a read-only operation, data freshness, rate limits, authentication needs, or error handling. The description adds some context about included indicators but lacks operational transparency.
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 efficiently structured in two sentences: first stating the core function and output fields, second elaborating on scope. Every phrase adds value without redundancy. It could be slightly more front-loaded by leading with 'comprehensive analysis' but remains highly concise.
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 zero parameters and no output schema, the description adequately explains what the tool returns (indicators with specific fields and examples). However, as a data-fetching tool with no annotations, it should ideally mention behavioral aspects like data sources or update frequency to be fully complete for 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 tool has 0 parameters with 100% schema coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on output content. This meets the baseline expectation for parameterless tools.
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: 'Get crypto market cycle top indicators' with specific fields listed. It distinguishes from siblings by focusing on comprehensive market cycle analysis rather than individual indicators like 'get_pi_cycle_top' or 'get_puell_multiple'. However, it doesn't explicitly contrast with 'get_cycles' which might overlap.
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 mentions 'comprehensive market cycle analysis' but doesn't specify scenarios where this aggregated view is preferred over individual indicator tools like 'get_pi_cycle_top' or broader tools like 'get_cycles'. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify data sources, update frequency, rate limits, authentication requirements, or error conditions. This leaves significant gaps for a tool that likely queries external APIs.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple data retrieval tool and front-loads the essential 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?
For a single-parameter read tool with no output schema, the description adequately covers the basic purpose. However, without annotations or output details, it lacks information about return format (e.g., numeric values, timestamps, units) and behavioral constraints that would be helpful for reliable agent usage.
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?
The schema has 100% description coverage, with the 'symbol' parameter well-documented in the schema itself (including format, examples, and pattern). The description adds no additional parameter information beyond what's in the schema, meeting the baseline for high schema coverage.
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 action ('Get') and the resource ('token circulating supply and total supply information'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools that also retrieve token-related data (like get_token_price), which prevents a perfect score.
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 sibling tools like get_token_price that also retrieve token data, there's no indication of when supply information is preferred over price information or other metrics, leaving usage context ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool returns a chart with specific data points (price, active addresses, etc.) but doesn't mention whether this is a read-only operation, if there are rate limits, authentication requirements, data freshness, or error conditions. The description provides basic output format but lacks critical behavioral context.
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 with just two sentences that efficiently convey the core functionality and output format. Every word earns its place - the first sentence states what the tool does, and the second specifies the exact return format. No wasted words or unnecessary elaboration.
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 this is a parameterless tool with no output schema, the description provides the essential information about what data it returns and in what format. However, it lacks important context about data sources, update frequency, timezone considerations for dates, and how this differs from similar tools. For a financial data tool, more completeness would be beneficial.
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 tool has zero parameters (schema coverage 100%), so the baseline score is 4. The description appropriately doesn't discuss parameters since none exist, and it instead focuses on what the tool returns, which is reasonable given the parameterless nature of this tool.
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: 'Get BTC trend chart for the past 3 months.' It specifies the resource (BTC trend chart) and timeframe (past 3 months), but doesn't explicitly differentiate from sibling tools like 'get_eth_trend' or 'get_cycle_indicators' beyond mentioning BTC specifically.
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 like 'get_eth_trend' for Ethereum data or 'get_cycle_indicators' for broader market analysis, nor does it specify any prerequisites, constraints, or recommended contexts for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It only states what the tool does without mentioning any behavioral traits such as data freshness, rate limits, authentication needs, or response format. This is inadequate for a tool with no annotation coverage.
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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 low complexity (0 parameters, no annotations, no output schema), the description is minimally adequate but lacks depth. It does not explain return values or behavioral context, which could be important for financial data tools, leaving gaps in 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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description does not add parameter details, but since there are no parameters, a baseline of 4 is appropriate as no additional semantic information is needed.
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 action ('Get') and resource ('list of fiat currency exchange rates'), providing a specific purpose. However, it does not differentiate from sibling tools like 'get_token_price' or 'get_mini_24hr', which might also involve financial data, so it lacks sibling distinction.
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 sibling tools like 'get_token_price' and 'get_fear_greed_index' that might overlap in financial contexts, there is no explicit or implied context for usage, leaving the agent without direction.
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 describes the tool's function (providing real-time insights with charts and metrics) and data sources (top 100 altcoins vs Bitcoin over 90 days), but lacks details on rate limits, authentication needs, or potential data freshness issues. It doesn't contradict annotations, but could be more comprehensive for a tool with no annotation coverage.
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 a single, well-structured sentence that efficiently conveys the tool's purpose, data basis, and additional features (charts and metrics). It's front-loaded with the main function and avoids unnecessary details, though it could be slightly more concise by trimming phrases like 'for tracking market trends and altcoin dominance' which are somewhat redundant.
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 no annotations, no output schema, and 0 parameters, the description adequately covers the tool's purpose and data sources. However, it lacks information on return format (e.g., what the 'insights' or 'metrics' look like), which is important since there's no output schema. For a tool with no structured data support, more detail on behavioral aspects 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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose without redundant parameter info, earning a baseline score of 4 for zero-parameter tools.
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 provides real-time insights into whether the market is in Altcoin Season based on specific metrics (top 100 altcoins vs Bitcoin over 90 days). It specifies the resource (Altcoin Season Index page) and includes details about charts and metrics. However, it doesn't explicitly differentiate from siblings like 'get_bitcoin_dominance' or 'get_cycle_indicators' that might overlap in market analysis.
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 guidance on when to use this tool versus alternatives is provided. The description mentions tracking market trends and altcoin dominance, but doesn't specify scenarios where this tool is preferred over siblings like 'get_bitcoin_dominance' for dominance metrics or 'get_cycles' for cycle analysis. Usage is implied rather than clearly defined.
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 the output format ('Format: [[date, price, active addresses, new addresses]]'), which is useful behavioral context. However, it lacks details on data sources, update frequency, or potential limitations like 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 highly concise and front-loaded, consisting of two clear sentences: one stating the purpose and timeframe, and another specifying the output format. Every sentence adds essential information without redundancy.
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 simplicity (0 parameters, no annotations, no output schema), the description is adequate but has gaps. It explains what the tool returns but lacks context on data freshness, sources, or error handling. For a data-fetching tool, more behavioral transparency 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the output format, which aligns with the baseline expectation for zero-parameter tools.
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: 'Get the ETH trend chart for the past three months.' It specifies the resource (ETH trend chart) and timeframe (past three months), but does not explicitly differentiate from sibling tools like 'get_btc_trend' or 'get_cycle_indicators' beyond the ETH focus.
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. The description does not mention any prerequisites, exclusions, or comparisons to sibling tools such as 'get_btc_trend' for Bitcoin data or 'get_cycle_indicators' for broader market analysis.
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 describes the tool's function and parameter behavior (optional date with default to current month), but lacks details on rate limits, authentication needs, error handling, or response format. It provides basic operational context but misses deeper behavioral traits that would help an agent use it effectively.
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 appropriately sized and front-loaded, with the core purpose stated first. The bilingual format (English/Chinese) adds some redundancy but maintains clarity. Every sentence contributes essential information about the tool's function and parameter usage, with no wasted content.
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 (single optional parameter, no output schema, no annotations), the description is minimally complete. It covers the basic purpose and parameter behavior but lacks details on output format, error conditions, or integration context. For a data retrieval tool without structured output documentation, more guidance on what to expect would improve completeness.
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 100%, so the schema fully documents the single parameter. The description adds minimal value beyond the schema, only restating that the date is optional and defaults to the current month. Since there's only one parameter and the schema is comprehensive, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.
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: 'Get economic calendar for specified month. Shows important market or political events.' This specifies the verb ('Get'), resource ('economic calendar'), and scope ('market or political events'). However, it doesn't explicitly differentiate from sibling tools, which are all financial data tools but focus on different metrics like price indices, trends, or indicators rather than calendar events.
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 by specifying it retrieves an economic calendar with market/political events, but it doesn't provide explicit guidance on when to use this tool versus alternatives. No sibling tools appear to offer similar calendar functionality, so there's no direct alternative mentioned, leaving usage context somewhat implied rather than clearly defined.
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 describes the tool's purpose and interpretation of results (e.g., low/high values indicating market conditions), which adds context beyond basic functionality. However, it doesn't cover aspects like rate limits, error conditions, or data freshness, leaving gaps in behavioral understanding.
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 appropriately sized at four sentences, with the first sentence clearly stating the tool's purpose. Each sentence adds value: the first explains the calculation, the second its market reflection, the third interprets values, and the fourth provides insight perspective. It could be slightly more front-loaded by emphasizing the tool's action earlier.
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 complexity (a financial indicator with interpretive context), no annotations, and no output schema, the description is moderately complete. It explains what the tool calculates and how to interpret results, but it lacks details on output format, data sources, or potential limitations, which would be helpful for an AI agent to use it effectively.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't discuss parameters, which is appropriate here. It earns a baseline 4 because the schema fully covers the absence of parameters, and the description focuses on the tool's output interpretation instead.
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 what the tool does: 'assesses Bitcoin miners' revenue by dividing daily issuance (in USD) by its 365-day average.' It provides a specific verb ('assesses') and resource ('Bitcoin miners' revenue'), though it doesn't explicitly differentiate from sibling tools like 'get_cycle_indicators' or 'get_cycles' that might also relate to market cycles.
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 by explaining that low values indicate undervaluation/buy areas and high values indicate overvaluation/sell opportunities, which suggests when this tool might be useful for market analysis. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_fear_greed_index' or 'get_cycle_indicators', nor does it provide exclusions or prerequisites.
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:

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

Score Badge

Copy to your README.md:

[![cryptocurrency-mcp-server MCP server](https://glama.ai/mcp/servers/desk3/cryptocurrency-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/desk3/cryptocurrency-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/desk3/cryptocurrency-mcp-server'

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