deribit-mcp

Server Quality Checklist

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

Latest release: v2.20260721.0
Disambiguation5/5
Each tool targets a distinct data type (volumes, instruments, expirations, quotes, candle history, funding, etc.) with no overlapping purposes. The descriptions clearly differentiate between exchange-level aggregates and instrument-specific data, making misselection unlikely.
Naming Consistency5/5
All 18 tools follow the exact pattern 'deribit_get_<noun_phrase>', using consistent snake_case and a uniform verb. The names are descriptive and predictable, enabling agents to infer what each tool does without ambiguity.
Tool Count4/5
18 tools is on the high end but still reasonable for a comprehensive public market data server covering quotes, histories, volatility, funding, settlements, and announcements. The scope justifies the count, though it pushes slightly beyond the typical 3-15 range.
Completeness5/5
The server covers the full spectrum of public Deribit data: instruments, quotes, order books, options chains, historical candles, mark prices, indices, volatility, funding, trades, settlements, combos, and announcements. No obvious gaps exist for public market data; the mention of a personal settlement tool indicates a clear boundary between public and private data.
Average 4.1/5 across 18 of 18 tools scored. Lowest: 3.2/5.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds that timestamps are in milliseconds, but this is also present in the schema parameter descriptions. No other behaviors (e.g., response format, limits) are disclosed, but there is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single concise sentence that states the primary action (query historical K-line and volume) followed by a note on timestamp units. No filler, front-loaded with purpose, and efficient.
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 only mentions 'K线和成交量' without details on OHLCV structure, volume units, limits, or pagination. For a tool with 4 required parameters and no output schema, 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% with detailed descriptions for all four parameters. The tool description provides no additional parameter meaning beyond reiterating 'specified contract' and timestamp units, both already in the schema. Baseline of 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool queries historical K-line and volume for a specified contract, which distinguishes it from siblings like mark_price_history or historical_volatility. However, it does not explicitly name alternatives or provide differentiation beyond the resource and type of 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 usage context is provided. The description only states the function without indicating when to choose this over similar tools like deribit_get_mark_price_history or deribit_get_historical_volatility, nor does it mention any exclusions or alternative references.
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds the specific data type (historical realized volatility series) and unit, which is useful context beyond the schema. It does not contradict annotations.
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, direct sentence that is front-loaded and contains no superfluous words. Ideal in length for the tool's simplicity.
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 description covers the core functionality and unit but omits potential details like time range, response format, or default behavior. Given no output schema, it could be more informative, though it is adequate for a basic one-parameter tool.
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%, and the parameter 'currency' is well described with examples. The description only reiterates 'specified currency' without adding new meaning, so it contributes no additional value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries historical realized volatility series for a specified currency, with unit annualized percentage. It distinguishes from sibling tools like deribit_get_volatility_index by explicitly mentioning 'realized volatility' and 'historical', though not naming alternatives.
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 (e.g., volatility index, historical candles). It simply states the action without providing context on scenarios or exclusions.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the data is historical and used for settlement verification, but does not elaborate on pagination, result composition, or any edge cases. This adds minimal value beyond annotations, warranting a baseline score.
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 with no filler. It states the purpose and intended use efficiently, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 3 params and no output schema, the description is adequate but has gaps. It does not explain pagination behavior (offset/count), what happens when no data exists, or how it differs from settlements. The annotations and schema cover the basics, so a 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention parameters at all. Schema coverage is 67% (index_name and count have descriptions, offset does not). With high schema coverage, the baseline is 3; the description adds no additional meaning so it stays at that baseline.
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 queries historical delivery prices for a specified index, which is a specific verb+resource+scope. It distinguishes from siblings like get_index_price (current price) and get_public_settlements (settlement events) by focusing on delivery prices 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 mentions a use case ('to verify settlement of expiring contracts') but does not explicitly state when to prefer this tool over alternatives like settlements or mark price history. It provides context but lacks exclusions or comparative 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the OHLC data scope and millisecond timestamp convention, but does not disclose response shape, pagination, or other runtime behavior.
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?
Single sentence, front-loaded with the core action and resource, no filler. Every word contributes.
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 read-only OHLC query with four fully described parameters, strong annotations, and no output schema, the description is adequate. The simple nature of the tool means no further context is essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters carry full meaning independently. The tool description adds little beyond the schema; the mention of millisecond timestamps is already present in 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?
Description states a specific verb ('查询' / query) and a specific resource (DVOL volatility index OHLC data), clearly distinguishing it from siblings such as historical volatility or index price. The timestamp unit clarification adds useful precision.
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 deribit_get_historical_volatility or deribit_get_index_price. The description only states what the tool does, not when it should be preferred.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds the context of maintenance/settlement windows, which is useful but doesn't disclose any additional behavioral details beyond annotations (e.g., output format, latency). Slightly above baseline, but not substantial.
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 Chinese sentence that efficiently states the purpose and a key use case. No fluff, no redundancy. It's front-loaded and earns its place in every word.
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?
Given zero parameters, a simple purpose, and no output schema, the description is fully complete for a status tool. It explains what it does and why you'd use it (to check maintenance or settlement windows). No gaps remain.
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 carries no parameter burden. Baseline is 4 for zero-parameter tools. The description does not need to explain parameter semantics, and it doesn't add or omit relevant info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('查询' = query) and the resource (Deribit platform status and server time), which distinguishes it from sibling market data tools. However, it doesn't explicitly name any sibling or alternative, so it's clear but not fully differentiated.
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 a use case ('可用于确认维护或结算窗口' - can be used to confirm maintenance or settlement windows), implying when to use it. But it provides no explicit guidance on when not to use it or how it compares to alternatives like deribit_get_announcements or other status-related tools.
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?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false, which already convey non-destructive behavior. The description adds that the length parameter overrides the time range ('不受上面的时间范围影响'), which is a behavioral nuance not obvious from the schema. It also mentions the 'length' chart data addition, adding beyond annotations. No contradiction observed.
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 compact sentence that conveys core purpose and the length parameter's behavior. No filler, no redundancy with schema descriptions. Front-loaded with the main query objective, then the additional feature. Perfectly concise for the information provided.
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 tool has 4 parameters, 100% schema coverage, and no output schema. Description explains the main function and the special behavior of 'length'. For a read-only query tool with clear parameter definitions, this is adequate. However, it doesn't mention what the output looks like (no output schema) or potential edge cases like empty results, but the openWorldHint suggests flexibility in results. Given the complexity, it's quite 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?
Schema already describes all parameters with 100% coverage, so baseline is 3. The description adds value by explicitly stating that 'length' returns additional chart data and that it's independent of the time range, which is not clear from the enum alone. The time unit (milliseconds) is reiterated in the description, reinforcing schema hints. This elevates beyond baseline.
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?
Description explicitly states the tool queries cumulative funding rates and funding rate history for perpetual contracts within a specified time range, and optionally returns chart data for a given length. It clearly identifies the resource (Deribit perpetual funding) and the action (query), but doesn't explicitly contrast with sibling tools like market quotes or trade volumes, though the funding-specific focus is 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 usage for fetching funding data, but provides no explicit when-to-use or when-not-to-use guidance, nor alternatives. The sibling tools are mostly price/history related, so an agent might infer this is for funding-specific needs, but the description doesn't explicitly exclude other scenarios or mention fallback options.
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?
Annotations already declare readOnly=true, openWorld=true, idempotent=true, destructive=false, so the safety profile is covered. The description adds useful behavioral context by saying the 'body' field is HTML and that announcements may explain market/order anomalies. However, response structure and sort/return behavior remain implicit, so there is still a moderate gap.
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 three very short sentences, each adding independent value: purpose/content, HTML format warning, and when-to-use guidance. There is no repetition of schema or annotation information.
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 announcements-list tool with two optional parameters and full schema coverage, this is mostly complete: it covers content scope, the HTML body caveat, and a real-world trigger scenario. Since there is no output schema, slightly more detail about returned announcement fields would push it to perfect completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: 'count' documents default/max, and 'start_timestamp' documents pagination and inclusive-exclusive behavior. The description itself adds no parameter-specific detail, so it does not exceed the schema. Baseline 3 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 ('查询') and clearly names the resource (交易所公告), then enumerates concrete content categories: system upgrades, maintenance windows, new contract launch, and rule changes. This distinguishes it from the sibling market-data tools, all of which return prices, volumes, or instrument data rather than announcements.
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 gives an explicit usage context: check announcements before troubleshooting abnormal market quotes or order placement failures. It does not name an alternative tool or state when not to use it, but no sibling tool is a direct substitute for announcements, and the guidance is sufficiently actionable.
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 annotations already mark the tool as read-only and non-destructive, so the description does not need to repeat that. It adds useful behavioral details such as timestamps being in milliseconds and the ability to use 'any' for filtering, which are not evident from the annotations alone.
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 that convey all necessary information without redundancy. It is well-structured and front-loaded with the main purpose.
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 adequately covers the tool's purpose and key behavioral aspects. Given that no output schema is provided, it is not required to explain return values; however, it could mention that it returns a list of expiration timestamps, but this is implied by the verb '列出'. Overall, it is sufficiently complete for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides parameter types and enums, but the description adds semantic meaning: it explains that 'currency' and 'kind' can be set to 'any' to indicate no filtering. This clarifies the intended interpretation of these parameters beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing tradable expiration dates for futures or options. It distinguishes from sibling tools like get_trade_volumes or get_instruments_info by specifying the specific data returned. The verb '列出' and resource '可交易到期日' are clear.
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 provide any guidance on when to use this tool versus the alternative get_* tools. It only states what it does without situational context or comparative advantages. No usage recommendations are 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is known. The description adds that it returns aggregated data for the whole exchange and mentions the optional extended parameter's effect, but does not describe other behaviors like pagination or rate limits. This is adequate given the annotation coverage, hence a 3.
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 starts with the core purpose, then details the breakdown, mentions the extended parameter, and ends with a clarifying statement about scope. Every clause adds value without 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?
Given the tool's simplicity (one optional parameter, no output schema, read-only), the description is reasonably complete. It explains what data is returned (24h volumes by product type, optionally 7/30 days) and clarifies scope. It does not describe output structure, but that is acceptable without an output schema for a simple metric tool. A 4 seems right given the 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 description coverage is 100% for the only parameter 'extended', which is described in the schema as returning 7-day and 30-day volumes. The description repeats this but does not add extra details like default value or behavior when false. Baseline 3 is appropriate as the schema already handles the parameter description.
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 verb (查询/query) and resource (Deribit trade volumes aggregated by currency), and explicitly distinguishes it from personal trades ('与个人成交无关'). It also mentions the specific breakdown (calls, puts, futures, spot), which distinguishes it from other market data tools among siblings.
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 makes clear it is exchange-wide data, not personal, which guides when to use it. It does not explicitly name alternative tools for personal trades or other volume queries, but the context is sufficient for typical use cases. A 4 is appropriate because it clearly scopes the use case without explicit when-not-to-use references.
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?
Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds behavioral context: results are per natural day and unsupported currencies will not have data. This goes beyond the annotation-provided safety profile.
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-loaded with the main action and target. Every clause adds value: purpose, granularity, supported currencies, and the negative constraint. 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 read-only tool with full schema documentation and no output schema, the description covers the core purpose, key constraint, and data granularity. It is slightly thin on what the response looks like, but given the simplicity and good annotations, it is sufficiently 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?
The input schema fully documents all three parameters with descriptions and enum values, making schema coverage 100%. The description restates the currency enum but adds no new parameter-level semantics beyond what the schema already provides.
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 queries historical APR for interest-bearing tokens, returned by natural day. It also specifies the exact supported currencies (usde, steth, usdc, build), which differentiates it from sibling market-data tools like funding 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this for APR history and only for the four listed currencies. It explicitly warns that other currencies lack this data, which serves as a when-not-to-use signal, though it does not name alternatives.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructiveHint. The description adds valuable parameter-specific behavior, such as the detailed fields returned for instrument_name (tick size, multiplier, fee rates, expiration, instrument id), which beyond annotations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence in Chinese, front-loaded with the main purpose, followed by logical conditional clauses. Every phrase earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the three primary usage modes well, but it omits behavior for the 'kind' parameter and combinations like currency+kind. With no output schema, the return format for currency and list cases is not fully specified, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds semantic relationships beyond the schema: it explains that no parameters yields currencies, currency alone yields a list, and instrument_name yields detailed specs. However, the 'kind' parameter is not mentioned at all, leaving its purpose unclear despite the enum-only schema definition, so it is not fully comprehensive.
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 queries Deribit supported currencies and tradable contracts ('查询 Deribit 支持的币种和可交易合约'), and differentiates itself from siblings by specifying three parameter-dependent response modes. The verb '查询' plus resource scope makes 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit parameter-usage context: omit all parameters to get currencies, pass currency to get the contract list, and pass instrument_name to get detailed specs. It does not mention alternatives or when to prefer this tool over siblings, but the usage context is clear.
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?
Annotations already declare readOnly, idempotent, non-destructive, so the bar is lower. Description adds behavioral details: payload reduction with ids_only, and requirement of currency when combo_id omitted. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, logically structured with semicolons, front-loaded with purpose, and zero 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?
Given no output schema and 4 optional params, the description covers all major usage scenarios and even notes payload size differences. State param is not mentioned, but its enum is self-explanatory in schema. A brief note on state usage would make it fully 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?
Schema covers 75% of parameters (state lacks description). Description explains the interplay between combo_id, currency, and ids_only, adding meaning beyond the schema's individual field descriptions. However, state remains undocumented in both.
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?
Description clearly states the tool queries existing combo contracts and specifies three distinct modes (with combo_id, ids_only, and by currency). The verb '查询' (query) plus the specific resource (组合合约) distinguishes 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use each parameter combination (combo_id for single detail, ids_only for lightweight list, else full list). However, it does not explicitly mention alternatives or exclusion criteria relative to siblings.
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?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral nuance by stating that querying with instrument_id returns only order book data, which is not visible in the schema. This appropriately extends beyond structured fields without contradicting them.
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 dense sentence that covers the purpose, key parameter relationship, and an important behavioral exception. There is no filler, and the most important information appears first.
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, optional-parameter read-only quote tool with no output schema, the description is mostly complete. It could slightly improve by noting whether IV/Greeks only apply to options or by naming the default depth in words, but the provided context is already sufficient for correct invocation.
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%, so the schema already describes depth, instrument_id, and instrument_name. The description adds critical semantic value by explaining that instrument_name and instrument_id are alternatives and that id changes the returned data scope.
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 queries real-time market quotes, order book depth, implied volatility, and option Greeks for a specified contract. This specific verb-object structure distinguishes it from sibling tools like historical candles, trade volumes, or mark price history.
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?
It gives clear usage context: instrument_name and instrument_id are alternatives, with a distinct behavioral consequence when using id. It does not explicitly name sibling tools or provide exclusions, but the domain of real-time quote/order book/Greeks is sufficiently clear.
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?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds what fields are returned and explains the two operational modes, which is valuable context beyond the annotations. It does not mention rate limits or pagination, but that is not essential given the read-only nature.
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 sentences, front-loaded with the core function and then the usage modes. Every sentence carries essential information without redundancy. It is efficiently structured for quick agent comprehension.
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 read-only query tool with 3 documented parameters and no output schema, the description adequately explains the two possible queries and the key returned fields. It lacks details on output formatting or potential large-response limits, but given the tool's simplicity and strong annotations, it is sufficiently 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?
Schema coverage is 100% with descriptions for all parameters, but the description adds the key mutual-exclusivity constraint and clarifies that kind only applies in currency mode. This goes beyond the schema's static property definitions, making the semantics clearer for correct invocation.
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 queries contract summaries including open interest, implied volatility, volume, and bid/ask prices. It also distinguishes two modes (by currency for a full chain or other contract types, or by instrument_name for a single contract), which sets it apart from siblings like get_market_quote or get_instruments_info.
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 explicitly states mutual exclusivity between currency and instrument_name, and that kind only applies when using currency. This gives clear context on when each parameter is appropriate, but it does not explicitly name alternative tools for similar purposes, so a small deduction.
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?
Annotations already indicate readOnly, idempotent, and non-destructive behavior; the description adds non-obvious behaviors beyond annotations: omitted index_name returns available names, and range triggers simultaneous history return. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact Chinese sentence conveys all key behaviors with semicolon-separated conditions; no filler or redundancy.
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 3-optional-parameter price/getter tool with no output schema and good annotations, the description covers all invocation modes and edge cases (omitted index_name, range with index_name). It is sufficient for an agent to select and call 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?
Schema coverage is 100% with detailed param descriptions and enums; the description adds conditional meaning by linking range to history and omitted index_name to list output. This goes beyond the baseline schema 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 uses a specific verb (查询/query) and resource (index price), and clearly distinguishes three behaviors: current price for a named index, history when range is provided, and index-name listing when index_name is omitted. This separates 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly describes conditional usage: provide index_name for current price, add range for history, or omit index_name to list available indices. It does not name alternatives or say when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds crucial expected behavior: mark price history is only retained for options involved in volatility index calculation, and empty results for futures/perpetuals are normal. This disclosure prevents misinterpretation of empty arrays as errors, which is highly valuable beyond the annotations.
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 sentences: the first states the action and return format, the second provides a critical caveat. No redundant information, and the important behavioral note is included without extra verbosity.
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 simple 3-parameter read-only history tool, the description covers what it returns, the units, and the unusual empty-result case. Annotations cover safety, and the schema covers parameters fully, so nothing critical is missing for an agent to use the tool 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% with all parameters documented (instrument_name with examples, timestamps with units). The description only confirms the millisecond unit for timestamps, which is already present in the schema. Thus, the description adds little beyond the structured schema, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('query') and specifies the resource ('historical mark price series for a contract') plus the exact return format ([timestamp, mark price] pairs). The note about futures/perpetuals returning empty arrays distinguishes it from similar 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly notes that futures and perpetuals will return empty arrays, which implies this tool is intended for options that participate in volatility index calculation. While it doesn't explicitly name alternative tools when futures/perpetuals are queried, the behavior warning provides enough context for an agent to decide when this tool is appropriate.
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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context: the tool covers market-wide events only, not personal P&L, and clarifies the mutual exclusivity constraint. This goes beyond the annotations without contradicting them.
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?
Three sentences, each earning its place: purpose with exclusions, a mutual-exclusivity constraint, and a pointer to the alternative tool. No redundancy or 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?
The description is concise but covers the core purpose, a key input constraint, and the alternative for personal data. With 6 parameters and no output schema, a bit more detail on return structure could be helpful, but the annotations and schema cover important aspects. Overall adequate for this market-data tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), so the schema already documents most parameters. The description adds the critical semantic detail that currency and instrument_name must be mutually exclusive and one is required, which is not expressed in the schema. This is valuable added meaning.
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 queries market-wide settlement, delivery, and bankruptcy events, explicitly excluding personal position P&L. This distinguishes it from the sibling tool deribit_get_settlement_history, which handles personal results. The verb '查询' (query) is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that currency and instrument_name are mutually exclusive and one must be provided. It also provides a clear alternative for personal settlement/delivery results: deribit_get_settlement_history. This is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses meaningful behavior: this endpoint only returns public trades (not personal), timestamp queries route to a dedicated time-window endpoint, and sequence parameters enable sequence-based pagination. These are non-obvious traits not present in structured fields.
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 three short sentences, front-loaded with the primary purpose, and every sentence adds unique guidance. No redundancy or unnecessary detail.
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 9-parameter tool with no required fields and no output schema, the description covers the essential constraints (public-only, parameter mutual exclusions, endpoint selection). The remaining parameters are well-documented in the schema, and annotations cover safety. This is a complete, self-sufficient description.
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 high (89%), so baseline is 3. The description adds value by stating the mandatory currency/instrument_name choice and the exclusivity between timestamp and sequence parameters, which the schema does not enforce. It clarifies endpoint behavior per parameter group beyond the individual descriptions.
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 queries all-market public trades and explicitly excludes personal trades, giving a specific verb + resource + scope. This distinguishes it from sibling tools like trade volumes or quotes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: currency and instrument_name are mutually exclusive, and timestamp-based vs sequence-based filtering are separate modes that cannot be mixed. It does not explicitly name alternatives among siblings, but the parameter guidance is strong.
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:

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

Score Badge

Copy to your README.md:

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

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