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 (Lines 1-14) per IRC §705 (basis computation), §731(a) (distributions exceeding basis), §733 (basis reduction), §751 (hot asset recapture), §752 (liability allocation), §1014 (stepped-up basis at death), and §199A (QBI deduction). Returns year-by-year basis erosion, §751 accumulation, annual federal tax, terminal FMV, §1014 step-up value at death, 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, deferred tax eliminated by §1014 step-up at death, or the unit price at which selling matches holding through inheritance. Single position, single lot.

Don't use for: 1099-DIV ETFs (AMLP, MLPX, AMZA — these use RIC structure, pay corporate-level tax, and issue 1099-DIV instead of K-1; use a standard cost-basis calculator instead). 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

TableJSON Schema

Name	Required	Description
`units`	Yes	Number of MLP units held
`years`	No	Projection horizon in years (1-50, default 20)
`ticker`	Yes	MLP ticker symbol
`tax_bracket`	No	Federal marginal rate as decimal, e.g. 0.32 (default 0.32)
`purchase_price`	No	Purchase price per unit in USD (optional — defaults to reasonable estimate)

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses limitations: single position/single lot, federal-level only, and estimated §751 recapture based on default ROC assumptions. It also states the methodology (IRS Partner's Basis Worksheet, IRC sections) and notes what values are returned, providing rich behavioral context without contradicting annotations.

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 description is well-structured with clear sections (core computation, use cases, exclusions, limitations) and front-loads the primary functionality. However, the final paragraph about the author and methodology link is not strictly necessary for an agent to invoke the tool and slightly dilutes conciseness, so 4 rather than 5.

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?

Given the tool's complexity (multi-year MLP tax projection, multiple IRC sections) and the absence of an output schema, the description thoroughly explains return values (year-by-year basis erosion, terminal FMV, break-even sell price) and constraints (single position, federal-only, estimated recapture). It provides enough context for an agent to decide and correctly invoke the tool, making it complete.

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?

The input schema already covers 100% of parameters with descriptions, including defaults and enum choices (e.g., 'ticker' has an explicit enum list, 'years' has range 1-50). The description adds no new parameter-specific syntax or format details beyond the schema; its limitations about single lot and federal-level align with but do not extend the schema. Therefore baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Computes a multi-year tax projection for a publicly traded MLP position.' It details exact outputs (basis erosion, §751 accumulation, annual federal tax, §1014 step-up, break-even sell price), and the 'Don't use for' section explicitly distinguishes siblings like k1_basis_compute, k1_basis_multi_year, and mlp_estate_planning.

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?

The description includes explicit 'Use when' and 'Don't use for' sections with named alternatives (e.g., 'use k1_basis_compute (single year) or k1_basis_multi_year' for actual K-1 data, 'use mlp_estate_planning' for multi-position estate analysis). It also states exclusions like 1099-DIV ETFs (AMLP, MLPX, AMZA) with reasoning.

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

All MLP Tax Computation Engine tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a very specific and distinct use case: single-year basis, multi-year basis, long-term projection, estate planning, sell-vs-hold decision, and reference data lookup. The descriptions clearly state when to use each and (crucially) when not to, making selection unambiguous.

Naming Consistency4/5

Tool names mostly follow the pattern of domain prefix followed by the specific operation (e.g., k1_basis_compute, mlp_projection, mlp_sell_vs_hold). The naming is clear, though 'mlp_estate_planning' is a full phrase rather than verb_noun, which is a minor deviation from an otherwise strong pattern.

Tool Count5/5

With 6 tools covering basic reference, single-year basis, multi-year basis, projection, estate planning, and sell-vs-hold decision, the count is well-scoped for the domain. Each tool serves a clear purpose, and there is no bloat or missing critical functionality for the stated MLP tax and estate analysis use cases.

Completeness5/5

The tool set provides complete coverage of the MLP tax and estate planning lifecycle: retrieving reference data, computing single-year and multi-year basis, projecting future tax scenarios, comparing sell vs. hold, and analyzing estate step-up benefits. All major decision points and IRC sections are addressed, leaving no obvious gaps for a direct MLP holder.

Resources

Need Help?