Read-only perp futures data: all-in trading cost, venue fees, funding rates and volume ranking
Scored across 5 tools
Each tool targets a distinct aspect of perp venue discovery: cost (cheapest venue), funding rates, access restrictions, fees, and volume ranking. There is no overlap; an agent can clearly choose the right tool for a specific query.
All five tools follow a consistent get_<descriptive_noun> pattern in snake_case. The verbs are uniform (get) and the nouns clearly indicate the data returned, making the naming predictable and easy to follow.
Five tools is well-scoped for a specialized perp-finder server. Each tool covers a key dimension (cost, funding, access, fees, volume) without redundancy or excessive granularity, and the count is neither too thin nor too heavy.
The tool surface comprehensively covers the core domain of finding and comparing perp venues. It provides essential data for decision-making: cost, funding, regulatory access, fee structure, and volume. No obvious gaps exist for the stated purpose; all major user intents are addressable.
Venues ranked by measured all-in cost (taker fee + half-spread + price impact) of a perp market buy at the base fee tier, from the newest stored 6-hour order-book sweep. Rows that cannot fill or have unconfirmed depth are listed apart, with the reason.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Order size in USD. Default 10000. | |
| asset | Yes | Base asset. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description goes beyond annotations by disclosing the measurement basis ('base fee tier'), the temporal scope ('newest stored 6-hour sweep'), and the handling of unconfirmable rows ('Rows that cannot fill or have unconfirmed depth are listed apart, with the reason'). This adds meaningful transparency about output structure and edge cases, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose and metric, and wastes no words. It packs essential context (data source, edge-case handling) into a compact form, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description conveys that the result is a ranked list of venues separated by fill-ability status, which implies the output structure. It does not mention pagination, result count, or whether costs are shown as numbers, but for a simple ranking tool this is sufficient. The absence of an output schema places more burden on the description to hint at returns, which it does adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters (asset, size) have descriptive enums and inline descriptions. The tool description does not add any parameter-specific meaning beyond the schema; it focuses on the tool's overall behavior. Given the high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('ranked'), resource ('venues'), and precisely defines the ranking metric ('measured all-in cost (taker fee + half-spread + price impact) of a perp market buy'). It also clarifies the data source ('newest stored 6-hour order-book sweep') and the handling of invalid rows, which clearly differentiates it from siblings like get_venue_fees (fees only), get_funding (funding), and get_volume_ranking (volume).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing venue costs on a perp market order, and the cost components are explicit. However, it does not explicitly state when not to use it or name alternative tools, though the sibling tools are clearly different in scope. The context is clear enough that an agent can infer appropriate usage, but it stops short of explicit disambiguation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current perpetual funding rate of one asset on each venue that lists it, normalized to a 1-hour rate, with the venue interval, open interest and price. Rates are fractions: 0.0001 is 0.01%.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Asset symbol, for example BTC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate the tool is read-only, idempotent, and non-destructive, so the description only needs to add behavioral context beyond safety. It does this by specifying that rates are normalized to a 1-hour rate, that venue interval/open interest/price are included, and that rates are expressed as fractions—useful details that prevent misinterpretation of the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the operation, scope, and output components, while the second clarifies the rate unit convention. Every sentence earns its place and the tool's purpose is immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool, the description is largely complete: it identifies the input, the per-venue scope, the normalization, and the main output fields. The absence of an output schema is partially mitigated by listing open interest and price, though the exact response structure or venue identifiers are not specified. This is adequate for a simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, asset, is fully documented in the input schema with a pattern and example, so schema coverage is 100%. The description adds no extra semantic information about the asset parameter beyond the word 'one asset,' which is already reflected in the title and description. Baseline 3 is appropriate because the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation—retrieving the current perpetual funding rate for one asset—and a clear resource scope: each venue that lists the asset. It also names the key returned components (rate, interval, open interest, price), making it easy to identify what this tool does and how it differs from sibling tools that focus on fees, access, or volume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context: use this tool when you need current funding rates for one asset across venues. However, it does not explicitly mention when to prefer an alternative such as get_cheapest_venue or get_venue_fees, nor does it state any exclusions or conditions for not using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For one jurisdiction, what each venue and the local regulator publish about perp access: yes, restricted, unclear or no, with the basis and the sources a person opened. Not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Jurisdiction code (us, uk, eu, ca, au, sg, no) or name, for example Norway or United Kingdom. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful context by explaining that the tool reports what venues and regulators publish, enumerates possible status values (yes, restricted, unclear, no), and includes the disclaimer 'Not legal advice.' No contradiction with annotations was found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core behavior, followed by a useful disclaimer. No filler or redundant restatement of the tool name or schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool with no output schema, the description adequately conveys the returned information: status category, basis, and sources. The phrasing 'sources a person opened' is unclear and could confuse an agent, and unsupported-country behavior is not mentioned, but the overall context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single 'country' parameter with allowed codes and examples, so the description need not repeat that. The phrase 'For one jurisdiction' reinforces the parameter's purpose, but the description adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: for one jurisdiction, report what venues and regulators publish about perp access, with answer categories and supporting sources. It distinguishes itself from sibling tools about fees, funding, volume, and cheapest venue. Minor ambiguity in the phrase 'the sources a person opened' and the unexplained abbreviation 'perp' keep it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'For one jurisdiction' implies the tool is used when you need access information for a single country, and the country parameter is obvious. However, the description gives no explicit guidance about when to prefer this tool over the listed siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Base maker and taker rates, the volume fee ladder, leverage and funding terms of one perp venue, each with its source and check date, plus the measured all-in cost of BTC and ETH market buys.
| Name | Required | Description | Default |
|---|---|---|---|
| venue | Yes | Venue slug, for example hyperliquid or binance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds valuable context about data provenance ('each with its source and check date') and measurement ('measured all-in cost'), which informs the agent about data freshness and methodology. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense sentence that front-loads the core content ('Base maker and taker rates') and lists all returned components efficiently. No filler or repetition; every element earns its place. Slightly long but appropriately packed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with one parameter and no output schema, the description covers the main return items comprehensively. It doesn't specify numeric formats or error behavior, but the list of data elements is sufficient for an agent to understand what to expect. The absence of an output schema is partially compensated by the detailed content list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the venue parameter fully (enum with example). The tool description adds the qualifier 'perp venue', which clarifies the domain but doesn't alter parameter semantics. Since schema coverage is 100%, the baseline of 3 is appropriate; the description provides minimal additional meaning beyond what the schema already gives.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the resource ('one perp venue') and enumerates the specific data returned: base maker/taker rates, volume fee ladder, leverage, funding terms, source/check date, and measured all-in cost of BTC/ETH market buys. This clearly distinguishes it from siblings like get_cheapest_venue (comparison) and get_funding (funding only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies usage: call this when you need detailed fee breakdown for a specific venue. However, it does not explicitly mention when to use alternatives, such as get_cheapest_venue for cost comparison or get_volume_ranking for relative volume. No exclusions or when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CEX and DEX perpetual venues ranked by reported volume and by adjusted volume. Adjusted is the reported figure with held-out venues removed; each hold-out has a dated reason. Measurements, not accusations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of venues. Default 20. | |
| window | No | Default 24h. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description adds value by explaining the adjusted-volume methodology, held-out venues, and dated reasons. The phrase 'Measurements, not accusations' also signals an impartial reporting stance beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler, front-loading the core purpose before explaining the adjusted metric. Every clause earns its place, including the clarifying 'Measurements, not accusations' note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple ranking tool with full parameter schema coverage and rich annotations, the description is largely complete. It explains the key methodological nuance (adjusted volume with held-out venues), though it does not describe the exact output shape, which would be useful given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters limit and window are fully documented in the schema. The description does not add parameter-level detail, but it does not need to because the schema already carries that burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource ('CEX and DEX perpetual venues') and a clear action ('ranked by reported volume and by adjusted volume'), which distinguishes it from sibling tools focused on cheapest venue, funding, access, and fees. The title and description align without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for volume-based rankings of perpetual venues, but it does not explicitly state when to prefer this tool over siblings or when not to use it. No exclusions or alternative routing are provided, leaving usage context mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_cheapest_venueget_fundingget_venue_accessget_venue_feesget_volume_rankingCrypto perps data for AI agents: funding rates, open interest, liquidations, order book, CVD.
Free crypto futures data: open interest, funding, long/short, liquidations, volume. No API key.
Exchange-exact crypto derivatives data for AI agents: OI, funding, liquidations, 13 venues.
Crypto perp funding, spreads and listings, plus your own Arbitron cards, trades, PnL and docs.
Add one secure layer between your agents and this server.
