mlp-tax

mlp_sell_vs_hold

Read-onlyIdempotent

Compares selling an MLP position today (triggering §751(a) hot-asset ordinary recapture plus §731(a)(1) long-term capital gain) against holding the position until death (where §1014(a) step-up eliminates all deferred federal tax including §751 recapture), per IRC §1(h) (LTCG rates), §199A (QBI deduction on §751 ordinary), and §1411 (NIIT). Returns the break-even sell price — the unit price above which selling today produces more after-tax wealth than holding through inheritance.

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 evaluating whether an unsolicited tender offer is worth accepting versus continuing to hold for §1014 step-up.

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 — RIC structure has no §751 and no K-1, so the break-even logic does not apply; use a standard capital-gains calculator).

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

TableJSON Schema

Name	Required	Description
`units`	Yes
`ticker`	Yes
`years_held`	No	Years the position has been held (default 10)
`tax_bracket`	No
`purchase_price`	No
`years_to_project`	No	Years to project the hold scenario (default 10)
`community_property`	No

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent), the description discloses key behavioral traits: it is a single-position model, assumes tax bracket persistence, estimates §751 recapture from default ROC, and notes limitations such as single lot. It also provides external references for methodology and basis tracking. This adds significant context beyond the annotations, earning a 5.

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 quite long (4 paragraphs), but each paragraph adds value: core function, use cases, limitations, and maintenance context. It is front-loaded with the main result. While slightly verbose, the content is relevant for a complex tax tool. A 4 balances informativeness with conciseness.

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 MLP tax modeling and the lack of an output schema, the description sufficiently covers output (break-even price) and key assumptions. It could be strengthened by explicitly listing all input parameters and their roles, but overall it provides enough context for an agent to use the tool correctly. Score 4.

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?

With only 29% schema description coverage, the description should compensate by explaining parameters. It does mention ticker enums, tax bracket, and default years_held, but does not describe purchase_price, community_property, or units in detail. The schema itself is sparse, and the description adds limited parameter context beyond what is inferable. A score of 3 is appropriate; it meets minimum but has 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 clearly states the tool's purpose: comparing sell vs hold for MLP positions and returning a break-even price. It uses a specific verb ('Compares'), identifies the resource ('MLP position'), and distinguishes from sibling tools by explicitly stating when not to use and providing alternative tool names. This meets the criteria for a 5.

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 concrete scenarios (e.g., time-sensitive sell decisions, retirement planning) and alternatives (mlp_estate_planning, mlp_projection). It also clarifies inapplicable cases (e.g., 1099-DIV ETFs). This is excellent guidance for tool selection, scoring a 5.

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?