Option Desk

Strategy from snapshot

option_strategy_from_snapshot

Read-onlyIdempotent

Build one option structure from a user-supplied chain and return its opaque payoff PNG with permanent source and risk warnings.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "option_strategy_from_snapshot"
  }
}

Input Schema

Name	Required	Default
`rate`	No
`expiry`	No
`symbol`	Yes
`strategy`	No	iron_condor
`data_source`	No
`source_data`	No
`source_text`	No
`source_format`	No
`dividend_yield`	No
`rights_confirmed`	No

Output Schema

Name	Required	Description
`units`	No
`expiry`	Yes	Option expiry, when available.
`images`	No	The returned images, for the inline plot app.
`warning`	Yes	Data and financial-risk warning.
`strategy`	Yes	Requested strategy for a payoff plot, when applicable.
`data_mode`	Yes	Whether the figures are synthetic or user supplied.
`plot_types`	Yes	Plot names in the same order as the image content.
`underlying`	Yes	Underlying shown by the plots.
`captured_at`	Yes	Snapshot or fixture timestamp, when available.
`data_source`	Yes	Named source used for the figures.
`diagnostics`	No
`expiry_note`	No	Set when the requested expiry is not the one the figures are for.
`image_count`	Yes	Number of returned PNG images.
`strategy_records`	No	Exact plotted engine records. Use these for tables; do not infer values from images.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 11, 2026

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds that the output is an opaque payoff PNG with permanent source and risk warnings, which is useful behavioral context, but it does not explain prerequisites such as rights_confirmed or how source input is selected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no wasted wording. It is concise and readable, though its brevity contributes to the parameter-semantics gaps.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 10 parameters, 0% schema description coverage, and a complex strategy-construction task. Although an output schema and rich annotations reduce the need to explain return values and safety, the description is too thin about inputs and when to use this tool rather than its siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden for 10 parameters. It only loosely references a 'user-supplied chain' and 'one option structure' without clarifying source_data, source_text, source_format, strategy, expiry, rate, dividend_yield, data_source, or rights_confirmed.

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 states a specific verb and resource: build one option structure from a user-supplied chain and return a payoff PNG. It is clear what the tool does, but it does not distinguish this from sibling tools such as option_plots_from_snapshot or option_strategy_plot.

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 gives no explicit when-to-use guidance, no exclusions, and no alternatives. It implies the tool is used with a user-supplied chain, but an agent must infer when this tool is preferable to its siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Option Desk tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?