Skip to main content
Glama

MLP Tax Computation Engine

mlp_sell_vs_hold

Read-onlyIdempotent

Compares selling an MLP position today (the §751(a) ordinary amount plus capital gain on the rest, R-751-BIFURCATION) against holding it with no sale by the holder through the projection horizon, per IRC §199A (qualified PTP income, including §751(a) gain attributable to the PTP's trades or businesses; R-199A-PTP-751-PAL) and §1411. Returns the break-even sell price: the unit price above which selling today produces more in this projection than holding with no sale (holding counts the projected value with no tax deducted, plus net distributions). It also returns the tax a sale by the holder at the projected value would carry, which is not a measure of tax saved or avoided at death; the successor's tax is not computed. If the units pass at death, the successor's basis is generally the fair market value at that date (or the §2032 alternate value where the executor elects), increased by the successor's share of partnership liabilities on that date and reduced to the extent the value is attributable to income in respect of a decedent, outside basis only; the partnership's basis in its property, from which the §751 amount on a later sale is figured, is adjusted only with a §754 election or a substantial built-in loss immediately after the transfer (R-1014-PTP-STEP-UP).

Use when: User holds a direct MLP position (EPD, ET, MPLX, WES, PAA, NRP, USAC, SUN), is approaching a sell decision, and wants a single break-even threshold to compare against the current market price. Useful for time-sensitive sell decisions, retirement-distribution planning, or comparing an unsolicited tender offer with continuing to hold.

Don't use for: Multi-position portfolio sell-ordering — this tool models a single position. For estate-planning analysis across multiple positions and beneficiaries, use mlp_estate_planning. For long-horizon basis-erosion modeling without a sell decision in view, use mlp_projection. 1099-DIV ETFs (AMLP, MLPX, AMZA): this tool does not model them.

Limitations: Single position, single lot — for portfolio-wide optimal sell ordering across multiple positions and lots, see lucasandersen.ai. Break-even price assumes the supplied tax bracket persists through the hold horizon. §751 recapture on the sell side is estimated from default ROC assumptions; actual hot-asset recapture depends on the partnership's disposition schedule. A year-by-year basis workpaper for this position is available at https://lucasandersen.ai/tax/k1-basis-tracker?src=mcp&tool=mlp_sell_vs_hold&surface=description.

Maintained by Lucas Andersen, MS Finance, with direct positions in major midstream MLPs. Methodology auditable at lucasandersen.ai/methodology.

Input Schema

NameRequiredDescriptionDefault
unitsYes
tickerYes
years_heldNoYears the position has been held (default 10)
tax_bracketNo
purchase_priceNo
years_to_projectNoYears to project the hold scenario (default 10)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / community_property
      Removed value: -{
      -  "type": "boolean"
      -}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description goes well beyond them: it discloses what is NOT computed (successor's tax, tax-saved-at-death), states the assumptions baked into the break-even (bracket persists through the horizon, §751 recapture estimated from default ROC), and limits scope to a single position and single lot. This is unusually candid about model boundaries for a read-only 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.

Conciseness3/5

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

The structured 'Use when / Don't use / Limitations' scaffolding is well front-loaded, but the second sentence is an extremely dense, clause-stacked §1014/§754 paragraph and the closing author bio, methodology link, and tracked URL are promotional filler that does not help an agent invoke the tool.

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?

With no output schema, the description correctly discharges the burden by stating both returned quantities (break-even sell price, tax a sale at projected value would carry). For a 6-parameter tool it stops short of explaining the remaining input semantics, but nothing blocks a correct call given the required ticker and units.

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 only 33% (only years_held and years_to_project are documented), so the description must compensate. It partially does — the ticker list matches the enum and the bracket-persistence caveat implies tax_bracket's role — but units and purchase_price are never given semantic meaning (e.g., unit count basis for the §751(a) split, basis for the capital-gain leg), leaving real gaps.

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 names a specific operation (compare selling an MLP position today vs. holding with no sale) and a specific output (the break-even sell price). It explicitly scopes itself against siblings mlp_estate_planning and mlp_projection, so an agent can route correctly without opening any schema.

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 carries explicit 'Use when' criteria (direct MLP position, approaching a sell decision, wanting a single break-even threshold against market price) and an explicit 'Don't use for' list naming the alternatives for portfolio ordering, estate planning, and long-horizon projection. Alternatives and exclusions are both stated, not inferred.

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