quantra-mcp

Overview Schema Source Related Servers Discussions Admin

price_equity_option

Prices vanilla equity options (Call/Put; European, American, Bermudan) from user-supplied market data and returns NPV plus delta, gamma, vega, theta, and rho.

Instructions

Price a vanilla equity option (POST /price-equity-option).

Args: market_data_source: where the market numbers in this call come from. user_pasted (the user pasted or typed the numbers in this conversation), user_file (the user attached a file/screenshot the numbers were read from), engine_example (an engine example's pricing block, only when the user explicitly asked to run an example), session (a market previously stored in this session, which itself came from one of the above). There is no value for estimated, recalled or placeholder data. If you would have to invent numbers, do not call this tool: ask the user for the data. spot: spot price (a Price quote the tool adds) or a quote id in the market. strike, expiry (YYYY-MM-DD), option_type Call | Put. vol: {constant: 0.2, id?} (constant BlackVolSpec added) or a surface id. rate_curve: {rate, end_date, id?} (flat continuous zero curve from as_of to end_date, added) or a curve id in the market. dividend_yield: same shape ({rate: 0.0, end_date} for no dividends); the engine requires a dividend curve id on every underlying. preset: a preset with an equity_option block (default EUR_EQUITY). exercise: European | American (window exercise_start..expiry; start default = as_of) | Bermudan (exercise_dates, last = expiry). model: {type: BlackScholesAnalytic|BinomialCRR, binomial_steps?, id?} or a model id; default BlackScholesAnalytic (id bs_analytic). discrete_dividends: [{ex_date, amount}] cash dividends on the underlying. market: optional; a pricing block / market with curves, quotes or surfaces to reference by id. as_of is required without it.

summary.options: npv, delta, gamma, vega, theta, rho.

Input Schema

TableJSON Schema

Name	Required	Default
`vol`	Yes
`spot`	Yes
`as_of`	No
`model`	No
`expiry`	Yes
`market`	No
`preset`	No	EUR_EQUITY
`strike`	Yes
`exercise`	No	European
`quantity`	No
`trade_id`	No
`rate_curve`	Yes
`request_id`	No
`option_type`	Yes
`underlying_id`	No	EQ
`dividend_yield`	Yes
`exercise_dates`	No
`exercise_start`	No
`additional_trades`	No
`calendar_overrides`	No
`discrete_dividends`	No
`market_data_source`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.4Oct 7, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose meaningful side effects and constraints: the tool adds Price quotes / zero curves / vol specs to the market, dividend_yield is mandatory because "the engine requires a dividend curve id on every underlying", as_of is required without a market, and exercise-window defaults are spelled out. Auth, permissions and any limits are unstated.

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?

Front-loads purpose, then a tightly formatted Args block; sizing is appropriate for a 22-parameter tool. Minor waste in restating the trailing summary.options fields even though an output schema exists.

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 high-complexity tool with no annotations, the description covers the market-data provenance rule, defaults, reference-by-id semantics and exercise conventions, and the output schema carries the return contract. The remaining gap is the handful of undocumented secondary parameters.

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?

Top-level schema description coverage is 0%, so the description must compensate, and it does for most parameters: all market_data_source enum values, the vol/rate_curve/dividend_yield shapes, preset default (EUR_EQUITY), exercise variants, model options and discrete_dividends. Still silent on quantity, trade_id, underlying_id, additional_trades and calendar_overrides.

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?

Opens with a specific verb+resource ("Price a vanilla equity option") plus the underlying endpoint, which is enough to separate it from the many sibling pricers (price_vanilla_swap, price_swaption, price_cap_floor, etc.) without reading the schema. Nothing vague or tautological.

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?

Gives explicit when-not guidance for market_data_source ("There is no value for estimated, recalled or placeholder data. If you would have to invent numbers, do not call this tool: ask the user for the data") and explains the id-vs-inline reference choice for vol, rate_curve, dividend_yield and model. It does not, however, route the agent to sibling helpers (build_curve, build_query, curve_from_pasted_table) when a curve/surface must be constructed first.

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

Deploy Server