optionsahoy-mcp
Server Details
Equity comp tax (ISO/NSO/RSU/QSBS), concentration & hedging. 50-state tax code, multi-year.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- AlvisoOculus/optionsahoy-mcp
- GitHub Stars
- 0
- Server Listing
- Equity Comp Tax (ISO/NSO/RSU/QSBS), Concentration & Hedging Optimizer
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.2/5 across 6 of 6 tools scored.
Each tool addresses a distinct equity compensation scenario (ISO optimization, concentration risk, NSO calculation, protective puts, QSBS qualification, RSU decisions) with no functional overlap. An agent can easily differentiate their purposes.
Most tools follow a noun_verb pattern (e.g., concentration_analyze, rsu_sell_vs_hold), but 'amt_iso_optimize' and 'protective_put_price' deviate slightly (adjective_noun_verb or noun_noun). Overall consistent enough for clear intent.
With 6 tools, the set is tightly scoped to core equity compensation needs. Each tool serves a specific function without redundancy, making the count ideal for an MCP server.
Covers ISOs, NSOs, RSUs, QSBS, concentration risk, and hedging. Missing employee stock purchase plans (ESPPs) or tax-loss harvesting, but the surface is comprehensive for the intended domain.
Available Tools
6 toolsamt_iso_optimizeBRead-onlyIdempotentInspect
Multi-year Incentive Stock Option (ISO) exercise schedule that maximizes after-tax Net Final Value (NFV) at the planning horizon. NFV is the after-all-tax cash equivalent of the position at year horizon, summing exercised shares (held to LTCG) plus the time-valued tax stream paid along the way; the optimizer chooses the per-year share allocation that lands the highest NFV across all feasible schedules. When the user asks for "maximum value", "best schedule", or "optimal exercise plan", report NFV (in dollars) as the primary headline — schedules.optimized.nfv is the recommended plan; compare it against schedules.lumpSum.nfv and schedules.evenSplit.nfv to show the value delta from the optimization. Use this tool for ISO planning; for NSO grants use nso_calculate, for RSUs at vest use rsu_sell_vs_hold, for §1202 QSBS qualification use qsbs_check. Models AMT credit recovery across future years, grant-expiration timing, and the post-termination exercise window. Pure deterministic computation: no network access, no PII retention; federal + 50-state tax tables and AMT brackets are compiled in. The optimizer searches the full feasible share-per-year space (exhaustive, not heuristic). Returns a top-level object with keys: schedules (object containing lumpSum, evenSplit, and optimized — each {nfv, federalLTCG, stateLTCG, amtPremiumFV, grossGain}), crossoverShares (max shares that can be exercised in year 1 before tentative AMT exceeds regular tax), crossoverBargain, alreadyInAmt (boolean), timing (grant expiration / qualifying disposition / 90-day window flags), stateHasAmt, bargainPerShare, effectiveHorizon, and departedRecommendation when applicable. Example call: {shares: 10000, strike: 2, fmv: 200, expectedGrowth: 0.15, volatility: 0.5, filingStatus: "married_joint", ordinaryIncome: 400000, stateCode: "CA", carryforwardCredit: 0, horizon: 4, cashReturnRate: 0.05, grantDate: "2022-01-15", hasLeftCompany: false, terminationDate: null}. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| fmv | Yes | Current fair market value per share, USD. Anchors year-1 of the growth path; future years compound from here using expectedGrowth and volatilityDrag. | |
| shares | Yes | Total Incentive Stock Option (ISO) shares available to exercise across the planning horizon. | |
| strike | Yes | Strike price per share, USD. | |
| ticker | No | Optional 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. | |
| horizon | Yes | Planning horizon in years (1..10). The optimizer searches all feasible per-year share allocations across this many years. | |
| grantDate | Yes | ISO grant date (YYYY-MM-DD). Drives the 10-year statutory grant expiration (IRC §422) and the 2-year qualifying-disposition threshold from grant. | |
| stateCode | Yes | Two-letter US state code (e.g. CA, NY, TX). Drives state ordinary brackets, state long-term capital gains (LTCG) treatment, and state AMT (CA, CO, CT, MN). | |
| volatility | No | Annualized 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. | |
| filingStatus | Yes | Federal filing status. Drives the ordinary-bracket walk, the AMT exemption tier ($90,100 single / $140,200 MFJ for 2026), and the AMT exemption phaseout start ($500,000 single / $1,000,000 MFJ). | |
| cashReturnRate | Yes | Annual after-tax return on idle cash (decimal), used to time-value the cash-tax stream. 0.05 = 5% (~short-Treasury yield). Required. The model MUST NOT invent this value; ask the user (e.g. "what after-tax yield should I use for idle cash, e.g. ~5% for short-term Treasury?"). At 0 the math collapses to a nominal sum. | |
| expectedGrowth | No | Annual expected stock growth as a decimal (0.10 = 10%). Required unless `ticker` resolves it from trailing CAGR. | |
| hasLeftCompany | Yes | True if the user has separated from the company. Activates the 90-day post-termination ISO exercise window measured from terminationDate. | |
| ordinaryIncome | Yes | Annual W-2 ordinary income before this exercise, USD. Baseline for the bracket walk and the AMT exemption phaseout. | |
| terminationDate | Yes | Separation date (YYYY-MM-DD) when hasLeftCompany=true; null when still employed. Together with hasLeftCompany, drives the 90-day exercise window deadline. | |
| carryforwardCredit | Yes | Existing federal AMT credit (Minimum Tax Credit, Form 8801) carryforward from prior tax years, USD. Recoverable in future years where regular federal tax exceeds tentative minimum tax. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions the optimization considers credit recovery, expiration timing, and post-termination window, but does not explain assumptions, data requirements, or limitations for a complex financial tool.
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 description is concise with three sentences, front-loading the purpose and outputs. It avoids unnecessary details, though using bullet points or sections could improve readability for complex information.
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?
Given the tool's complexity (14 required parameters, no output schema, no annotations), the description is insufficient. It does not explain the return format, optimization algorithm, or how to interpret results, leaving agents without critical context for invocation.
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?
With 0% schema description coverage, the description should compensate by explaining key parameters. It mentions some parameters (e.g., expectedGrowth, volatilityDrag) in context but does not define their meaning, units, or required formats, leaving significant ambiguity for a 14-parameter tool.
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 clearly states the tool's purpose: optimizing multi-year ISO exercise to minimize AMT. It specifies the resource (ISO exercise schedule) and verb (minimizes), and distinguishes from sibling tools focused on other stock compensation strategies.
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 description implies usage for ISO AMT optimization but does not explicitly state when to use this tool versus alternatives like nso_calculate or rsu_sell_vs_hold. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
concentration_analyzeBRead-onlyIdempotentInspect
Single-stock concentration risk analysis on an existing position. For standalone hedge pricing use protective_put_price; for the tax math on the option exercise or RSU vest that created the concentration, route to amt_iso_optimize / nso_calculate / rsu_sell_vs_hold first. Quantifies drawdown exposure at 30/50/70% downside, then compares three after-tax strategies over a three-year horizon (sell-down to target weight, hold, hedge with put or zero-cost collar), accounting for federal LTCG, state tax, the 3.8% Net Investment Income Tax (NIIT), and reinvestment opportunity cost. totalAssets (concentrated position + everything else) frames risk relative to the portfolio and MUST come from the user, never inferred. Returns a top-level object with keys: concentration (position/totalAssets), riskBand (Low / Moderate / Concentrated / Highly concentrated / Extreme), isLongTermToday, longTermDate, daysUntilLongTerm, lossExposure ({drop, dollarLoss, newConcentration} for 30/50/70% drops), waitForLtInsight, schedule (yearly sales with per-year tax), hedging (NFV + cost when hedgeChoice provided), sectorContextLine, advisorBenchmarkLine. Example call: {positionValue: 400000, costBasis: 100000, acquisitionDate: "2022-01-01", sector: "tech_software", stateCode: "CA", filingStatus: "single", ordinaryIncome: 200000, totalAssets: 1200000, volatility: 0.45, ticker: "NVDA"}. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | Yes | Sector tag. Drives the default volatility used in the hedge-cost computation when no explicit volatility is provided. See lib/markets/sector-stats.ts for the per-sector annualVol table; this tool applies IV_OVER_RV_MULTIPLIER (1.20) to the realized vol to approximate implied vol. | |
| ticker | No | Optional 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. | |
| costBasis | Yes | Total cost basis of the position, USD (sum of strikes paid + ordinary-income inclusions on RSU vest / NSO exercise / disqualified ISO). | |
| stateCode | Yes | Two-letter US state code. Drives state LTCG and ordinary brackets. | |
| volatility | No | Annualized volatility (sigma) of the stock as a decimal (0.72 = 72%). Pass the user-supplied volatility directly; the tool uses it both for hedge pricing (as implied vol) and for the 3y horizon drag, computed 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; only when neither is supplied does hedge pricing fall back to sector_stats.annualVol × 1.20. | |
| hedgeChoice | No | Optional hedge specification. When provided, adds a hedged scenario to the sell-down-vs-hold comparison and computes the post-tax NFV of the hedged hold. Omit to compare only sell-down vs. hold. | |
| totalAssets | Yes | Total investable portfolio in dollars (concentrated position + everything else). User-supplied; never inferred. If the user did not state it, ASK. | |
| filingStatus | Yes | Federal filing status. Drives LTCG brackets and the NIIT MAGI threshold. | |
| positionValue | Yes | Current market value of the concentrated single-stock position, USD. | |
| ordinaryIncome | Yes | Annual W-2 ordinary income before any sales, USD. Baseline for LTCG bracket determination. | |
| acquisitionDate | Yes | Earliest acquisition date in the lot (YYYY-MM-DD). Drives the 1-year LTCG threshold and the long-term-vs-short-term tax routing. | |
| expectedMarketReturn | No | Annual after-tax-proceeds reinvestment rate. Defaults to SPY trailing CAGR for the 3-year horizon if omitted. | |
| expectedPositionReturn | No | Annual expected return on the concentrated stock as a decimal (0.10 = 10%). Required unless `ticker` resolves it from trailing CAGR. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description lacks behavioral disclosures such as whether the tool is read-only, requires authorization, has side effects, or handles errors. It does not describe the return format or any constraints beyond the input schema.
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 description is a single, front-loaded sentence that efficiently captures the tool's core function. However, given the complexity (13 parameters, nested objects), slightly more structure could improve clarity without sacrificing conciseness.
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 13 parameters, zero schema description coverage, no output schema, and no annotations, the description is too sparse. It does not explain the output format, prerequisites, or how to use the nested 'hedgeChoice' parameter, leaving significant gaps for an agent to invoke the tool correctly.
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 0%, and the description adds minimal parameter-level meaning. It mentions high-level concepts (drawdown levels, tax math) but does not explain individual parameters like stateCode, filingStatus, or hedgeChoice. The description fails to compensate for the lack of schema descriptions.
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 uses specific verbs ('quantify') and resources ('single-stock concentration risk') and clearly lists analytical actions (drawdown exposure, after-tax comparison, multi-year tax math). It distinguishes itself from sibling tools that focus on other tax optimization topics.
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 description implies usage for concentration risk analysis but provides no explicit guidance on when to use this tool versus alternatives (e.g., not for broad portfolio analysis). No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nso_calculateARead-onlyIdempotentInspect
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 betweenholdandsellNowInvest.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.
| Name | Required | Description | Default |
|---|---|---|---|
| shares | Yes | Non-qualified Stock Option (NSO) shares to exercise. | |
| strike | Yes | Strike price per share, USD. | |
| ticker | No | Optional 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. | |
| holdYears | Yes | Years to hold after exercise (minimum 1). At ≥1 year, the appreciation since exercise is LTCG; sub-1-year holds are out of scope. | |
| stateCode | Yes | Two-letter US state code. Drives state ordinary and LTCG treatment. | |
| volatility | No | Annualized 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. | |
| holdFunding | Yes | How 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). | |
| currentPrice | Yes | Current fair market value per share, USD. The bargain element at exercise is shares × (currentPrice − strike). | |
| filingStatus | Yes | Federal filing status. Drives ordinary brackets and LTCG brackets used at the hold horizon. | |
| stillEmployed | Yes | True if still employed at exercise. FICA (Social Security + Medicare + Additional Medicare) applies only when true. | |
| ordinaryIncome | Yes | Annual W-2 ordinary income before this exercise, USD. Baseline for the bracket walk on the bargain element. | |
| expectedSalePrice | No | Projected $/share at end of holdYears. Required unless `ticker` resolves it from currentPrice × (1 + trailing CAGR)^holdYears. | |
| expectedMarketReturn | No | Annual after-tax-proceeds reinvestment rate. Defaults to SPY trailing CAGR for holdYears if omitted. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It transparently lists the tax types (federal, state, FICA) and the comparison strategy, but does not disclose underlying assumptions or limitations, which is acceptable for a calculation tool.
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?
Two concise sentences, front-loaded with the core purpose and key comparisons, containing no filler.
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 12 required parameters and no output schema, the description provides a good overview but lacks detail on parameter dependencies, calculation steps, or return format. Incomplete for a complex tool.
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 0% and the description does not explain individual parameters. It only mentions high-level inputs; missing details on how each parameter (e.g., haircut, holdFunding) affects the calculation.
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 clearly states the tool calculates after-tax payout for NSO exercise and compares sell-at-exercise vs hold-for-capital-gains. It distinguishes from siblings like amt_iso_optimize which targets ISO, making the specificity clear.
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 description implies usage for NSO by naming it, but does not explicitly say when to use it over sibling tools or provide exclusions. The context of NSO versus ISO is implied, but no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
protective_put_priceBRead-onlyIdempotentInspect
Black-Scholes pricing of a protective put or zero-cost collar on a single-stock position. Use for standalone hedge pricing on a single-stock position; for concentration-vs-hedge tax-cost comparison, use concentration_analyze with a hedgeChoice. Parameter interactions an agent should know: volatility omitted falls back to sector_stats[sector].annualVol × 1.20 (the implied-over-realized vol multiplier); supply an explicit sigma when the user provides one. For collars, omitting upsideCapPct lets the tool back-solve the cap that zeros the net premium (truly zero-cost collar); supplying upsideCapPct overrides the solver and yields a non-zero net premium when the cap is wider than zero-cost. tenorYears drives the risk-free-rate lookup AND the floor-hit / cap-hit probability metrics, so changing tenor shifts every probability output even at fixed strike. expectedReturn affects only the probability metrics (real-world drift in the floor-hit / cap-hit calculations); premium math is risk-neutral and ignores it (default 0). protectionLevel sets the put strike as (1 − protectionLevel) × spot; raising it widens the protected zone but raises premium roughly linearly. Closed-form, deterministic, offline: sector volatility table and risk-free-rate curve compiled in. Reports annualized hedge cost as a percentage of position value, maximum loss with the hedge in place, upside-participation cap (collar only, since the short call offsets the long put premium), and probability of hitting the protection floor over the tenor. Returns a top-level object with keys: inputs (echoed canonical input), riskFreeRate (used in Black-Scholes), realWorldDrift (from expectedReturn), barePut (strike, premium, annualCost, annualCostPct, maxLoss, badYearPrice, badYearDropPct, coveredLossAtBadYear, premiumToCoveredRatio, expectedProfit, premiumToExpectedProfitRatio), collar (putStrike, callStrike, netPremium, annualCost, annualCostPct, maxLoss, upsideCap, upsideCapPct, isZeroCost, capProbability), payoffTable, payoffRange, and recommended (the better of bare put vs collar given the inputs). Both barePut and collar blocks are always returned regardless of caller preference; the caller picks. Example call: {positionValue: 400000, sector: "tech_software", protectionLevel: 0.10, tenorYears: 1}. IMPORTANT: every field listed in required must come from the user's message. The model invoking this tool MUST NOT invent a value for any required field. If the user did not supply it, ask the user. For enum fields that accept unsure, pass unsure when the user does not know; do not guess yes/no.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | Yes | Sector tag. Drives the default volatility when no explicit `volatility` is supplied. Lookup table is in lib/markets/sector-stats.ts. | |
| tenorYears | Yes | Option tenor in years. 1 = 12-month; 0.25 = ~90-day. | |
| volatility | No | Annualized implied volatility (sigma) of the stock. Defaults to a sector-typical IV when omitted. The model SHOULD NOT invent this. Either pass an explicit value the user gave you, or omit it and let the sector default apply. | |
| tickerLabel | No | Optional display string echoed back in the result. Not used in pricing. | |
| positionValue | Yes | Market value of the underlying single-stock position, USD. Premium and max-loss scale linearly with this. | |
| expectedReturn | No | Annual expected stock return (decimal). Drives risk-neutral drift in the cap-hit / floor-hit probability metrics. Does not affect premium math. Default 0. | |
| protectionLevel | Yes | Put strike as (1 − this fraction) × spot. 0.10 = 10% OTM put. Range 0.05..0.50. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists outputs (annual cost, max loss, upside cap, bad-year coverage) and the tool's action (pricing) but omits critical behavioral details like the valuation model used (e.g., Black-Scholes), assumptions (e.g., no dividends, continuous hedging), data sources, or error handling. With no annotations, the description carries the full burden and falls short.
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 description is extremely concise (two short sentences) and front-loaded with the primary action. Every word adds value; there is no repetition or irrelevant detail. It efficiently conveys the tool's purpose and key outputs.
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?
Given the complexity of pricing options (7 parameters, financial domain), the description is insufficient. It lists some outputs but does not explain the pricing methodology, assumptions, return format, or error conditions. Without an output schema, the description should be more thorough to guide correct usage.
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?
The input schema has 7 parameters with 0% coverage (no property descriptions), yet the tool description provides no explanations for any parameter. It does not define what 'sector', 'protectionLevel', 'volatility', or 'tenorYears' mean in the pricing context. The description adds no value beyond the schema's type/enum constraints.
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 clearly specifies the verb 'price' and the resource 'protective put or zero-cost collar on a single-stock position'. It distinctly sets the tool apart from its siblings, which deal with equity compensation (AMT, ISO, NSO, RSU, QSBS) rather than options strategies.
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 description implies the tool is for pricing options strategies but offers no explicit guidance on when to use it versus alternatives, nor does it mention when not to use it. Given the distinct sibling tools, the lack of explicit guidance is a missed opportunity but not critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qsbs_checkCRead-onlyIdempotentInspect
Section 1202 Qualified Small Business Stock (QSBS) qualification check. Use this tool for §1202 / QSBS qualification. For AMT timing on the ISO exercise that produced the QSBS holding, use amt_iso_optimize first. Parameter interactions an agent should know: entityType="other" short-circuits the verdict to does-not-qualify regardless of other fields; acquisitionMethod="secondary" does the same; assetCategory="over-75m" likewise fails immediately. Under acquisitionMethod="gift-or-inheritance" the holding period tacks from the original holder, so supply that earlier date as acquisitionDate if known. acquisitionDate drives era classification independent of holding period: before 2009-02-17 caps exclusion at 50%, 2009-02-17 to 2010-09-27 at 75%, 2010-09-28 through 2025-07-04 reaches 100% after a 5-year hold (pre-OBBBA), and 2025-07-05 onward uses the OBBBA tiered schedule (50% at 3y, 75% at 4y, 100% at 5y). The per-issuer exclusion cap is max($10M, 10 × adjustedBasis); when expectedGain exceeds it, the overage is fully taxable and the response surfaces taxableGain for that delta. industry is the dominant industry (>80% revenue) when the corp operates in multiple. Evaluates the eight statutory tests: domestic C-corporation entity, original-issuance acquisition method, gross assets at issuance (under $50M / $50-75M / over $75M tiered cap), qualified-trade-or-business industry, active-business posture (80% asset use), holding period (3 / 4 / 5-year tiers under OBBBA), adjusted basis, and expected gain at sale. Pure stateless check: no filing, reporting, or IRS lookup happens; the eight tests are evaluated against the bundled OBBBA 2026 rule set and per-state conformity table. Returns a top-level object with keys: verdict (qualifies / partial / does-not-qualify), exclusionPercent (0..1), perIssuerCap and tenXBasisCap (the two cap inputs), applicableCap (max of the two), excludableGain, taxableGain, federalTaxSaved (LTCG bracket on the excluded gain), stateConforms (full / partial / none) and stateNote (per-state explanation), holdingYears, yearsUntilFullExclusion, era (pre-2009 / 2009-2010 / pre-obbba / obbba), and tests (array of {id, label, status, detail} for each of the eight statutory tests so an agent can show which gate failed). Example call: {acquisitionDate: "2020-01-15", saleDate: "2026-06-01", entityType: "us-c-corp", acquisitionMethod: "original-issuance", assetCategory: "under-50m", industry: "tech-software", activeBusiness: "yes", adjustedBasis: 100000, expectedGain: 5000000, stateCode: "CA", ordinaryIncome: 250000, filingStatus: "single"}. IMPORTANT: every field listed in required must come from the user's message. The model invoking this tool MUST NOT invent a value for any required field. If the user did not supply it, ask the user. For enum fields that accept unsure, pass unsure when the user does not know; do not guess yes/no.
| Name | Required | Description | Default |
|---|---|---|---|
| industry | Yes | §1202 Test 4: Industry classification of the corporation. Qualified-trade-or-business industries qualify (tech-software, manufacturing, biotech-research, retail-wholesale, hospitality, etc.). Specified service trades or businesses (law, engineering, architecture, accounting-actuarial, consulting, finance, farming, extraction, health-services, performing-arts) generally do NOT qualify. | |
| saleDate | Yes | Planned or actual sale date (YYYY-MM-DD). Together with acquisitionDate determines holdingYears. | |
| stateCode | Yes | Two-letter US state code. Drives the state-conformity verdict: CA/AL/PA/MS do not conform (full state tax owed); HI/MA partial; NJ 2026-01-01 conformity switch; most others fully conform. | |
| entityType | Yes | §1202 Test 1: Type of issuer at the time of acquisition. Only 'us-c-corp' qualifies. S-corps, LLCs, partnerships, and foreign entities fail. | |
| expectedGain | Yes | Expected total gain on sale, USD. Compared against the per-issuer exclusion cap to compute excludableGain and taxableGain. | |
| filingStatus | Yes | Federal filing status. Drives the LTCG bracket on any non-excluded gain and the NIIT MAGI threshold. | |
| adjustedBasis | Yes | Adjusted basis of the QSBS shares, USD. Used in the 10× basis cap: the per-issuer exclusion cap is max($10M, 10 × adjustedBasis). | |
| assetCategory | Yes | §1202 Test 3: Aggregate gross assets of the issuing corporation at the time of issuance. 'under-50m' qualifies pre-OBBBA. '50m-to-75m' qualifies ONLY under OBBBA 2026+ (post-2025-07-05). 'over-75m' never qualifies. 'unsure' returns a partial verdict. | |
| activeBusiness | Yes | §1202 Test 5: Did the corporation use ≥80% of its assets in the active conduct of a qualified trade throughout the holding period? 'yes' qualifies. 'no' fails. 'unsure' returns a partial verdict (user should confirm with their CFO). | |
| ordinaryIncome | Yes | Annual W-2 ordinary income, USD. Baseline for the federal LTCG bracket on any taxable gain. | |
| acquisitionDate | Yes | Date the QSBS shares were acquired (YYYY-MM-DD). Drives the holding-period test and the era classification (50% pre-2009, 75% 2009-2010, 100% 2010-2025-07-04, OBBBA tiered after 2025-07-05). | |
| acquisitionMethod | Yes | §1202 Test 2: How the user obtained the shares. 'original-issuance' (direct from the company) qualifies. 'gift-or-inheritance' tacks the original holder's basis and clock. 'secondary' (bought on a secondary market) does NOT qualify. 'unsure' triggers a partial verdict. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It mentions checking eight tests and returning several outputs, but does not disclose side effects, error handling, or assumptions (e.g., does it require certain entity types?). The reference to 'OBBBA 2026 tiered exclusion rules' adds some legal context but not behavioral specifics.
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 description is a single sentence that efficiently states purpose and outputs. There is no wasted text, but it could be slightly more structured (e.g., bullet points for outputs) without harming conciseness.
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?
Given the tool's complexity (12 required parameters, no output schema, no parameter descriptions), the description is far from complete. An AI agent cannot determine how to set parameters like industry, assetCategory, or activeBusiness without further guidance. The description does not explain the eight tests or expected input values.
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 0%, and the description provides no parameter-level details. With 12 parameters including enums (e.g., industry, assetCategory, acquisitionMethod), the description fails to explain how parameters map to the eight statutory tests or what each value means. This leaves the AI agent unable to populate inputs correctly.
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 clearly states the tool performs a Section 1202 QSBS qualification check against eight statutory tests and lists specific outputs (verdict, exclusion percentage, tax saved, state conformity). This is a specific verb+resource that distinguishes it from sibling tools like amt_iso_optimize or nso_calculate.
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?
No guidance on when or when not to use this tool. There is no mention of prerequisites, alternative tools, or typical use cases. The description simply states what the tool does without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rsu_sell_vs_holdCRead-onlyIdempotentInspect
After-tax payout on a Restricted Stock Unit (RSU) vest: federal ordinary income tax, state income tax, FICA (Social Security + Medicare + Additional Medicare), and the gap between mandatory 22% federal supplemental withholding and the user's marginal bracket. Use this tool for RSUs at vest; for ISO/AMT planning use amt_iso_optimize, for NSO use nso_calculate. Compares sell-at-vest vs hold-for-long-term-capital-gains (LTCG) across the chosen horizon, accounting for the 12-month short-term-vs-long-term holding threshold and the optional expected-growth assumption. Pure deterministic computation: no network access; tax tables and the 22% supplemental-withholding rate are compiled in. Returns a top-level object with keys: vest (vestValue, federal, state, socialSecurity, medicare, additionalMedicare, total, netCashAtVest, federalWithheldAtVest), hold (expectedGain at horizon, capGainFederal/State/Total including NIIT, isLongTerm), sellNowInvest (counterfactual: sell at vest and reinvest at expectedMarketReturn), holdMinusSell (dollar delta), and bracketJump (fromRate, toRate, thresholdAtJump on the vest amount). Example call: {shares: 1000, currentPrice: 100, ordinaryIncome: 200000, filingStatus: "single", stateCode: "CA", stillEmployed: true, holdYears: 2, volatility: 0.3, ticker: "MSFT"}. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| shares | Yes | Restricted Stock Unit (RSU) shares vesting in this tranche. | |
| ticker | No | Optional 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. | |
| holdYears | Yes | Years to hold after vest (0.25..5). Below 1 year triggers the short-term capital gains cliff (ordinary rates on appreciation). | |
| stateCode | Yes | Two-letter US state code. | |
| volatility | No | Annualized 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. | |
| currentPrice | Yes | Fair market value per share at vest, USD. Also the cost basis on retained shares. | |
| filingStatus | Yes | Federal filing status. | |
| stillEmployed | Yes | True if still employed at vest. Drives FICA applicability and whether the 22% supplemental withholding rule applies. | |
| ordinaryIncome | Yes | Annual W-2 ordinary income before this vest, USD. Baseline for the bracket walk on the vest amount. | |
| expectedSalePrice | No | Projected $/share at end of holdYears. Required unless `ticker` resolves it from currentPrice × (1 + trailing CAGR)^holdYears. | |
| expectedMarketReturn | No | Annual after-tax-proceeds reinvestment rate. Defaults to SPY trailing CAGR for holdYears if omitted. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the tool 'compares' payouts but does not explain side effects (none expected for a calculator), inputs, or state changes. The description implies a read-only analysis tool but lacks explicit confirmation.
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 description is a single concise sentence that front-loads the tool's purpose. However, given the complexity (10 parameters), a structured breakdown would improve usability without harming conciseness.
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?
Despite the complexity of a financial analysis tool with 10 parameters and no output schema, the description omits critical context: what the output looks like, how assumptions are applied (e.g., growth assumption marked 'optional' but expectedMarketReturn is required), and the typical workflow. This leaves an AI agent with insufficient information to use the tool correctly.
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?
The schema has 10 required parameters with 0% coverage (no descriptions). The description loosely references 'state tax', 'FICA', and 'growth assumption' but fails to map specific parameters like 'ordinaryIncome', 'holdYears', or 'haircut' to their roles. Without schema descriptions, the tool description should compensate; it does not.
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 clearly states the tool compares two strategies (sell-at-vest vs hold-for-LTCG) for RSU vest payouts. It lists specific factors included (12-month cliff, state tax, FICA, growth assumption), differentiating it from sibling tools like amt_iso_optimize or nso_calculate which address other equity types.
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 description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or scenarios where the tool is appropriate. Sibling tools are listed in context but no comparative advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.