Skip to main content
Glama
alpacahq

alpaca-mcp-server

Official
by alpacahq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_option_contracts

Retrieve and filter option contracts for underlying symbols by type, style, status, expiration, and strike price to find tradable options.

Instructions

Retrieves option contracts for underlying symbol(s).

Input Schema

NameRequiredDescriptionDefault
typeNoThe type of the option contract.
limitNoThe number of contracts to limit per page (default=100, max=10000).
ppindNoThe ppind (Penny Program Indicator) field indicates whether an option contract is eligible for penny price increments, with `true` meaning it is part of the Penny Program and `false` meaning it is not.
styleNoThe style of the option contract.
statusNoFilter contracts by status (active/inactive). By default only active contracts are returned.
page_tokenNoUsed for pagination, this token retrieves the next page of results. It is obtained from the response of the preceding page when additional pages are available.
root_symbolNoFilter contracts by the root symbol.
expiration_dateNoFilter contracts by the exact expiration date (format: YYYY-MM-DD).
strike_price_gteNoFilter contracts with strike price greater than or equal to the specified value.
strike_price_lteNoFilter contracts with strike price less than or equal to the specified value.
show_deliverablesNoInclude deliverables array in the response.
underlying_symbolsNoFilter contracts by one or more underlying symbols.
expiration_date_gteNoFilter contracts with expiration date greater than or equal to the specified date.
expiration_date_lteNoFilter contracts with expiration date less than or equal to the specified date. By default this is set to the next weekend.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.4.0
    • changedInput schema / properties / ppind / description
      Previous value: -"The ppind(Penny Program Indicator) field indicates whether an option contract is eligible for penny price increments,\nwith `true` meaning it is part of the Penny Program and `false` meaning it is not."New value: +"The ppind (Penny Program Indicator) field indicates whether an option contract is eligible for penny price increments,\nwith `true` meaning it is part of the Penny Program and `false` meaning it is not."
  2. Changed5 schema fields changedv2.3.2
    • changedInput schema / properties / page_token / example
      Previous value: -"MA=="New value: +"eyJpZCI6IjU1MGU4NDAwLWUyOWItNDFkNC1hNzE2LTQ0NjY1NTQ0MDAwMCJ9Cg"
    • changedInput schema / properties / style / description
      Previous value: -"Filter contracts by the style (american/european)."New value: +"The style of the option contract."
    • addedInput schema / properties / style / example
      Added value: +"american"
    • changedInput schema / properties / type / description
      Previous value: -"Filter contracts by the type (call/put)."New value: +"The type of the option contract."
    • addedInput schema / properties / type / example
      Added value: +"call"
  3. Addedv2.0.0

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the core action. It omits the default active-only filtering, the page_token pagination model, and the fact that expiration_date_lte defaults to the next weekend — all of which materially affect results.

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

Conciseness3/5

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

A single short sentence with no waste, but it is under-specified rather than concise — the brevity comes at the cost of routing and behavioral detail an agent needs.

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?

An output schema exists so return values need not be explained, but for a 14-parameter read tool with zero annotations the description should at minimum cover pagination and default filtering behavior. It leaves the agent without the context needed to use the tool predictably.

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 every parameter (enums, defaults, formats, the ppind explanation) is already documented in the schema. The description's mention of 'underlying symbol(s)' merely echoes the schema and adds no syntax or format detail beyond it, making baseline 3 appropriate.

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?

States a clear verb ('Retrieves') and resource ('option contracts') scoped to underlying symbol(s). However, it does not distinguish itself from the near-identical sibling get_option_contract (singular) or get_option_chain, so an agent cannot route between them from the description alone.

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 when-to-use guidance, no exclusions, and no mention of the obvious alternative get_option_contract for a single contract or get_option_chain for chain data. The agent is left to infer selection criteria entirely.

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

Deploy Server

Other Tools