Options Profit Calculator

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

Annotations already declare readOnlyHint and openWorldHint; the description adds real context beyond them — the grid is bounded by the earliest expiry, and calculatorUrl implies an external dependency on optionsprofitcalculator.com. It does not mention computation cost or how large the returned grid can be, which is a minor gap.

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

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

Three short sentences, front-loaded with the differentiator ('Everything probability_of_profit returns, plus...') then the use case, then the calculator URL note. Slightly dense opening clause but no wasted text.

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

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

With 7 parameters, no output schema, and coverage at 86%, the description usefully describes what comes back (P/L grid plus calculatorUrl) and the graph's date bound. It leaves return shape details (grid size, units per cell) unspecified, but the essential calling information is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 86%, so the schema already documents nearly every parameter and default. The description only indirectly touches priceMin/priceMax via the 'grid of stock prices' wording and the earliest-expiry cutoff; it adds no syntax or default detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific computation ('P/L in dollars across a grid of stock prices and dates up to the earliest expiry') and explicitly positions itself as a superset of probability_of_profit, so an agent can distinguish it from all siblings without opening a schema.

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

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

Gives clear usage contexts ('chart a position', 'see how profit changes over time') and implies the lighter sibling probability_of_profit when only POP data is needed. It stops short of an explicit 'use X instead when...' exclusion, so it is strong but not complete routing guidance.

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

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

Annotations already cover readOnlyHint and openWorldHint, and the description goes beyond them by disclosing the ranking function (return on max risk, with return on margin for naked short options) and the result shape (up to 5 items, each with a calculatorUrl). It does not mention rate limits, data freshness, or latency from the external site, which would have pushed it to a 5.

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

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

A single front-loaded sentence that leads with the action and the selection criterion before the ranking detail and return shape. Dense but no filler; the only cost is that the parenthetical about margin slightly interrupts the flow.

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

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

With 7 parameters, no output schema and an external open-world dependency, the description does the important work: it names the data source, the ranking metric, the result cap and one field of each result. Gaps are minor — budget-driven position sizing and the exactExpiry broadening behavior are left entirely to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 86%, so the schema already documents date, price, budget, symbol, target and exactExpiry well. The description adds only one piece of real parameter meaning — that results are either single options or vertical spreads, which frames the strategies enum — and says nothing about how budget sizing or the target eq/gt/lt modifier affect the search.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (find), a specific resource (options / vertical spreads) and the exact selection criterion (a price target by a date) plus the upstream service, optionsprofitcalculator.com. This is clearly distinguishable from siblings like get_option_chain (enumerate a chain) and calculate_position (score a given position).

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

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

The scenario that selects this tool — you already have a target price and date and want candidates — is implied clearly by the wording, but the description never names an alternative (get_option_chain, probability_of_profit, calculate_position) or states when not to use it. An agent must infer the routing decision from the sibling names alone.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful return context (expiry dates, days to expiry, strike counts) and the data source, but says nothing about completeness (all expirations? weeklies/monthlies?), ordering, or data freshness.

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

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

The definition is a single front-loaded sentence with no filler. It is efficient, though the passive 'listed' phrasing is slightly awkward and it leaves out a natural chaining hint that would earn the fifth point.

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

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

With no output schema, the description must carry some return-value burden, and it does name the key fields. However, for a discovery tool feeding get_option_chain, it omits how to use the results and whether expirations are exhaustive, which leaves a meaningful gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single required symbol parameter with 100% schema description coverage, so the schema already explains it fully. The description does not add any format, normalization, or symbol-resolution details beyond the schema, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: listing option expiry dates for a given symbol, and names the payload fields (days to expiry, number of strikes). It does not explicitly distinguish itself from siblings like get_option_chain or find_options, which likely also touch expirations, so it stops short of a 5.

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

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

Usage is implied rather than stated: an agent can infer this is the discovery step before get_option_chain, but the description never says when to use this versus the chain or find_options. No exclusions, prerequisites, or alternatives are named.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and external-dependency profile is covered. The description adds genuinely useful context by warning the data is delayed (freshness/accuracy caveat) and naming the upstream site, but says nothing about rate limits, failure modes, or staleness window.

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

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

A single front-loaded sentence with the caveat (delayed), the key extra output (IV30), and the source — no filler whatsoever.

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

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

For a one-parameter read-only lookup with full schema coverage and annotations, this is nearly complete: it tells the agent what comes back (quote + IV30), how fresh it is (delayed), and where it comes from. Only return-shape details (price fields, units) are absent, which is minor given no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter exists and schema coverage is 100%, with the schema itself giving the ticker example (AAPL). The description adds no format rules (exchange suffixes, case handling), so it neither compensates nor needs to; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource (fetch a delayed stock quote) and adds the distinguishing payload (IV30) plus the data source (optionsprofitcalculator.com), which separates it from options-focused siblings like get_option_chain and find_options. It stops short of explicitly naming a sibling, so a 4.

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

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

Usage is only implied: an agent infers you call this to get a ticker's price/IV. There is no statement of when to prefer it over get_option_chain or probability_of_profit, and no prerequisites or exclusions are given.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantive behavior beyond that: missing prices and IVs are backfilled from current market data, probability is computed at the earliest expiry using a lognormal model on 30-day implied volatility, and calculatorUrl opens the position on an external site. It stops short of covering failure modes or rate limits, but the model assumptions are unusually well disclosed.

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

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

Four dense sentences, front-loaded with what is calculated and for what instrument, followed by input defaults, model assumptions, and the calculatorUrl return behavior. No sentence is redundant and nothing important is buried.

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

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

For a complex multi-leg options calculation with no output schema, the description covers the returned metrics, the calculation model, the expiry used, input backfilling, and the external URL behavior. Combined with read-only annotations, an agent has enough to call it correctly without further documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, so the schema already documents most fields, but the description adds meaning the schema does not: the cap of 8 option legs plus 1 stock leg, the fact that omitted price and IV values are auto-filled from market data, and that probability is evaluated at the earliest expiry. This meaningfully reduces ambiguity about how partial inputs are treated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific calculation (probability of profit, breakevens, max profit and max loss) for a specific resource (an options position) and names the external engine that performs it. It also states the leg composition limit, making the tool's scope immediately distinguishable from generic siblings like calculate_position.

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

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

Usage is implied by the leg-composition constraint and the note that omitted prices and IVs are filled from market data, which tells an agent it can call with sparse inputs. However, it never says when to prefer this over calculate_position or how it relates to find_options, get_expirations, or get_option_chain, so the agent must infer routing.

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