AgentData MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools are clearly distinct, targeting specific data types. However, get_market_overview overlaps with get_sentiment, get_funding_rates, and get_arbitrage_opportunities, which could confuse agents looking for specific metrics. The descriptions help clarify that market_overview is a summary, but the overlap is notable.
Naming Consistency5/5
All 16 tools follow the consistent 'get_' prefix with descriptive snake_case names like get_crypto_prices, get_funding_rates, and get_technical_indicators. The pattern is perfectly uniform across the entire toolset.
Tool Count4/5
The server has 16 tools, which is just slightly above the typical 3-15 well-scoped range. Each tool serves a distinct data category, so the count feels justified, but the market_overview tool could arguably be consolidated to reduce redundancy.
Completeness5/5
The toolset covers a comprehensive range of crypto market data: prices, funding, volatility, correlation, liquidations, gas, network activity, yields, arbitrage, DEX/CEX spreads, technical indicators, support/resistance, sentiment, stablecoin health, and historical data. There are no obvious missing operations that would impede typical usage for a read-only data provider.
Average 3.9/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the cost of $0.005 USDC, which is a significant behavioral trait not obvious from the name. However, it omits other important behaviors such as rate limits, read-only confirmation, or possible errors. The cost disclosure is useful but incomplete.
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 one short sentence plus a cost note. It is front-loaded with the core purpose and omits fluff. Very efficient and easy to parse.
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?
Without annotations or an output schema, the description is the sole source of context. It covers what the tool does and its cost but leaves out parameter semantics, return structure, and usage examples. For a tool with three parameters, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fails to explain any of the three parameters (limit, symbol, interval). The word 'candles' hints at the data structure, but no parameter meaning is conveyed. The schema provides defaults and an enum, but the description adds no value in this area.
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 states the specific verb and resource: 'Get historical OHLCV candles' and adds the purpose 'for backtesting.' This clearly distinguishes it from sibling tools like get_crypto_prices (current prices) and get_technical_indicators (derived indicators).
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 phrase 'for backtesting' implies when to use the tool, but it does not explicitly mention alternatives or contexts where other tools should be used instead. No exclusions or comparisons to sibling tools are provided, so guidance remains implied rather than 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds useful context about the methodology, timeframe, and cost, but does not disclose return format, rate limits, or data freshness. The word 'Get' implies a read-only operation, but this is not explicit.
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 sentence front-loaded with the key action and resource, followed by the cost detail. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description provides enough context: it states the analysis method, timeframe, and cost. However, it could mention what the returned levels look like (e.g., arrays of support/resistance prices), but this is a minor gap given the tool's simplicity.
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 coverage is 100% for the single parameter 'symbol', and its minimum description 'Trading pair' is clear. The tool description adds no additional parameter semantics, but the schema already provides adequate meaning, so a baseline of 3 is appropriate.
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 uses a specific verb ('Get') with a clear resource ('support & resistance levels') and adds methodology ('via fractal analysis on 4h timeframe'), distinguishing this tool from siblings like get_technical_indicators or get_crypto_prices. No ambiguity about what the tool does.
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 does not state when to use this tool versus alternatives, nor does it mention any exclusions or conditions. It only states the cost and timeframe, leaving the agent without guidance on selecting this tool over the many sibling market data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the monetary cost ($0.002 USDC) and data source (DefiLlama), which is valuable. However, it omits other behavioral traits such as rate limits, response format, or explicit confirmation of read-only operation, leaving some uncertainty.
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, front-loaded sentence that states the purpose and cost with no wasted words. It is succinct 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?
The tool is simple with no parameters and no output schema. The description covers the core function and cost, but leaves ambiguity about what 'top' means, how many results are returned, and the structure of the response. Given the lack of annotations and output schema, more detail 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 no parameters, so schema coverage is trivially 100%. With 0 parameters, the baseline is 4, and the description correctly does not attempt to explain nonexistent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves top DeFi yield opportunities, naming specific protocols (Aave, Compound, Morpho, Pendle) via DefiLlama. It uses a specific verb and resource, distinguishing it from sibling tools like get_crypto_prices or get_funding_rates.
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 simply states what it does without mentioning appropriate use cases, exclusions, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries transparency burden. It discloses the monetary cost ($0.001 USDC) and indicates live monitoring, but does not reveal data freshness, update rates, what 'depeg check' entails, or the exact response structure.
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?
A single, front-loaded sentence that includes the core purpose and the cost. No wasted words; all information is relevant and immediately scannable.
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?
No output schema exists, so the description should clarify return values. It gives a high-level summary (peg status + top 10 list) but lacks details on how the data is presented, what 'health' metrics are included, or whether alerts are returned. Still adequate for basic selection.
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 and schema coverage is 100%, so no parameter explanation is needed. The description adds context by naming specific stablecoins (USDC, DAI) and the top-10 by market cap, going beyond the empty 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 a specific verb and resource: 'Get stablecoin peg monitoring' plus 'top 10 stablecoins by market cap.' It distinguishes itself from sibling market-data tools by focusing on stablecoin-specific health and depeg checks.
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. The cost and stablecoin focus imply a use case, but the description does not state exclusions or compare to siblings like get_crypto_prices or get_market_overview.
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, the description carries the burden. It discloses the cost ($0.001 USDC), which is a significant behavioral trait. However, it does not mention the return format, calculation details beyond the components, or any other behavioral aspects like rate limits or data freshness. Cost disclosure adds value, but the profile is not rich.
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, concise sentence that front-loads the core purpose and includes a separate cost note. Every word earns its place; there is no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read-only tool, the description covers the key aspects: what it returns (composite sentiment with components) and the cost. The lack of an output schema means agents won't know the exact response structure, but the description gives sufficient context for a simple getter. It falls short of 5 due to missing likely return format hints.
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, so the description cannot add parameter-level meaning. Per the baseline rule, 0 params scores 4. The description correctly makes no claims about parameters, keeping the focus on purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting composite market sentiment, and specifies the components (Fear & Greed Index, funding-based, composite score). It distinguishes itself from sibling tools by its focus on sentiment rather than raw prices or funding rates.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention scenarios like 'use for overall market mood' or exclude cases better served by get_funding_rates or get_market_overview. The cost note is informative but not usage 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?
No annotations are provided, so the description carries the full disclosure burden. It transparently mentions the cost ($0.002 USDC), which is critical behavioral information, and lists the indicators returned. However, it does not describe output format, error behavior, or rate limits, 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 extremely concise, with one sentence for purpose and one for cost. It omits any fluff and front-loads the core information, making it easy to scan. Every word earns its place.
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 simplicity (2 parameters, no output schema), the description includes the essential details: indicators, parameter scope, and cost. It lacks an explicit return structure, but the indicator list gives a reasonable expectation. The coverage is adequate for selection and basic invocation, though not exhaustive.
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 covers half of the parameters with descriptions (symbol), while interval has an enum but no description. The description adds generic context ('for a symbol/interval') but does not elaborate on parameter formats or enum constraints. Since the schema already provides the symbol example and interval options, the added value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it retrieves specific technical indicators (RSI, MACD, Bollinger Bands, ATR) for a given symbol and interval. This specificity distinguishes it from sibling tools like get_crypto_prices and get_funding_rates, which serve different data domains.
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 the tool is used when technical indicator data is needed, but it does not explicitly state when to prefer this over alternatives or mention any exclusions. It provides the context of symbol/interval but no direct comparison to sibling tools. This is adequate but lacks explicit guidance.
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 must fully disclose behavior. It only mentions the cost ($0.003 USDC) and the asset scope, but does not disclose read-only nature, rate limits, data sources, or any other behavioral traits. This is insufficient for a tool without annotation support.
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 one sentence combining the core function and the cost, with no unnecessary words. It is front-loaded with the action and resource.
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?
While the tool is simple and the description covers purpose and cost, the lack of an output schema means the agent must infer what 'spread analysis' includes. The description does not explain the return format or any limitations, so it is minimally complete but has 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 input schema has zero parameters, so the baseline is 4. The description adds context by specifying the assets (BTC/ETH/SOL) and the comparison nature, which helps the agent understand what the tool processes without needing parameter documentation.
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 specifies the verb 'Get' and the resource 'DEX aggregated prices vs CEX prices with spread analysis' for specific assets. This distinguishes it from sibling tools like get_crypto_prices (which are general prices) and get_arbitrage_opportunities (which focus on profitable differences).
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 a clear usage context: when you need to compare DEX and CEX prices or analyze spreads for BTC/ETH/SOL. It doesn't explicitly name alternatives or exclusions, but the specific scope provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a cost of $0.002 USDC, which is a valuable behavioral detail not captured elsewhere. However, it does not describe the response format, the scope of 'full', or any additional traits like rate limits. With no annotations provided, the description carries the full burden but only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two short sentences. The first sentence states the action and content, and the second provides cost information. There is no redundancy or unnecessary detail, making it well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool aggregates multiple market metrics, but the description only lists three components, while sibling tools suggest many more (prices, volatility, correlation, etc.). The term 'full' could be misleading. There is no output schema, so the description is the sole source for expectational completeness, and it lacks a preview of the return value or confirmation that it includes all other metrics.
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, so the description need not explain parameter usage. Baseline for zero parameters is 4, and the description adds no parameter-related semantics, which is appropriate given there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with the verb 'get' and the resource 'full market overview', then lists specific components (sentiment bias, arbitrage detection, funding yield). This distinguishes it from sibling tools that focus on individual metrics, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for obtaining a comprehensive snapshot but does not explicitly state when to prefer it over the sibling tools. It is named 'overview', which suggests aggregation, but there is no direct guidance on when to use this instead of, for example, get_sentiment or get_funding_rates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It does disclose a cost of $0.002 USDC, which is a unique behavioral trait, and outlines the specific data fields returned. However, it does not mention data freshness, latency, rate limits, or whether the data is historical or real-time, leaving some openness about behavioral characteristics.
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, well-structured sentence that front-loads the action and resource, then lists key specifics, and ends with a cost notice. Every word contributes value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description adequately covers the purpose, the key data points, and the associated cost. It is complete enough for an agent to select and invoke correctly, though a note about the data type (e.g., live vs. delayed) would have made it 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 tool has no parameters, so the description does not need to explain parameter meanings. As per the baseline for zero parameters, a score of 4 is appropriate. The description adds clarity about the tool's scope without needing to address parameter semantics.
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 a specific action ('Get') on a specific resource ('Base Mainnet network activity') and lists concrete data points (TPS, block stats, gas utilization). It distinguishes itself from sibling tools like get_gas_prices or get_market_overview by focusing on the Base network specifically.
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 its focus on Base Mainnet, but it does not explicitly state when to prefer this tool over alternatives or mention any exclusion conditions. There is no direct comparison to sibling tools or guidance on using it for Base-specific metrics versus other network metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the $0.001 USDC cost, which is a helpful behavioral trait, but does not mention authentication, rate limits, or return structure. More context could be added, but the fee disclosure is meaningful.
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 two short sentences, front-loaded with the core purpose and enriches it with the cost. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool, the description conveys the essential context: time range, asset pairs, and cost. No output schema is present, but the return value is adequately described as a correlation matrix. Slightly more guidance on when to use it would improve contextual 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 zero parameters and the schema is empty, so no parameter documentation is needed. The baseline for 0-parameter tools is 4, and the description does not need to compensate for missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a 30-day price correlation matrix for specific pairs (ETH/BTC, SOL/BTC, SOL/ETH), using a specific verb and resource. This distinguishes it from sibling tools like get_volatility or get_technical_indicators.
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 when a correlation matrix is needed, but does not explicitly state when to prefer this over alternatives or provide exclusions. The cost is mentioned, but no when-to-use or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the $0.001 USDC cost, a non-obvious behavioral trait, and indicates the output includes long/short signals. However, it does not mention data source, refresh interval, or response structure, leaving gaps in transparency given no annotations exist.
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?
Two concise sentences front-load the core function and follow with cost. No redundant or irrelevant content.
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 zero-parameter tool, the description covers asset scope and signal type. It could provide more detail on the response format or what 'long/short signals' exactly contain, but it's functionally sufficient for selection.
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 accepts zero parameters, so schema covers all. The description adds no parameter semantics, but none are needed; baseline of 4 applies per rubric.
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 verb 'Get' and resource 'perpetual futures funding rates' clearly specify the tool's function. The mention of BTC/ETH/SOL and long/short signals differentiates it from sibling market data tools.
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 use for funding rate queries but provides no explicit comparison to siblings like get_crypto_prices or get_volatility. There are no when/when-not statements, so guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the cost ($0.002 USDC) and the 'estimated' nature of the data, which are useful behavioral traits. However, it does not mention rate limits, response format, or other potential side effects, and no annotations are provided to cover these.
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, compact sentence that conveys all essential information (what, for which leverage and assets, and cost) without any wasteful words. It is front-loaded with the core action and resource.
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 simplicity (no parameters, no output schema, no annotations), the description covers the main aspects: the type of data, the supported assets and leverage levels, and the cost. It lacks explicit return structure but is otherwise complete for the complexity level.
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, so the schema is fully covered and no additional parameter explanation is needed. The baseline for 0 params is 4, and the description appropriately focuses on the output scope rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets estimated liquidation zones, specifying leverage levels (5x/10x/20x) and assets (BTC/ETH/SOL). This distinguishes it from sibling tools like get_crypto_prices or get_funding_rates, which serve different purposes.
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: when you need liquidation estimates for BTC/ETH/SOL at certain leverage levels. However, it does not explicitly mention when to use this tool over others or any exclusions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It discloses a $0.001 USDC cost and limits data to BTC/ETH/SOL over 24h. However, it does not explicitly state whether the operation is read-only, side-effect-free, or any rate limits. The cost disclosure adds some transparency, but the description remains incomplete for full behavioral clarity.
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 sentence with no filler. It conveys the purpose, scope, and cost efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential information: what it returns, for which assets, and the cost. However, it lacks an output schema and does not describe the response format. Given the simplicity of the tool, this is acceptable but not exhaustive, so a score of 4 is appropriate.
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 zero parameters, so the description does not need to elaborate on parameters. The baseline for 0-parameter tools is 4, and the description appropriately omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 24h volatility, range, and annualized volatility for BTC/ETH/SOL. This is a specific verb ('Get') and resource, and it is distinct from sibling tools like get_crypto_prices or get_funding_rates, none of which mention volatility.
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 does not explicitly specify when to use this tool versus alternatives, nor does it name exclusions. However, the asset scope and metric are clear, implying it is for volatility data. No alternative tools are mentioned, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses a significant behavioral trait: 'Costs $0.003 USDC.' However, it does not elaborate on output format, latency, or other nuances, though the 'get' nature implies read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose, and the cost note is a concise single sentence. 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 parameterless get tool with no output schema, the description is adequately complete: it identifies the exchanges and the cost. It could be improved by noting the output type (e.g., list of opportunities), but given the simplicity, it is 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?
The input schema is empty (0 parameters), so the baseline is 4. The description correctly does not need to explain parameters, as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get cross-exchange arbitrage opportunities between MEXC, Binance, Bybit, OKX.' It specifies the verb (Get), the resource (cross-exchange arbitrage opportunities), and the scope (specific exchanges), distinguishing it from sibling tools like get_crypto_prices or get_funding_rates.
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 the use case (detecting arbitrage opportunities) but does not explicitly contrast with alternative tools or state when to prefer this over others. The mention of specific exchanges provides context, but no exclusions or alternative guidance are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds value by disclosing the $0.001 USDC cost, which is a non-obvious behavioral trait. It does not detail response format or potential side effects, but for a simple getter this is reasonably transparent.
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?
Two short sentences, front-loaded with the main purpose. 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?
Despite no output schema, the description covers what the tool does, the assets involved, and the cost. It could mention the unit of gas prices (e.g., gwei) or data freshness, but for a simple 0-param tool it is largely complete.
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, so the description inherently covers the parameter semantics. Baseline of 4 applies.
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 uses a specific verb ('Get') and clearly identifies the resource ('current gas prices for Base, Ethereum, Solana with USD cost estimation'). This distinguishes it from sibling tools like get_crypto_prices, which presumably return crypto asset prices.
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?
It indicates the scope (Base, Ethereum, Solana) but does not explicitly state when to choose this over alternatives or any exclusions. The cost disclaimer provides some context but not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It adds the crucial detail of a $0.001 USDC cost, which is not obvious from the name. However, it does not describe the return format, pagination, or any potential rate limits, which could be relevant for an agent invoking the 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 two concise sentences: one stating the function, the other stating the cost. It is front-loaded with the core purpose and contains no filler or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and a simple action, the description is complete: it states what it does and the cost. No output schema exists, but the tool's simple nature and clear purpose make the return value predictable. The description is sufficient for an agent to select and invoke the tool correctly.
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, and the schema has 100% coverage (i.e., no parameters to describe). The description mentions the specific assets, which serves as a pseudo-parameter hint, but since there are no actual parameters, the baseline of 4 applies per the rubric.
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 explicitly states the tool fetches real-time prices for a specific set of cryptocurrencies (BTC, ETH, SOL, BNB, XRP). The verb 'Get' and the resource 'crypto prices' are clearly defined, and the asset list differentiates it from sibling tools like get_funding_rates or get_volatility.
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 asset list provides clear context for when to use this tool: when real-time prices for these specific coins are needed. It does not explicitly mention alternatives or exclusions, but the high specificity makes the usage unambiguous. The cost disclosure adds an important consideration, though no explicit 'when not to use' is stated.
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:

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

Score Badge

Copy to your README.md:

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

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