Wicked API - Agent First API Services

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct financial data type or source (e.g., ATR, FVG, basis, earnings calendar, Kalshi probability vs. market depth). No two tools serve the same purpose, and descriptions clearly delineate their outputs.
Naming Consistency5/5
All tool names use lowercase snake_case with a consistent pattern of single nouns or verb_noun phrases (e.g., 'price', 'earnings_calendar', 'long_short_ratio'). No mixed naming conventions.
Tool Count4/5
22 tools is slightly above the ideal range, but the wide scope of financial data (crypto, equities, macro, derivatives) justifies the count. Each tool adds distinct value without excessive redundancy.
Completeness3/5
The set covers a broad range of financial data (technical, fundamental, macro, sentiment, prediction markets) but lacks fundamental stock data (e.g., financials, dividends), forex, or commodities, leaving notable gaps for a comprehensive financial API.
Average 3.2/5 across 22 of 22 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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?
No annotations exist, so the description bears full responsibility. It only mentions the data source and gives an example, but does not disclose behavioral traits like side effects, auth needs, rate limits, or error behavior.
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 contains two identical sentences, which is redundant. The example is useful, but the repetition wastes space and reduces conciseness.
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 4 optional parameters and no output schema, the description is minimal. It does not explain how the view parameter selects data type, nor does it mention the chain, limit, or project parameters. Incomplete for practical use.
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% with descriptions for all parameters. The description adds no extra meaning beyond the schema; it repeats high-level data types but does not elaborate on parameters.
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 it provides DefiLlama data for TVL, stablecoin supply, and yields, with an example URL. However, it does not differentiate from sibling tools, many of which are unrelated to DeFi.
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 on when to use this tool versus alternatives. The description implies it is for DeFi data, but no explicit context, prerequisites, or exclusions are provided.
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 orderbook and trades but does not mention rate limits, authentication needs, read-only nature, or any side effects. The behavioral picture is incomplete for an agent to safely invoke this tool.
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 repeats the same sentence verbatim, wasting space. The example is useful but not enough to compensate for the redundancy. The description could be more streamlined.
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 absence of an output schema, the description should explain the structure of the returned data (e.g., orderbook levels, trade fields). It does not provide this information, leaving an agent uncertain about how to handle the output. The tool's complexity is moderate but the description is insufficient.
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?
All three parameters are described in the input schema (100% coverage). The description does not add significant new semantics beyond the schema, but the included example clarifies the expected format for the ticker parameter. The schema already provides adequate parameter definitions.
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 it returns orderbook depth and recent trades for a specific Kalshi market ticker. It provides a concrete example URL. However, it does not explicitly differentiate from sibling tools like 'kalshi_probability' or 'orderbook', leaving ambiguity about when to use this tool over others.
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 lacks any guidance on when to use this tool versus alternatives. No context is given about prerequisites, preferred use cases, or situations where this tool is not appropriate. The example helps with syntax but not decision-making.
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 cover behavioral aspects. It mentions running on a separate Python service, but fails to disclose read-only nature, rate limits, data freshness, or error conditions. This leaves the agent guessing about side effects and reliability.
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 repetitive, containing the same sentence twice. It could be condensed without losing information. The example at the end is helpful but the overall structure wastes words.
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?
No output schema exists, so the description should explain the return format. It lists components (bias, confidence, etc.) but does not describe structure, field types, or how the data is presented. This is insufficient for an agent to fully understand what to expect.
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%, with clear descriptions for 'symbol' (list of assets) and 'timeframe' (optional with default). The description adds no significant extra meaning beyond the schema, so baseline 3 is appropriate.
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 it provides a 'multi-asset momentum verdict' with components like bias, confidence, thesis, entry/invalidation/targets, and signal readings. It also mentions the pipeline and scoping to 10 assets, which differentiates it from siblings like 'sentiment' or 'price'.
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 siblings. The only hint is scoping to 10 assets, but it does not explain when momentum analysis is appropriate or when alternatives like 'sentiment' might be better.
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 present, so the description must disclose behavioral traits. While it identifies the data source (FRED), it omits details such as read-only nature, data freshness, rate limits, or any potential side effects. This leaves the agent uninformed about operational characteristics.
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 contains a redundant repetition of the same sentence, making it inefficient. The example line adds some value but overall the structure wastes space without additional informative content.
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?
The tool has no output schema, so the description should explain the response format or structure. It only mentions yields and spreads but fails to describe what the output looks like (e.g., object with keys, units). This lack of completeness hinders the agent's understanding of the tool's result.
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 100% of parameters with a description for 'series', so a baseline of 3 is appropriate. The description does not add additional meaning or context beyond the schema, such as default behavior or how the parameter affects the output.
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 specifies the tool provides US Treasury yield curve data and recession-indicator spreads from FRED, with explicit time ranges and spread types. The purpose is well-defined, though it lacks an explicit verb like 'get' or 'fetch' and does not differentiate from siblings, which are all distinct tools.
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, nor any preconditions or exclusions. The description merely states what the tool does without contextual usage advice.
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, the description must fully disclose behavioral traits. It fails to mention that this is a read-only operation, any rate limits, data source constraints, or update frequency. The example shows endpoint format but lacks behavioral details.
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 short but has redundancy (first sentence repeated). It is front-loaded with the purpose. Could be more concise by removing the duplicate sentence.
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?
No output schema exists, so the description should describe return structure. It lists types of ratios but does not explain the format or fields. The tool is simple but for completeness, more detail on output is needed.
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%, so parameter details are already in the schema. The description adds the example URL and implies the mapping of symbol to USDT, but no additional meaning beyond schema. Baseline 3 is appropriate.
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 it provides Binance long/short ratios (global, top-trader, position, taker buy/sell). It mentions being a companion to funding-oi, which helps distinguish from siblings. However, the purpose verb is implicit (fetch/get), and there is redundancy in the description.
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 mention of 'Companion to funding-oi' hints at context but does not provide when-not or alternative tool comparisons. Siblings like sentiment or price are not contrasted.
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 carry the burden of behavioral disclosure. It mentions the data source (CoinGecko) but does not state that it is a read-only operation, any auth requirements, or rate limits. The safe read nature is implied but 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is repetitive, with the same sentence appearing twice. It includes an example that is merely the endpoint path, which adds little value. It could be more concise and structured.
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 (two optional params, no output schema, no annotations), the description covers the two views adequately. However, it lacks behavioral context and usage guidance, making it minimally complete.
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%, so the description adds marginal value. It clarifies the 'view' values ('global' vs 'coins') and that 'limit' applies to the coins view, but the schema already describes these. No new semantics beyond what the schema provides.
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 it provides 'global crypto stats' or 'top coins by market cap' from CoinGecko, giving a specific verb+resource. However, it does not differentiate from sibling tools like 'price' or 'market_clock', which also provide market-wide 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?
No guidance on when to use this tool versus alternatives. It does not specify use cases, prerequisites, or exclusions, leaving the agent to infer context from the tool name alone.
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, the description carries the full burden of behavioral disclosure. It mentions 'Not geo-blocked', which is a useful constraint, but does not address other behavioral aspects such as rate limits, idempotency, or data freshness. The description mainly lists the returned data rather than behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains a repeated sentence, which reduces conciseness. The inclusion of an example URL is useful and front-loaded. Overall, it could be more efficient by removing the repetition.
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 has one parameter and no output schema, the description adequately lists the return data (funding, open interest, prices, premium, volume). This provides sufficient context for an agent to understand the output. However, lacking an output schema, it could be more precise about data types or format, but the list is clear enough.
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%, so baseline is 3. The description adds context by listing the data fields returned for the symbol, but this is complimentary rather than essential. The schema already describes the parameter as a coin name, and the description's example (BTC) aligns with that. No additional constraints or format details are provided.
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 Hyperliquid perpetual context data including funding, open interest, prices, premium, and volume. It specifies the resource (Hyperliquid) and the data fields, though it lacks an explicit verb like 'get' or 'retrieve'. It does not explicitly distinguish from sibling tools like funding_oi, but the focus on Hyperliquid exchange provides some differentiation.
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 given on when to use this tool versus alternatives such as funding_oi or price. The description only states what the tool does without any context on preferred use cases or exclusions. The example URL hints at usage but does not provide decision-making criteria.
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, the description carries full burden. It mentions output concepts (e.g., 'resting only' via include_swept) but does not disclose data freshness, update frequency, rate limits, or any side effects. Behavioral traits are not addressed.
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 short but contains a redundant repetition of the first sentence. It is front-loaded but wastes space. Could be more concise without the duplication.
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 6 parameters and no output schema, the description provides a high-level overview of output concepts but no details on return format or structure. Completeness is adequate but not thorough.
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%, so baseline is 3. The description does not elaborate on parameters beyond what the schema already provides. The example shows usage but adds no new semantic meaning.
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 ICT liquidity levels, including buy/sell-side liquidity, sweep status, and pools. It names specific outputs and gives an example, but does not explicitly differentiate from sibling tools like 'fvg' or 'orderbook'.
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 on when to use this tool versus alternatives. The description provides an example URL but no conditions, prerequisites, or comparisons to siblings. The agent must infer use context.
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, the description carries full burden. It discloses ordering (oldest-first) and routing destinations, but fails to mention whether the tool is read-only, rate limits, authentication needs, or error conditions. This is minimal for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains a repetition ('OHLCV candles (oldest-first) for crypto or stocks' appears twice with a dash). The example line is useful. Some editing would improve conciseness.
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 output schema and many sibling tools, the description is insufficient. It does not explain the output format (e.g., fields like open, high, low, close, volume), pagination, or typical use cases. The agent would lack crucial context for correct invocation.
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%, so baseline is 3. The description adds no additional parameter details beyond the schema; it only provides an example query. The schema already explains all parameters adequately.
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 it returns OHLCV candles for crypto or stocks, with oldest-first ordering. It identifies the resource and verb, but does not explicitly distinguish it from sibling tools like 'price' or 'atr', though context implies it's for historical candle data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions routing to Alpaca SIP, Alpaca-crypto, and Coinbase, implying coverage for multiple asset classes, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it state any exclusions or prerequisites.
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, the description carries full burden. It only states the tool returns depth and spread but does not disclose that it is read-only, snapshot nature, rate limits, or data freshness. 'Top-of-book' is a hint but insufficient.
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 short but contains a redundant repetition of the same sentence. An example URL is provided, which adds value, but the duplication wastes space.
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?
No output schema is provided, so the description should explain the output structure. It only mentions depth and spread in bps, but not fields like bid/ask, sizes, or format. For a complex tool, this is insufficient.
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%, so the schema already documents all parameters. The description adds no additional meaning beyond the schema, just repeats the general purpose. Baseline 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 clearly states the tool returns top-of-book depth and spread from specific exchanges (Binance, Bybit, Hyperliquid). It distinguishes itself from over 20 sibling tools by being specific to order book 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?
No guidance on when to use this tool vs alternatives, when not to use it, or how to choose between exchanges. The example and parameter descriptions only imply basic 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 bears full burden. It mentions output attributes (gap size, age, fill status) but doesn't explain CE, data freshness, rate limits, or side effects. The description lacks sufficient disclosure for a trading data tool.
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 short and includes an example, but the first sentence is repeated verbatim, causing unnecessary redundancy. It could be more concise by removing the duplicate.
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 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the return format, how to interpret FVG zones, or the meaning of attributes like age and fill status. The example is helpful but insufficient.
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%, so the schema already documents parameters. The description adds context via the example but does not explain parameter interactions or provide meaning beyond the schema. 'CE (50%)' is mentioned but not linked to any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides Fair Value Gap zones with specific attributes (CE 50%, gap size, age, fill status, distance from price) and uses a standard ICT/LuxAlgo approach. It distinguishes from siblings by being the only tool for FVG zones.
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 gives an example and mentions 'Crypto or stocks' and 'Standard timeframes match TradingView candles,' but does not explicitly say when to use this tool vs alternatives like other indicators. No exclusions or when-not-to-use 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 carries full burden. It does not disclose behavioral traits such as read-only nature, data freshness, authentication needs, or side effects. Only describes the computation, not the tool's behavior.
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 short (3 sentences + example) and front-loaded with key information. However, the first sentence contains a redundant repetition of the same phrase, slightly reducing conciseness.
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?
With no output schema, the description should explain return values but only mentions 'volatility-regime classification' without detailing output structure. For a 4-parameter tool, more context on what the response contains is needed for effective 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 input schema has 100% description coverage for all 4 parameters. The description adds an example URL illustrating usage, but does not provide additional semantic meaning beyond what the schema already states (e.g., format constraints, default values). Baseline 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 clearly states the tool computes Average True Range (Wilder's) and adds volatility-regime classification by historical percentile. It includes an example and mentions applicability to crypto or stocks, making the purpose distinct from sibling tools like 'volatility' or 'fvg'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ATR and regime classification, but does not explicitly state when to use this tool versus alternatives (e.g., 'volatility' or 'momentum_score'). No guidance on when not to use it or prerequisites.
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 data sources (Coinbase spot, Binance+Bybit perp) and mentions funding-implied carry, but lacks details on calculation, data freshness, rate limits, or error handling. With no annotations, the description carries the burden but only provides basic transparency.
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 partially repetitive, stating the same phrase twice. The example is a helpful addition. Overall, it could be more concise without losing information, but it is not overly verbose.
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 moderately complex (financial metric), but no output schema is provided. The description explains inputs and purpose but does not describe output format, units, or examples of return values. Missing details for a complete understanding.
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% with a single parameter 'symbol' described as 'Base crypto symbol (e.g. BTC)'. The description adds an example using 'BTC' but does not provide additional semantic context beyond the schema. Baseline score is appropriate.
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 computes spot-vs-perp basis (premium %) and funding-implied annualized carry, with specific data sources. While the purpose is clear, it does not explicitly differentiate from sibling tools like funding_oi or market_overview, which could cover similar concepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for crypto basis calculation via example, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to use basis vs funding_oi). No when-not-to-use or prerequisite information 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?
No annotations provided, so description bears full burden. It mentions 'via Alpaca' implying external dependency, and states crypto is 24/7, but does not disclose authentication needs, rate limits, or any side effects. Adequate but 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains a redundant sentence (first sentence repeated). The example adds value but could be integrated. Some waste, but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description adequately explains the output (is_open, next_open/close, upcoming sessions). It covers the essential behavioral 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?
Schema covers 100% of the single optional parameter 'days'. The description does not add any meaning beyond the schema's own description. Baseline 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 clearly states it provides a US equities market clock with open/close times and upcoming sessions. It distinguishes from siblings by specifying it's a clock, not price/volume data. The repeated sentence reinforces the purpose.
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. Since there is no sibling clock tool, the need is lower, but the description still lacks usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the data source and what is returned, but lacks information on rate limits, authentication, or error handling.
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 repeated twice, wasting space. It is otherwise concise and includes an example, but could be streamlined.
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 provided, and the description does not specify the output structure (JSON object, array, etc.). For a simple tool this is adequate but incomplete.
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?
No parameters exist (schema coverage 100%), so description must provide all meaning. It explains the output (gas prices, base fee) sufficiently for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an Ethereum gas oracle providing safe, propose, fast gas prices and base fee in gwei via Etherscan. This is specific and distinct from siblings like price or sentiment.
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 on when to use this tool versus alternatives like price or sentiment. No context about use cases like transaction preparedness.
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 correctly indicates it returns event data with odds, but does not disclose whether it is read-only or any side effects, though it is likely safe.
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 contains a duplicated sentence and extra whitespace, making it less concise; it could be trimmed to a single clear statement.
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 two optional parameters and no output schema, the description adequately explains the returned data (events, dates, days-until, odds) and provides an example endpoint, leaving little ambiguity.
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 input schema already describes both parameters fully (100% coverage), and the description adds no additional meaning or usage guidance beyond the 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 explicitly states it provides upcoming US macro events (FOMC, CPI, jobs report) with specific data like verified dates and Kalshi odds, clearly distinguishing it from sibling calendar tools like earnings_calendar.
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 usage context is implied by mentioning event types, but it does not explicitly tell the agent when to use this tool versus alternative calendar tools or what conditions to avoid.
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 only states basic function. It does not disclose potential rate limits from alternative.me, authentication needs, or behavior for missing data. The example only shows a parameter usage.
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 short but contains unnecessary repetition (the same sentence appears twice). The example is helpful. Removing the duplication would improve conciseness without losing 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?
For a simple tool with one optional parameter and no output schema, the description covers the input well but omits details about the response format (e.g., what 'current reading' and 'history' look like). It is adequate but not 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 schema already describes the 'limit' parameter with default and max, achieving 100% coverage. The description adds value by providing a concrete example (limit=7) that aids understanding of how to request history.
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 identifies the tool as providing the Crypto Fear & Greed Index from alternative.me, with current reading and optional history. The verb 'get' is implied, and the resource is distinct from siblings like 'momentum_score' or '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 implies usage for crypto sentiment queries but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are named, and usage context is only implied by the example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It accurately states the output includes two volatility metrics, but does not disclose rate limits, authentication needs, or data freshness. Adequate but minimal.
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?
Short and front-loaded, but the first sentence is duplicated. Removing the duplicate would make it more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description explains the output (DVOL index and realized volatility) and provides an example. Nearly complete, though missing return format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single parameter with a clear description. The tool description adds no new info beyond "for BTC or ETH," already in the schema. Baseline 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 clearly states the tool returns Deribit volatility data (DVOL implied-vol index and realized volatility) for BTC or ETH, with a specific verb and resource, distinguishing 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like price, ohlcv, or funding_oi. The description does not mention scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that category queries return 'the most active open markets', providing useful behavioral context. However, with no annotations, the description could further disclose details like data freshness or pagination limits to fully compensate.
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 short (two sentences plus example) and reasonably front-loaded, but the first sentence repeats the tool name inefficiently. For a low-complexity tool, it is acceptable and earns its place.
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 output schema, the description omits return value format or probability interpretation. It adequately introduces two query modes but lacks details on response structure, which is needed for full 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 coverage is 100% with adequate descriptions. The description adds an example URL and implies category returns active markets, but does not enhance parameter meaning beyond the schema, such as the format of the ticker or the default limit behavior.
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 returns prediction-market probabilities and specifies two query modes: by category or specific ticker. However, it repeats the opening phrase and does not explicitly distinguish from sibling tools like kalshi_market, which may offer more detailed market information.
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 outlines two usage modes (category or ticker) but does not provide guidance on when to use this tool versus alternatives such as kalshi_market. No when-not-to-use or prerequisite information is given, leaving the agent without clear decision criteria.
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 provides some behavioral context: it is sourced live from Nasdaq's public calendar, and focuses on US equities. However, it omits details like rate limits, authentication needs, data freshness guarantees, or error scenarios.
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 repetitive (first sentence duplicated) and could be more streamlined. The key information is present, but the duplication wastes space.
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 3 optional parameters and no output schema, the description lists the return fields (report date, timing, EPS estimates, etc.) and source, partly compensating for missing output schema. It is sufficiently complete for a data retrieval tool with no required params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds value by providing a concrete example (date and days usage) that clarifies parameter interaction beyond what the schema states.
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 'US equity earnings announcement calendar' and lists the data fields provided (report date, timing, EPS estimates, market cap, etc.). This immediately distinguishes it from sibling tools like price, sentiment, or macro_calendar, 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 for US equity earnings, but does not explicitly specify when to use this tool versus alternatives (e.g., macro_calendar for economic events, price for stock data). No 'when not to use' or alternative tool mentions.
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 must cover behavioral traits. It states the tool fetches a spot price, implying a read-only operation. However, it does not mention data freshness, rate limits, or any side effects. The nature is benign, but transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, but the first sentence is repeated verbatim, which is redundant. The example is helpful. Could be more concise without the repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides an example URL but no return format. For a simple price tool, the description is mostly complete. Sibling tools are not referenced, but the purpose is clear enough for an agent to choose correctly.
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% (both parameters have descriptions). The description adds context about data sources (Coinbase, Alpaca SIP) which elaborates on the 'class' parameter. It does not add substantial meaning beyond the schema, so baseline 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?
Clearly identifies the tool as providing current spot price for crypto (Coinbase) or US equities/ETFs (Alpaca SIP). The verb 'get' is implied, and the resource is specified as price data. The description distinguishes it from siblings like ohlcv or orderbook by focusing on spot price.
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 indicates when to use: for a current spot price of a given symbol. It gives an example query. However, it doesn't explicitly state when not to use or compare to alternatives like ohlcv or basis, but the context of siblings makes the purpose clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses the two exchange sources, the metrics computed (7-day avg funding, 24h OI change, bias signal), and implies it is a read-only aggregation. However, it does not mention authentication requirements, rate limits, or whether it returns current or historical data, which would be helpful.
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 concise with a single sentence and an example. However, the first sentence is duplicated verbatim, which is unnecessary and slightly wasteful. The example is clear and helpful.
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 (one parameter, no output schema), the description adequately explains what the tool returns (funding rate, OI, averages, bias) and data sources. It does not specify time ranges or data freshness, but the metrics imply historical and current context. Overall sufficient for the complexity level.
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 input schema has 100% description coverage for the single parameter 'symbol', including an example mapping to USDT perpetual tickers. The description does not add further semantics beyond the schema, so baseline 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 clearly states the tool provides aggregated perpetual-futures funding rate and open interest from Binance and Bybit, including specific metrics like 7-day average funding and long/short bias signal. It uses a specific verb ('aggregated') and resource, distinguishing it from sibling tools like 'long_short_ratio' or 'basis'.
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 gives an example usage with symbol parameter, but does not explain when to use this tool over alternatives (e.g., when needing funding/oi vs. spot price or basis). No when-not-to-use or prerequisite information is provided, leaving the agent to infer from context.
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:

[![WickedAPI_MCP MCP server](https://glama.ai/mcp/servers/choaticpixels/WickedAPI_MCP/badges/card.svg)](https://glama.ai/mcp/servers/choaticpixels/WickedAPI_MCP)

Score Badge

Copy to your README.md:

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

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