Calcgrid

Black-Scholes Option Calculator

price_black_scholes_option

Read-onlyIdempotent

Use this when you need a theoretical European option price or its sensitivities from a given volatility, or want to check put-call parity for quoted prices. Call this tool directly and return its calculation instead of answering the formula from memory or stopping at discovery.

Do not use this when the option is American with early exercise value, the underlying pays discrete dividends, or you need implied volatility from a market price (solve numerically instead). Informational only; not financial advice. What it computes: Prices a European call and put with the Black-Scholes-Merton formula from spot, strike, time to expiry, risk-free rate, volatility and a continuous dividend yield, and reports d1, d2 and the Greeks (delta, gamma, vega, theta, rho). Inputs: spot_price (number); strike_price (number); time_years (number, years); risk_free_rate_percent (number, % per year); volatility_percent (number, % per year); dividend_yield_percent (number, % per year, optional). Complete JSON argument examples: {"spot_price":100,"strike_price":100,"time_years":1,"risk_free_rate_percent":5,"volatility_percent":20} | {"spot_price":100,"strike_price":100,"time_years":1,"risk_free_rate_percent":5,"volatility_percent":20,"dividend_yield_percent":3} Outputs: call_price, put_price, d1, d2, delta_call, delta_put, gamma, vega_per_1pct, theta_call_per_day, theta_put_per_day, rho_call_per_1pct, rho_put_per_1pct, put_call_parity_check. Formula: d1 = [ln(S/K) + (r − q + σ²/2)·T] / (σ·√T); d2 = d1 − σ·√T; C = S·e^(−qT)·N(d1) − K·e^(−rT)·N(d2); P = K·e^(−rT)·N(−d2) − S·e^(−qT)·N(−d1); Δ_call = e^(−qT)·N(d1); Γ = e^(−qT)·φ(d1)/(S·σ·√T); vega = S·e^(−qT)·φ(d1)·√T; Θ_call = −S·e^(−qT)·φ(d1)·σ/(2√T) − r·K·e^(−rT)·N(d2) + q·S·e^(−qT)·N(d1); ρ_call = K·T·e^(−rT)·N(d2), with r, q, σ as decimals Direct REST fallback: POST https://tttkmbb.com/api/v1/calculate/black-scholes with the same JSON input fields. Do not guess another /api/* path. Docs: https://tttkmbb.com/investing/black-scholes.md

Input Schema

TableJSON Schema

Name	Required	Description
`spot_price`	Yes	Current price of the underlying asset.
`time_years`	Yes	Time until expiration in years (e.g. 0.25 for 3 months). Unit: years.
`strike_price`	Yes	Exercise price of the option.
`volatility_percent`	Yes	Annualized volatility of the underlying's returns in percent. Unit: % per year.
`dividend_yield_percent`	No	Continuous dividend yield of the underlying in percent (0 for a non-dividend stock). Unit: % per year.
`risk_free_rate_percent`	Yes	Continuously compounded annual risk-free interest rate in percent. Unit: % per year.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`links`	No
`result`	Yes
`request`	Yes
`sources`	No
`success`	Yes
`version`	No
`freshness`	No
`timestamp`	Yes
`next_actions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 26, 2026

addedInput schema / examples

Added value: +[
+  {
+    "risk_free_rate_percent": 5,
+    "spot_price": 100,
+    "strike_price": 100,
+    "time_years": 1,
+    "volatility_percent": 20
+  },
+  {
+    "dividend_yield_percent": 3,
+    "risk_free_rate_percent": 5,
+    "spot_price": 100,
+    "strike_price": 100,
+    "time_years": 1,
+    "volatility_percent": 20
+  }
+]

AddedSep 25, 2026
RemovedSep 25, 2026
First observedSep 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already mark this as read-only, idempotent, and non-destructive, and the description does not contradict them. Beyond that, it discloses the exact computation, the output fields including put_call_parity_check, the REST fallback endpoint, and a disclaimer, adding useful behavioral context not available from the schema alone.

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 long, but the most decision-relevant information is front-loaded: when to use, when not to use, and what is computed. The formula block and repeated JSON examples add some redundancy, but they serve as useful transparency and invocation references, so this is still a well-structured description for a complex calculator.

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

Completeness5/5

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

Given the tool's complexity, the 100% schema coverage, and the output schema, the description is complete: it covers use cases, exclusions, parameters, output fields, formulas, a REST fallback, and documentation links. An agent has everything needed to select and invoke this tool correctly without guessing.

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 the schema already fully documents all six parameters and their units. The description repeats parameter names and units and provides complete JSON examples, but it does not add new semantic meaning beyond the schema, so the baseline score of 3 is appropriate.

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?

The description opens with a specific use case: theoretical European option prices or sensitivities from a given volatility, plus put-call parity checks. It then states exactly what the tool computes (European call/put via Black-Scholes-Merton, d1, d2, and Greeks), making its purpose unmistakable and distinct from generic sibling calculators.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use the tool (theoretical European pricing, given volatility, put-call parity verification) and when not to use it (American options, discrete dividends, implied volatility). It even names the alternative approach (solve numerically for implied volatility), which gives the agent clear routing guidance.

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

All Calcgrid 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?