Skip to main content
Glama

Options Profit Calculator

Get option chain

get_option_chain
Read-only

Calls and puts for one expiry: bid, ask, last, mid, volume, open interest and implied volatility, from optionsprofitcalculator.com.

Input Schema

NameRequiredDescriptionDefault
expiryYesExpiry date, YYYY-MM-DD (see get_expirations)
symbolYesTicker symbol, e.g. AAPL

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-reach are covered structurally. The description adds the concrete data source (optionsprofitcalculator.com), which usefully signals third-party provenance and possible staleness, but says nothing about failures, rate limits, or empty/missing expiries.

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?

A single dense sentence that front-loads the resource and then lists returned fields, with no filler. It is a noun fragment rather than a full sentence, but nothing is wasted.

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?

With no output schema, the description carries return-value duty and does it well by enumerating the exact fields (bid, ask, last, mid, volume, open interest, IV). Parameters are fully covered by the schema; the only meaningful gap is the absence of usage/routing guidance against the five siblings.

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%, with both symbol and expiry documented including format hints, so the schema carries the parameter burden. The description reinforces that the chain is scoped to a single expiry but adds no format, range, or edge-case guidance beyond that.

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 names a specific resource (calls and puts for one expiry) and enumerates the fields returned, which lets an agent distinguish it from get_quote and find_options. It stops short of an explicit verb phrase like 'fetch the full chain', but the scope ('one expiry') is clear enough to act on.

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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative. The only hint is the phrase 'for one expiry', which is a scope constraint rather than a routing rule; the pointer to get_expirations lives in the schema, not the description.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources