Skip to main content
Glama

Debit spread calculator

debit_spread
Read-onlyIdempotent

Call or put debit spread figures: width, maximum profit and loss, breakeven, reward to risk, debit-to-width, and the model's chance of profit when implied volatility and days are given.

Input Schema

NameRequiredDescriptionDefault
daysNoDays to expiration, for the chance of profit. Optional.
kindYescall for a call debit spread (bullish), put for a put debit spread (bearish).
debitYesNet debit paid per share, in dollars.
priceYesStock price in dollars.
iv_pctNoImplied volatility, percent per year, for the chance of profit. Optional.
contractsNoNumber of contracts. Default 1.
long_strikeYesThe strike bought, in dollars.
short_strikeYesThe strike sold, in dollars.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds valuable behavioral context by naming the exact computed outputs and by stating that chance of profit depends on implied volatility and days being supplied, which the annotations do not cover.

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

Conciseness5/5

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

A single front-loaded sentence with no wasted words. The resource and output list are presented immediately, making it easy for an agent to parse purpose and scope.

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?

There is no output schema, so the description usefully enumerates the return metrics an agent should expect. Combined with full schema coverage of inputs and rich annotations, the definition is mostly complete, though it does not explain calculation assumptions or edge-case behavior.

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 documents every parameter, including the optional days and iv_pct fields for chance of profit. The description repeats the IV/days condition but adds no syntax, format, or constraint details beyond the schema.

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 states a specific calculation resource (call or put debit spread figures) and enumerates the exact outputs: width, maximum profit and loss, breakeven, reward to risk, debit-to-width, and chance of profit. This clearly distinguishes it from sibling credit_spread by specifying debit spreads.

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 alternatives, and no conditions for choosing this over credit_spread, profit_calculator, or probability_of_profit. Usage is only implied by the phrase 'debit spread figures.'

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