Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@derive-options-mcp I think BTC goes up over the next month. I'd risk $500."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for Derive options. Describe a view; get real option structures, priced against the live order book, sized to your budget, with the payoff and the worst case spelled out.
you: I think BTC goes up over the next month. I'd risk $500.
agent: BTC is 85,376.
## Up, capped — Price goes up, but not enormously.
Costs $500 for 0.46 contracts, expiring Fri, Oct 30 (37 days).
- Most you can lose: $500
- Most you can make: $1,347
- Breaks even at: 91,083
Legs: buy 1× 90,000C @ $2,354 · sell 1× 94,000C @ $1,271
$1,347 ┤ ▀▀▀▀▀▀▀▀▀▀▀▀
┤ ▀│
┤ ▀│
$0 ┼···························▀│···········
-$500 ┤▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄│
└─────────────────┬──────────────────────
now 85,376No API key. No account. No wallet. It reads Derive's public API and does the arithmetic locally.
Claude Code
claude mcp add derive-options -- npx -y derive-options-mcpClaude Desktop / Cursor / Codex — add to the MCP config:
{
"mcpServers": {
"derive-options": {
"command": "npx",
"args": ["-y", "derive-options-mcp"]
}
}
}Remote — npm run serve starts a streamable-HTTP endpoint on :8080/mcp.
To mount it inside an existing app, export the handler from any route that
speaks Web Request/Response (a Next.js route handler, for instance):
import { handleMcpRequest } from "derive-options-mcp/dist/transports/http.js";
export const POST = handleMcpRequest;Related MCP server: MCP Options Order Flow Server
Tool | Answers |
| "I think X goes up / stays flat / moves hard — what should I trade?" |
| "I hold this. How do I protect it?" |
| "What does an iron condor on ETH cost right now?" |
| Every shape, what it bets on, and its trade-off |
| The market |
| Prices and the tape |
Every tool returns two things: text with an ASCII payoff diagram for the
model and the chat window, and structuredContent carrying the full payoff
curve, every leg with its fill price and its quote, breakevens, both extremes
and a handoff link — enough for a host app to render its own chart without
re-deriving anything and disagreeing with what the user was just told.
Enumerate. Every shape that can express the view, at the three expiries nearest your horizon, at three distances from the money — about a hundred candidates.
Price against the book. Buys cross the ask, sells hit the bid. Priced off mark, every spread looks free, and the sell legs are exactly where these books are thinnest. A leg with no price on its side is a rejection, not a number to soften — so nothing is ever proposed that cannot be traded.
Size to the risk. Debit structures size on cost. Credit structures are constrained by what they can lose, not what they cost, so they size on that — otherwise a $500 budget quietly opens a $5,000 exposure.
Rank. By what each pays if the market moves one standard deviation by that expiry — the market's own implied volatility, not a guess — per dollar at risk. Each expiry is scored against its own one-sigma move, so a nine-day structure isn't flattered by a thirty-seven-day move.
It costs three network requests: the chain is cached and a whole expiry's book arrives in one call, so the hundred candidates are priced from three responses.
Structures whose loss has no limit are excluded unless you pass
allow_uncapped. They can't be sized against a budget, and their real
constraint is margin this server cannot see.
It does not trade. It holds no key, signs nothing, and has no account. Every result carries a link where you review and sign it yourself.
This is deliberate rather than unfinished. A Derive session key is not scope-limited — the protocol grants it the same authority as the account owner, withdrawals included — so a server holding one would be custodial. Building the trade and signing it are separate jobs, and only one of them belongs here.
Prices move. Everything is a snapshot. Treat a result more than a minute old as stale and ask again.
It is not advice. It tells you what a structure costs and what it can lose. What to do about that is yours.
Variable | Default | |
|
|
|
|
| Where trade links point |
|
| HTTP transport only |
Mainnet is Derive v2 (api.lyra.finance) — v3 mainnet has not launched, and its
option books read bid 0 / ask 0.
npm install && npm run build
npm test # pricing core, against a book under test
npx @modelcontextprotocol/inspector node dist/transports/stdio.jsMIT.
Every quoted strike on one expiry — bid, ask, mark, implied volatility and delta for both the up and down contract. Use when you need to reason about the actual book rather than take a proposal.
| Name | Required | Description | Default |
|---|---|---|---|
| around | No | How many strikes either side of spot. Default 8. | |
| currency | Yes | ||
| expiry_ts | No | From list_expiries. Defaults to the nearest weekly. |
| Name | Required | Description |
|---|---|---|
| rows | Yes | |
| spot | Yes | |
| currency | Yes | |
| expiryTs | Yes | |
| expiryDays | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose read-only and open-world hints, so the description does not need to restate safety. It adds value by clarifying that the tool returns the real quoted book for a single expiry—including both contracts—rather than a theoretical or proposed structure, which is a meaningful behavioral distinction from sibling tools.
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?
Two dense sentences with no filler: the first front-loads the payload scopeabb, and the second gives the selection cue. Every phrase earns its place.
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?
Given a rich output schema, well-described parameters, and annotations covering the read-only behavior, nothing essential is missing. An agent can correctly select and invoke the tool from the description and schema alone.
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 coverage is 67%: around and expiry_ts have descriptions, while currency is represented by an enum. The description adds no parameter-level detail, so it does not enrich the schema, but the schema already carries most of the parameter documentation 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 names the resource (option chain), the scope (one expiry), and the returned fields (bid, ask, mark, implied volatility, delta for both call and put). It also distinguishes itself from proposal-making siblings by framing this as 'the actual book' rather than a proposal.
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?
It gives an explicit trigger condition: use when you need to reason about the actual book rather than take a proposal. This provides both a when-to-use signal and an implicit when-not-to-use contrast against the proposal-generating siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The most recent option trades on the whole exchange, newest first. Use to see what other people are actually putting money on before proposing something.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| currency | No | Leave out for the whole exchange. |
| Name | Required | Description |
|---|---|---|
| trades | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful behavior beyond that: exchange-wide scope, recency, newest-first ordering, and that these are real option trades rather than quotes.
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?
Two short sentences with no filler. The core scope and ordering are front-loaded, and the second sentence adds a practical usage cue.
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?
The tool is a simple read-only list operation with two optional parameters and an output schema. The description conveys the essential selection criteria, ordering, and use case. Nothing critical for invoking it correctly is missing.
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 only 50%: currency has a description, but limit has only type/min/max with no semantics. The description repeats the exchange-wide scope but does not explain limit or clarify how currency interacts with the ordering. Since coverage is low, the description should have compensated.
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 ('get'), a specific resource ('most recent option trades on the whole exchange'), and the ordering ('newest first'). This clearly distinguishes it from siblings like get_ticker, get_option_chain, and price_structure.
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 use case: use it to see what other people are actually putting money on before proposing something. It does not explicitly name exclusions or alternatives, but the context is clear enough among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current price, and optionally where it has been, so a view can be grounded in what actually happened.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | Yes | ||
| history_hours | No | Include price history over this many hours. |
| Name | Required | Description |
|---|---|---|
| spot | Yes | |
| history | No | |
| currency | Yes | |
| changePct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, making the safety profile clear. The description adds that the tool optionally returns historical price data ('where it has been'), which is consistent with the schema and annotations, but does not disclose further behavioral traits such as data freshness or response shape.
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 a single, front-loaded sentence that states the core action and the optional behavior, with a short rationale that earns its place. There is no redundant or filler content.
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 spot-price tool with an output schema and clear annotations, the description covers the essential behavior and optional history sufficiently. It does not elaborate on sibling trade-offs, but no critical call-time fact is missing.
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 already documents history_hours and currency via an enum. The description adds conceptual meaning by matching 'Current price' to currency and 'where it has been' to history_hours, but it does not clarify ranges, units, or behavior when history_hours is omitted beyond what the schema already provides.
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 clearly identifies the resource (a coin) and the action (return its current price), with optional price history. It is specific but does not explicitly differentiate this from sibling tools like get_ticker or get_recent_trades.
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 used when current price and optionally historical price context are needed, especially 'so a view can be grounded in what actually happened.' However, it provides no explicit exclusions or alternatives, leaving sibling differentiation to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bid, ask, mark, implied volatility and greeks for a single named instrument, e.g. 'ETH-20261030-3000-C'.
| Name | Required | Description | Default |
|---|---|---|---|
| instrument | Yes | Derive instrument name, e.g. ETH-20261030-3000-C |
| Name | Required | Description |
|---|---|---|
| iv | Yes | |
| ask | Yes | |
| bid | Yes | |
| mark | Yes | |
| vega | Yes | |
| delta | Yes | |
| gamma | Yes | |
| index | Yes | |
| theta | Yes | |
| instrument | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by enumerating the exact data fields returned and providing a concrete instrument example.
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 sentence delivers the core meaning and an example with no filler. The title is also crisp and informative.
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?
With one well-documented parameter, an output schema, and read-only annotations, the description plus structured metadata fully equip an agent to select and invoke the tool. Nothing critical is missing.
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 coverage is 100%, so the schema already documents the parameter. The description adds meaning by clarifying the parameter must be a single named instrument and by giving a realistic example format, going just beyond the schema's minimal description.
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?
States a specific verb and resource: returns bid, ask, mark, implied volatility, and greeks for a single named instrument. The example and title 'One contract, in full' clearly distinguish it from chain-level or spot tools.
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 makes clear this is for a single named instrument, which implies use when a specific contract is targeted rather than an entire chain. It does not explicitly name alternatives or exclusions, but the 'single named instrument' framing gives adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which coins can be traded here, with their current price and how many expiries are listed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| currencies | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no safety concern is hidden. The description adds useful behavioral context by revealing the output scope: current price and expiry counts, which helps the agent know what to expect beyond the title alone.
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 a single, front-loaded sentence that conveys the core purpose and the key output fields with no wasted words. Every part adds value.
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 zero-parameter, read-only listing tool with an output schema, the description is sufficiently complete. It explains what the list contains and the count of expiries, leaving little ambiguity for an agent selecting or invoking the tool.
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 tool has zero parameters, so there is nothing for the description to document in terms of inputs. The baseline of 4 applies, and the description appropriately focuses on the returned data rather than parameter usage.
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 clearly states that the tool lists tradable coins, their current price, and the number of listed expiries, which goes beyond the generic title. It distinguishes the resource (currencies/coins) from siblings like list_expiries or get_spot, though it does not explicitly name alternatives.
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 'Which coins can be traded here' gives clear context for when to use this tool: when an agent needs to discover available coins and their option-chain activity. It does not explicitly mention exclusions or alternative tools, but the intended use case is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every listed expiry for a coin, with how far away it is and how many strikes are quoted on it.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | Yes |
| Name | Required | Description |
|---|---|---|
| spot | Yes | |
| currency | Yes | |
| expiries | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that results include distance and strike counts, but does not disclose ordering, pagination, or data freshness. This is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the core action and resource, then specifies exactly what information is returned. The title provides additional context without redundancy.
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?
With an output schema present, return values are already documented; annotations cover read-only and open-world behavior. The simple one-parameter schema makes the description sufficient for correct invocation. Only missing usage differentiation keeps it from a 5.
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 0%, but there is only one required parameter with a self-explanatory enum. The description's 'for a coin' loosely maps to currency but adds no format, meaning, or nuance beyond the schema's enum values.
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 and object: 'Every listed expiry for a coin,' plus the included fields ('how far away it is and how many strikes are quoted'). This clearly distinguishes it from sibling tools like list_currencies and get_option_chain.
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?
Usage context is implied by the title 'Dates you can trade' and the phrase 'for a coin,' but there is no explicit when-to-use guidance or contrast with alternatives such as get_option_chain. The agent must infer when this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The option structures available, each with what it bets on and its trade-off, in plain language. Use to pick a shape id for price_structure, or to explain the options to someone.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| strategies | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to restate that. The description adds that it provides plain-language explanations, which is useful but not behavioral. It doesn't describe return format or error handling, but given the simplicity and read-only nature, the annotation covers the core 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence states the resource and content, the second gives usage context. Everything earns its place and is front-loaded.
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 parameterless read-only list tool with an output schema present, the description covers purpose and usage. It might mention that it returns a list of strategies, but that is likely defined in the output schema. The description is adequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and description cannot add parameter semantics. Baseline for 0-param tools is 4, and the description correctly focuses on the output and purpose rather than parameters.
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 clearly states the tool lists available option structures, each with its bet and trade-off, in plain language. It distinguishes itself from sibling list tools (list_currencies, list_expiries) by focusing on strategy shapes and explicitly ties to price_structure via shape ID selection.
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?
It explicitly says to use it to pick a shape id for price_structure or to explain options to someone. This gives clear when-to-use context, though it does not mention alternative tools or exclusion criteria. Still, the guidance is direct and sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price a specific shape at a specific expiry against the live book — use when the shape is already decided, or to compare a variant of something propose_trades returned. offset pushes every leg further out of the money (cheaper, needs a bigger move). Returns the same full detail as a proposal. Call list_strategies first if you need the shape ids.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Strikes further from the money. Default 0. | |
| currency | Yes | ||
| strategy | Yes | Shape id from list_strategies, e.g. 'call-spread', 'iron-condor'. | |
| contracts | No | Size. Default 1. | |
| expiry_ts | No | Unix seconds, from list_expiries. Defaults to the nearest weekly. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| structure | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, lowering the bar, and the description adds meaningful behavior: pricing against the live book, the effect of offset ('pushes every leg further out of the money... cheaper, needs a bigger move'), and that it returns the same full detail as a proposal. This goes beyond what the annotations or schema alone convey, though it does not discuss failure modes or data freshness.
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?
Three tightly written sentences with no filler. The first sentence front-loads the purpose and primary use case, the second explains the key offset behavior, and the third covers return parity and the prerequisite. Every sentence earns its place.
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 pricing tool with an output schema and strong parameter descriptions, the description is sufficiently complete. It covers when to use it, how it relates to propose_trades, the prerequisite for getting shape ids, the key offset parameter behavior, and what to expect in the return. Nothing essential is missing for an agent to invoke it correctly.
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 high (80%), so the schema already documents strategy, contracts, expiry, and offset defaults. The description adds real semantic value by explaining the practical effect of offset (cheaper but needs a bigger move) and reinforcing that strategy ids come from list_strategies. This is above the baseline but not exhaustive for every parameter.
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 ('Price'), a precise resource ('a specific shape at a specific expiry against the live book'), and a clear use case ('when the shape is already decided'). It also differentiates itself from propose_trades by framing this tool as pricing an already-decided/named structure or comparing a variant of a proposal.
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 explicit when-to-use guidance: use it when the shape is already decided or to compare a variant of something propose_trades returned. It also names the prerequisite ('Call list_strategies first if you need the shape ids'), which directs the agent to the correct sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a holding and the level they want protected, return ways to protect it, priced against the live book. Use this for 'I hold 5000 dollars of ETH and want to protect it', 'how do I put a floor under my BTC'. The payoff returned is the WHOLE position — the coin plus the options — not the options alone, which is the only honest way to show what protection does. Says plainly where each one stops protecting and what it costs as a share of the holding.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| currency | Yes | ||
| protect_at | No | The price they want floored. Defaults to 10% below spot. | |
| coin_amount | No | How much of the coin they hold. | |
| horizon_days | No | How long they want protection for. Default 30. | |
| notional_usd | No | What the holding is worth today. Give this or coin_amount. |
| Name | Required | Description |
|---|---|---|
| spot | Yes | |
| options | Yes | |
| currency | Yes | |
| rejected | Yes | |
| protectAt | Yes | |
| coinAmount | Yes | |
| notionalUsd | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the readOnlyHint and openWorldHint annotations: it discloses that the returned payoff is the whole position, not just the options, and that each option plainly states where protection stops and what it costs as a share of the holding. This is exactly the kind of contextual behavior an agent needs.
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 appropriately sized at three sentences. It front-loads the core purpose, gives concrete examples, and then states the critical output semantics without wasting words.
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?
Given the output schema and annotations, the description covers the key contextual details an agent needs: what the tool does, when to invoke it, and crucially what the returned protection payoff represents. No important behavioral gap remains for selecting and using this tool.
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?
With 67% schema coverage, the schema already documents protect_at, coin_amount, horizon_days, and notional_usd. The description adds useful natural-language intent mapping—'holding' maps to coin_amount/notional_usd, 'floor under my BTC' maps to currency and protect_at—which helps the agent translate user phrasing into parameters.
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 names a specific verb and resource: given a holding and a protection level, return protection strategies priced against the live book. The examples and the whole-position payoff explanation make it clearly distinct from generic sibling tools like propose_trades or list_strategies.
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?
It gives clear, explicit use cases with concrete natural-language examples: 'I hold 5000 dollars of ETH and want to protect it' and 'how do I put a floor under my BTC.' It does not state when not to use it or name alternatives, so it stops short of a full when/when-not/alternative structure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a view on a coin and a budget, return a few real option structures that express it, priced against the live book and sized to the budget. Use this for 'I think X will go up', 'what should I trade if I expect a big move', 'how do I bet on ETH staying flat'. Every result is tradable right now: candidates that cannot be filled are discarded, not softened. Each is ranked by what it pays if the market moves one standard deviation by that expiry — the market's own implied volatility, not a guess — divided by what it puts at risk. Structures whose loss has no limit are left out unless allow_uncapped is set.
| Name | Required | Description | Default |
|---|---|---|---|
| view | Yes | bullish = expects it to rise; bearish = to fall; quiet = to stay near here; big-move = a large move either way. | |
| limit | No | ||
| currency | Yes | The coin. | |
| budget_usd | Yes | What they'll spend, or for a structure that pays up front, what they'll risk. | |
| horizon_days | No | Roughly when they expect to be right. Default 30. | |
| target_price | No | A specific level they have in mind, reported per structure. | |
| allow_uncapped | No | Include structures that can lose without limit. Off by default. |
| Name | Required | Description |
|---|---|---|
| spot | Yes | |
| view | Yes | |
| atmIv | Yes | |
| currency | Yes | |
| rejected | Yes | |
| budgetUsd | Yes | |
| proposals | Yes | |
| referenceSpot | Yes | |
| referenceMovePct | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare read-only and open-world behavior; the description adds essential behavioral details: unfillable candidates are discarded rather than softened, ranking is based on one-standard-deviation payoff divided by risk, and uncapped-loss structures are excluded unless allow_uncapped is set. This goes well 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with the core function, then layered with usage examples and key behavioral guarantees. No sentence is wasted; each clause earns its place.
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 7-parameter tool with an output schema, the description covers the essential semantics: inputs, ranking methodology, tradability filtering, and risk defaults. The output schema handles return-value details, so nothing critical is missing.
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 high at 86%, so the schema already documents most parameters. The description reinforces budget sizing and the view concept but adds little parameter-specific meaning beyond what the schema provides, meriting the baseline 3.
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 and resource: given a view and budget, return real option structures priced against the live book. It also gives concrete example queries, making the tool's purpose unmistakable and distinct from siblings like propose_hedge, even without naming them.
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?
It provides explicit use cases with 'Use this for...' and example natural-language prompts. It doesn't name alternatives or state when not to use it, so it falls short of full exclusion guidance, 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_option_chainget_recent_tradesget_spotget_tickerlist_currencieslist_expirieslist_strategiesprice_structurepropose_hedgepropose_tradesScored across 10 tools
Each tool targets a distinct resource and action: trade proposals, hedging, pricing specific structures, listing strategies, currencies, expiries, option chains, spot, tickers, and recent trades. No two tools have overlapping purposes; even the two proposal tools are clearly separated by intent (expressing a view vs. protecting a holding).
All tools follow a consistent verb_noun pattern with lowercase snake_case: propose_trades, propose_hedge, price_structure, list_strategies, list_currencies, list_expiries, get_option_chain, get_spot, get_ticker, get_recent_trades. Verbs (propose, price, list, get) clearly indicate the action, and the pattern is uniform across the set.
With 10 tools, the server is well-scoped for its domain of options analysis and trade generation. Each tool serves a clear purpose—generating ideas, hedging, pricing, listing available instruments, and retrieving market data—without redundancy or bloat.
The surface covers the core workflow: generating trade ideas, hedging existing holdings, pricing specific structures, listing strategies and market metadata, and accessing detailed market data. A minor gap is the lack of trade execution (the server seems focused on analysis and pricing), but this is likely intentional given the server's name and description. Overall, the domain is well-covered.
Real-time news with bias scoring, live market data, and AI-powered options pricing
Live prices, perps, prediction markets and a paper trading desk over one MCP.
Options analytics for AI assistants: chains, IV rank, VRP, Greeks, GEX, expected moves, screeners.
Options analytics: 17 pricing models, 17 Greeks, GEX, IV, 23 screeners, unusual, dark pool, max pain
