mlp-tax

mlp_estate_planning

Read-onlyIdempotent

Computes §1014 stepped-up basis and estate-planning analysis for one or more direct MLP positions held until death, per IRC §1014(a) (basis at death), §1014(b)(6) (community-property double step-up), §751(a) (ordinary recapture eliminated at death), §731 (distributions), and §705 (basis). Returns total deferred federal tax eliminated, §751 ordinary recapture eliminated, per-beneficiary inheritance split, community-property double-step-up amount when applicable, and the dollar advantage of holding to death versus selling today.

Use when: User has one or more direct MLP positions (EPD, ET, MPLX, WES, PAA, NRP, USAC, SUN) and wants to quantify the §1014 step-up benefit for estate planning, compare holding to death versus selling now across a portfolio, model community-property double step-up for spouses in CA/TX/WA/etc., or compute per-beneficiary inheritance values across multiple heirs.

Don't use for: Trust-based estate strategies (revocable trusts preserve §1014; irrevocable trusts and IDGTs typically destroy it — this tool models direct holdings only). Single-position long-horizon tax projection — use mlp_projection. Single-position sell-now-versus-hold-to-death break-even — use mlp_sell_vs_hold. 1099-DIV ETFs (AMLP, MLPX, AMZA — RIC structure receives §1014 step-up but has no §751 to eliminate because no K-1; the analysis is materially different).

Limitations: Direct unit holdings only — does not model trust, IDGT, FLP, or charitable structures (these can destroy the §1014 benefit; for guidance on trust selection, see lucasandersen.ai). Federal-level only — does not include state estate tax. §751 recapture eliminated at death is estimated; 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

TableJSON 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)
`community_property`	No	Whether positions are in a community property state (doubles step-up)

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description builds on that by disclosing limitations: it only models direct holdings, excludes state estate tax, and notes that §751 elimination is estimated. It also provides a link to a basis workpaper. This adds useful context beyond annotations, though it could explicitly state that it does not persist data (though annotations cover that).

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 (purpose, outputs, use cases, limitations) and is front-loaded with the main function. However, it is somewhat lengthy due to boilerplate like the maintenance note and methodology link. Every sentence adds value, but some trimming could improve conciseness without losing important context.

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?

Given the complexity of the tool (4 parameters, no output schema), the description is quite complete. It explains the function, outputs, use cases, and limitations. It does not describe the exact return format, but it lists the specific outputs. The annotations provide readOnly and idempotent hints. The description is sufficient for an AI agent to understand what the tool does and when to use it, though it could elaborate on how parameters affect results.

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 75%, and the description does not add significant detail about individual parameters beyond what is in the schema. It mentions the overall input of 'one or more direct MLP positions' and implies parameters like tax_bracket and beneficiaries from the output description, but it does not explain how tax_bracket is used or how units and purchase_price interact. The schema provides some descriptions (e.g., positions, beneficiaries, community_property), so the description adds marginal value.

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 clearly states the tool computes §1014 stepped-up basis and estate-planning analysis for direct MLP positions held until death, citing specific IRC sections. It lists specific return outputs and distinguishes from siblings by naming alternative tools for different use cases (e.g., mlp_projection, mlp_sell_vs_hold). The verb 'computes' and resource 'estate-planning analysis' are specific and unambiguous.

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 that provide clear guidance on when to apply this tool versus alternatives. It names sibling tools (mlp_projection, mlp_sell_vs_hold) and excludes trust-based strategies, ETFs, and other structures. This is exceptional guidance for an AI agent to decide when to invoke the tool.

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

All mlp-tax 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 has a clearly distinct purpose: single-year basis, multi-year basis, estate planning, info lookup, long-term projection, and sell-vs-hold analysis. The 'Don't use for' sections further eliminate ambiguity, making it easy for an agent to select the correct tool.

Naming Consistency4/5

Tool names use a consistent snake_case convention with domain prefixes ('k1_' for basis tools, 'mlp_' for others). While the pattern is not strictly verb_noun (e.g., 'k1_basis_compute' has verb after noun, and 'mlp_estate_planning' is noun_gerund), the naming is clear and predictable, with only minor deviations from a uniform pattern.

Tool Count5/5

With 6 tools, the server is well-scoped for its domain of MLP tax calculations. Each tool addresses a specific, essential use case without redundancy, and the count is neither too sparse nor too heavy for a specialized tax calculator.

Completeness4/5

The tool set covers the core MLP tax scenarios: single-year and multi-year basis, long-term projection, estate planning, sell-vs-hold comparison, and reference data. A minor gap is the lack of multi-position or multi-lot optimization, but that is explicitly noted as beyond scope, and the server feels complete for its intended purpose.

Resources

Need Help?