Skip to main content
Glama
AlvisoOculus

Equity Comp Tax (ISO/NSO/RSU/QSBS), Concentration & Hedging Optimizer

nso_calculate

Read-onlyIdempotent

Calculate after-tax payout for NSO exercise, comparing sell-at-exercise versus holding for long-term capital gains, including federal, state, and FICA taxes.

Instructions

After-tax payout on a non-qualified stock option (NSO) exercise: federal, state, and FICA (Social Security + Medicare + Additional Medicare), comparing sell-at-exercise vs hold-for-long-term-capital-gains over the chosen horizon. Use for NSOs; for ISOs use amt_iso_optimize, for RSUs use rsu_sell_vs_hold. Deterministic, offline; tax tables compiled in. Optional ticker resolves expectedSalePrice from a bundled trailing-CAGR snapshot.

Returns a top-level object with these keys:

  • exercise: bargainElement, federal, state, socialSecurity, medicare, additionalMedicare, total, netCashSellAll, sharesSoldToCover, sharesRetained.

  • hold: expectedGain, capGainFederal, capGainState, capGainTotal, isLongTerm at end of holdYears (LTCG triggers at holdYears ≥ 1).

  • sellNowInvest: counterfactual where shares are sold at exercise and proceeds reinvested at expectedMarketReturn.

  • holdMinusCashless: dollar delta between hold and sellNowInvest.

  • bracketJump: fromRate, toRate, thresholdAtJump describing the marginal bracket change at exercise.

Example call: {shares: 5000, strike: 10, currentPrice: 50, ordinaryIncome: 180000, filingStatus: "single", stateCode: "CA", stillEmployed: true, holdYears: 2, volatility: 0.3, holdFunding: "cash", ticker: "AAPL"}. IMPORTANT: every field listed in required must come from the user's message OR be derivable from an optional ticker. The model invoking this tool MUST NOT invent a value for any required field. If the user did not supply it and no ticker resolves it, ask the user.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sharesYesNon-qualified Stock Option (NSO) shares to exercise.
strikeYesStrike price per share, USD.
currentPriceYesCurrent fair market value per share, USD. The bargain element at exercise is shares × (currentPrice − strike).
ordinaryIncomeYesAnnual W-2 ordinary income before this exercise, USD. Baseline for the bracket walk on the bargain element.
filingStatusYesFederal filing status. Drives ordinary brackets and LTCG brackets used at the hold horizon.
stateCodeYesTwo-letter US state code. Drives state ordinary and LTCG treatment.
stillEmployedYesTrue if still employed at exercise. FICA (Social Security + Medicare + Additional Medicare) applies only when true.
holdYearsYesYears to hold after exercise (minimum 1). At ≥1 year, the appreciation since exercise is LTCG; sub-1-year holds are out of scope.
expectedSalePriceNoProjected $/share at end of holdYears. Required unless `ticker` resolves it from currentPrice × (1 + trailing CAGR)^holdYears.
volatilityNoAnnualized volatility (sigma) of the stock as a decimal (0.72 = 72%). Pass the user-supplied volatility directly; the tool computes the horizon-cumulative drag internally. The model MUST NOT compute drag itself — the correct formula is horizon-dependent and most models get it wrong. If the user does not supply a volatility number, ASK them.
expectedMarketReturnNoAnnual after-tax-proceeds reinvestment rate. Defaults to SPY trailing CAGR for holdYears if omitted.
tickerNoOptional public-stock symbol (e.g. "NVDA", "AAPL"). When set, the tool substitutes the ticker's trailing CAGR for any unsupplied expected-return / sale-price field instead of requiring the caller to invent one. ~90 symbols covered; unknown tickers fall through to "required field" errors so the model knows to ask the user.
holdFundingYesHow the strike cost and exercise tax are funded. 'sell-to-cover' sells enough shares to cover strike + tax (reduces sharesRetained). 'cash' pays from outside the position (full sharesRetained but requires the cashNeededAtExercise field).
Behavior4/5

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. Description adds that the tool is deterministic and offline with pre-compiled tax tables, and details the return structure. No contradiction.

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?

The description is well-structured with a clear purpose statement, bullet-pointed return keys, and a usage note. Every sentence serves a purpose without being overly verbose.

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?

No output schema, but the description lists all return keys in detail. The tool is complex with 13 parameters, yet the description covers high-level behavior, counterfactual analysis, and important edge cases (e.g., bracket jump, FICA condition).

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?

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the optional ticker resolution, the volatility computation warning, and the not-inventing-values guideline, going beyond schema details.

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 clearly states it calculates after-tax payout for NSO exercise, comparing sell-at-exercise vs hold for LTCG. It explicitly distinguishes from siblings by naming amt_iso_optimize and rsu_sell_vs_hold for other option types.

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?

Provides explicit 'Use for NSOs' and alternatives for ISOs and RSUs. Includes important guidelines like not inventing required field values and instructing to ask user for missing data.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AlvisoOculus/optionsahoy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server