MLP Tax Computation Engine

mlp_estate_planning

Read-onlyIdempotent

Computes an estate view for one or more direct MLP positions with no sale by the holder, per IRC §705, §731 and §751(a), with §1014(a) cited for the successor's basis at death (R-1014-PTP-STEP-UP). Returns the projected market value, the tax a sale by the holder at that value would carry and its §751 amount (each position priced as if sold alone; not a measure of tax saved or avoided at death; the successor's tax is not computed), the projected value less adjusted basis, a per-beneficiary split, and the difference between holding with no sale and selling today. 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). The community-property option is withdrawn: a call with community_property true is rejected.

Use when: User has one or more direct MLP positions (EPD, ET, MPLX, WES, PAA, NRP, USAC, SUN) and wants the projected value and, if the units pass at death, the successor's basis proxy (the projected value before the liability-share and IRD adjustments) across a portfolio, a comparison of holding with no sale against selling now, or per-beneficiary values across several beneficiaries.

Don't use for: Units held in a trust, IDGT, FLP or charitable structure (this tool models direct holdings only). Single-position long-horizon tax projection — use mlp_projection. Single-position sell-now-versus-hold break-even — use mlp_sell_vs_hold. 1099-DIV ETFs (AMLP, MLPX, AMZA): this tool does not model them.

Limitations: Direct unit holdings only; does not model trust, IDGT, FLP or charitable structures. Does not compute estate tax, federal or state. The §751 amount is estimated from default ROC assumptions; the exact figure depends on the partnership's actual hot-asset 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_estate_planning&surface=description.

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

Input Schema

Name	Required	Description
`positions`	Yes	Array of MLP positions to analyze (max 20)
`tax_bracket`	No
`beneficiaries`	No	Number of beneficiaries (default 1, max 20)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

removedInput schema / properties / community_property

Removed value: -{
-  "description": "Whether positions are in a community property state (doubles step-up)",
-  "type": "boolean"
-}

First observedApr 15, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds substantial beyond-annotation context: no estate tax computed, §751 estimated from default ROC assumptions, successor's tax not computed, and that a community_property=true call is rejected. It stops short of describing return structure or pagination, so a 4 is appropriate.

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 purpose is front-loaded and the use/don't-use routing is efficient, but the §1014/§2032 legal digression is dense and the closing promotional links and author credentials (with UTM parameters) do not help tool selection and dilute the section. Sizeable waste for a 3-parameter 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 carries the return-value burden and does so well, enumerating projected market value, sale tax, §751 amount, value-less-basis, per-beneficiary split, and hold-vs-sell delta. Limitations and excluded structures are also stated, leaving little for an agent to infer.

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 coverage is 67%, so the schema already documents positions and beneficiaries. The description clarifies positional scope (direct holdings, one or more positions, max 20 implied) but leaves tax_bracket unexplained and references community_property, which is not even in the schema — a mildly confusing detail. Baseline 3 fits.

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 first sentence states a specific verb (Computes) and resource (estate view for direct MLP positions with no sale) and cites the governing code sections, then names the exact sibling tools it is not (mlp_projection, mlp_sell_vs_hold). An agent can distinguish it from siblings 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?

Explicit 'Use when' block enumerates qualifying scenarios (portfolio view, successor basis proxy, hold-vs-sell comparison, per-beneficiary split) and a 'Don't use for' block names the alternatives (mlp_projection, mlp_sell_vs_hold) with their distinct triggers plus unsupported structures. Routing is unambiguous.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?