Skip to main content
Glama

MLP Tax Computation Engine

mlp_projection

Read-onlyIdempotent

Computes a multi-year tax projection for a publicly traded MLP position, applying the IRS Partner's Basis Worksheet methodology per IRC §705, §731(a), §733, §751, §752 and §199A. Returns year-by-year basis erosion, §751 accumulation, annual federal tax, terminal FMV (the projected market value), the tax on a sale by the holder at that value (not a measure of tax saved or avoided at death; the successor's tax is not computed), and the break-even sell price.

Use when: User holds direct units of a midstream MLP (EPD, ET, MPLX, WES, PAA, NRP, USAC, SUN) and wants to model long-term tax outcomes — when basis reaches zero, total tax paid over the hold horizon, the tax a sale at the projected value would carry, or the unit price at which selling now matches holding with no sale. Single position, single lot.

Don't use for: 1099-DIV ETFs (AMLP, MLPX, AMZA): this tool does not model them. Multi-position estate analysis — use mlp_estate_planning. Computing basis from actual K-1 data the user has in hand — use k1_basis_compute (single year) or k1_basis_multi_year.

Limitations: Single position, single lot — for multi-position portfolios and per-lot optimal sell ordering, see lucasandersen.ai. Federal-level only — does not include state-level basis adjustments or state estate tax. §751 recapture is estimated from default ROC assumptions; actual recapture depends on the partnership's hot-asset disposition schedule.

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

Input Schema

NameRequiredDescriptionDefault
unitsYesNumber of MLP units held
yearsNoProjection horizon in years (1-50, default 20)
tickerYesMLP ticker symbol
tax_bracketNoFederal marginal rate as decimal, e.g. 0.32 (default 0.32)
purchase_priceNoPurchase price per unit in USD (optional — defaults to reasonable estimate)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover readOnlyHint and idempotentHint, so the description carries the rest and does so well: it discloses the governing methodology (IRC §705/§731(a)/§733/§751/§752/§199A), the estimation basis for §751 recapture, and the federal-only limitation excluding state adjustments and state estate tax. It also explicitly clarifies that the terminal-FMV tax is not a measure of tax saved at death, pre-empting a likely misinterpretation.

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

Conciseness4/5

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

The Use when / Don't use for / Limitations structure is well front-loaded and each limitation sentence carries real information. It loses a point for the promotional closing lines ('Maintained by Lucas Andersen, MS Finance...' and the lucasandersen.ai redirect for multi-position portfolios), which are not strictly needed to invoke the tool correctly.

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

Completeness5/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 fully enumerates the return values (year-by-year basis erosion, §751 accumulation, annual federal tax, terminal FMV, sale tax at that value, break-even sell price). For a five-parameter analytical tool it leaves no material gap an agent would need before calling it.

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% and includes defaults and an enum for ticker, so the schema already documents all five parameters. The description adds no parameter-level syntax or format guidance (e.g. how tax_bracket interacts with the projection), so the baseline 3 applies.

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 verb and resource ('Computes a multi-year tax projection for a publicly traded MLP position') and pins the scope to a single position, single lot. It is immediately distinguishable from siblings like k1_basis_compute and mlp_estate_planning, which are named directly.

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 has an explicit 'Use when' clause naming the asset class and tickers, plus a 'Don't use for' clause that routes three distinct cases to named alternatives (mlp_estate_planning, k1_basis_compute, k1_basis_multi_year). Nothing about tool selection is left to inference.

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