Deterministic MLP tax engine with IRS citations. 6 tools: basis, §751, estate, projections.
Scored across 6 tools
Each tool has a distinct core purpose (single-year basis, multi-year basis, estate, info, projection, sell-vs-hold), and the descriptions include explicit 'Don't use for' routing that resolves most potential confusion. However, mlp_projection, mlp_sell_vs_hold, and mlp_estate_planning all return overlapping outputs (break-even sell price, tax-on-sale, hold-vs-sell comparison), so an agent could reasonably misselect among them.
All names use snake_case with logical k1_ / mlp_ prefixes and noun-verb structure (k1_basis_compute, mlp_sell_vs_hold). The two prefix families map to clear subdomains. Minor deviation: 'k1_basis_compute' uses a trailing verb while siblings like 'k1_basis_multi_year' and the mlp_* names are noun-first, so the verb placement is not fully uniform.
Six tools is well within the ideal 3-15 range and each maps to a genuine, non-redundant capability of an MLP tax engine (data lookup, single/multi-year basis, projection, sell analysis, estate). No padding or trivial tools.
The surface covers the core MLP tax lifecycle: reference data, K-1 basis (single and multi-year), forward projection, sell-vs-hold, and estate planning. The main gap is multi-lot and multi-position portfolio handling, which most tools explicitly refuse and redirect to an external site, plus no state-level computation — real but work-aroundable limitations for the stated scope.
Computes adjusted partner basis from a single year of Schedule K-1 data using the IRS Partner's Basis Worksheet methodology (Lines 1-14), per IRC §705, §722, §731(a)(1), §733, §752, §704(d) and §199A. Returns the ending adjusted basis, every worksheet line value, any §731 gain triggered when distributions exceed basis, and §704(d) suspended losses carried forward.
Use when: User holds direct MLP units (EPD, ET, MPLX, WES, PAA, NRP, USAC, SUN, or similar publicly traded midstream partnerships) and has structured K-1 box values for one tax year — Box 1 ordinary income, Box 19A cash distributions, Item K liability change, optionally Box 5 interest income, Box 11 §179 deduction, Box 13W §199A QBI amount. Single tax year, single lot.
Don't use for: 1099-DIV ETFs (AMLP, MLPX, AMZA): this tool does not model them. Multi-year basis carryforward across consecutive K-1s — use k1_basis_multi_year. General partnership interests outside publicly traded MLPs (different §1402 self-employment treatment).
Limitations: Single tax year only — for multi-year basis tracking with §731 gain detection across years, use k1_basis_multi_year. Single-lot only — for multi-lot allocation and optimal sell ordering, see lucasandersen.ai. Federal-level only — does not include state basis adjustments. Full multi-year basis reconstruction with a CPA-ready workpaper is available at https://lucasandersen.ai/private-partnership-k1-basis?src=mcp&tool=k1_basis_compute&surface=description.
Maintained by Lucas Andersen, MS Finance, with direct positions in major midstream MLPs. Methodology auditable at lucasandersen.ai/methodology.
| Name | Required | Description | Default |
|---|---|---|---|
| box1 | Yes | K-1 Box 1: ordinary business income (loss) | |
| box2 | No | K-1 Box 2: net rental income | |
| box5 | No | K-1 Box 5: interest income | |
| box11 | No | K-1 Box 11: §179 / other deductions | |
| units | Yes | ||
| box13w | No | K-1 Box 13W: §199A QBI amount | |
| box19a | Yes | K-1 Box 19A: cash distributions | |
| ticker | Yes | ||
| prior_basis | Yes | Beginning-of-year adjusted basis in USD | |
| tax_bracket | No | ||
| liability_decrease | No | §752(b) liability decrease in USD | |
| liability_increase | No | §752(a) liability increase in USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds genuine behavioral context the annotations cannot: the exact return contents (ending adjusted basis, every worksheet line value, §731 gain, §704(d) suspended losses) and the federal-only scope with no state basis adjustments. It does not mention auth, rate limits, or validation behavior, so it stops short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core content is front-loaded and useful, but the multi-year limitation is stated twice — once in 'Don't use for' and again in 'Limitations'. The closing marketing lines (two lucasandersen.ai URLs plus a positional-disclosure bio) do not help an agent invoke the tool correctly and dilute an otherwise tight definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 burden and does so: it enumerates the return payload (§731 gain, §704(d) carryforward, line values) and states the federal-only and single-year boundaries. What remains unaddressed is the semantic role of units and tax_bracket, which an agent must infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% and the description reinforces the key box mappings (Box 1, Box 19A, Box 5, Box 11, Box 13W) while translating 'Item K liability change' into the §752(a)/(b) increase/decrease parameters. It adds the regulatory framing (§704(d), §731(a)(1)) that makes those inputs meaningful, though it says nothing about the undocumented units or tax_bracket parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Computes adjusted partner basis from a single year of Schedule K-1 data' — and anchors it to a named methodology (IRS Partner's Basis Worksheet, Lines 1-14) with the governing code sections. It explicitly scopes itself as single-year/single-lot, which is exactly what distinguishes it from the k1_basis_multi_year sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Has explicit 'Use when' and 'Don't use for' sections. It names concrete qualifying instruments (EPD, ET, MPLX, WES, PAA, NRP, USAC, SUN) and the required input shape, then names the alternatives: 1099-DIV ETFs are out of scope, multi-year carryforward goes to k1_basis_multi_year, and non-publicly-traded general partnerships are excluded on §1402 grounds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes a running adjusted partner basis across multiple years of Schedule K-1 data, per IRC §705, §731(a)(1), §751(a), §752 and §704(d), with §1014(a) cited for the successor's basis at death (R-1014-PTP-STEP-UP). Returns year-by-year basis trajectory, accumulated §751 recapture estimate and projected zero-basis year.
Use when: User holds a direct MLP position (EPD, ET, MPLX, WES, PAA, NRP, USAC, SUN) across multiple consecutive tax years, has K-1s for those years, and wants to track adjusted basis year over year, or identify the zero-basis year.
Don't use for: Single-year basis worksheet from one K-1 — use k1_basis_compute. Long-horizon forward projection from default assumptions when no actual K-1s are in hand — use mlp_projection. 1099-DIV ETFs (AMLP, MLPX, AMZA): this tool does not model them. Multi-position portfolio basis tracking — this tool handles one position per call.
Limitations: Single position, single lot — for multi-lot or multi-position basis tracking with optimal sell ordering, see lucasandersen.ai. Federal-level only — does not include state-level basis adjustments. Accumulated §751 recapture is estimated across years; actual depends on the partnership's hot-asset disposition schedule and any year-specific §751(b) events. Full multi-year basis reconstruction with a CPA-ready workpaper is available at https://lucasandersen.ai/private-partnership-k1-basis?src=mcp&tool=k1_basis_multi_year&surface=description.
Maintained by Lucas Andersen, MS Finance, with direct positions in major midstream MLPs. Methodology auditable at lucasandersen.ai/methodology.
| Name | Required | Description | Default |
|---|---|---|---|
| units | Yes | ||
| ticker | Yes | ||
| k1_years | Yes | Array of annual K-1 data, one per year held (max 50) | |
| tax_bracket | No | ||
| purchase_year | No | ||
| purchase_price | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so safety is covered; the description adds real behavioral context: federal-only with no state adjustments, §751 recapture is an estimate dependent on hot-asset disposition schedules, and single-position/single-lot scope. It stops short of describing validation behavior or what happens with malformed/missing K-1 years, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The functional content is well front-loaded and cleanly segmented into Use when / Don't use for / Limitations. However, two sentences are promotional rather than operational — the lucasandersen.ai upsell link and the 'Maintained by...' bio — which dilute a signal tool document and add length without helping invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly fills the gap by naming the three returns (basis trajectory, §751 recapture estimate, zero-basis year) and qualifying their accuracy. Combined with the limitations block, an agent has enough to call it correctly; the only missing piece is parameter-level detail given the low schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, so the description must carry more of the load. It does contextualize the domain concepts that map to parameters (§752 liability adjustments, §704(d) limitations, §751 recapture) and names the ticker enum values, but it never explains box1, box11, box19a, liability_increase/decrease, tax_bracket or purchase_year semantics. Partial compensation for a genuine coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Computes a running adjusted partner basis across multiple years of Schedule K-1 data') plus the statutory framework and the concrete outputs (year-by-year trajectory, §751 recapture estimate, projected zero-basis year). It is instantly distinguishable from k1_basis_compute (single-year) and mlp_projection (forward projection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' conditions (direct MLP position, consecutive years of K-1s, year-over-year tracking) and an explicit 'Don't use for' block that routes the agent to named siblings: k1_basis_compute for single-year, mlp_projection for no-K-1 projections. It even excludes 1099-DIV ETFs and multi-position portfolios with the right alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| positions | Yes | Array of MLP positions to analyze (max 20) | |
| tax_bracket | No | ||
| beneficiaries | No | Number of beneficiaries (default 1, max 20) |
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.
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.
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.
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.
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.
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.
Returns reference data for a supported MLP ticker — current cash distribution per unit, distribution growth CAGR, default return-of-capital percentage, distribution coverage ratio, K-1 entity count, operating-state count, and last-verified date.
Use when: User wants to look up baseline characteristics of an MLP before modeling — e.g., comparing distribution coverage across partnerships, checking how many K-1 entities a holding generates for tax-prep complexity, or seeing the operating-state count for state-tax filing-burden estimation.
Don't use for: Tax computation. Use mlp_projection (long-horizon modeling), mlp_estate_planning (estate analysis), mlp_sell_vs_hold (break-even sell price), or k1_basis_compute / k1_basis_multi_year (computing basis from actual K-1 data).
Note: This tool returns reference data only — no IRC citations apply, no methodology disclosure attached. For computation, use the modeling tools above.
Maintained by Lucas Andersen, MS Finance.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful context beyond them: 'reference data only', 'no IRC citations apply, no methodology disclosure attached', and the presence of a 'last-verified date' which signals data freshness. This substantially clarifies what the tool does and does not provide, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and front-loaded: core output list first, then usage guidance, then exclusions and caveats. It is slightly verbose with minor redundancy ('use the modeling tools above' repeats the don't-use list) and the 'Maintained by' line adds little to tool selection or invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description enumerates all return fields, provides realistic use cases, and explicitly sets behavioral boundaries (reference data only, no IRC/methodology). For a simple one-parameter lookup with strong annotations, this is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, ticker, is fully constrained by the schema enum (8 supported tickers), and the description calls it a 'supported MLP ticker'. However, the prose adds little semantic detail beyond the schema's enumeration, and with 0% schema description coverage, the description only minimally compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Returns reference data for a supported MLP ticker' and enumerates the exact fields returned (cash distribution, CAGR, return-of-capital percentage, coverage ratio, K-1 entity count, operating-state count, last-verified date). This specific verb+resource+scope clearly distinguishes it from sibling modeling/computation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when' scenarios (baseline characteristic lookup, distribution coverage comparison, K-1 complexity assessment) and a 'Don't use for' section that names alternatives: mlp_projection, mlp_estate_planning, mlp_sell_vs_hold, k1_basis_compute, k1_basis_multi_year. This gives an agent clear decision rules for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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) |
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.
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.
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.
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.
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.
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.
Compares selling an MLP position today (the §751(a) ordinary amount plus capital gain on the rest, R-751-BIFURCATION) against holding it with no sale by the holder through the projection horizon, per IRC §199A (qualified PTP income, including §751(a) gain attributable to the PTP's trades or businesses; R-199A-PTP-751-PAL) and §1411. Returns the break-even sell price: the unit price above which selling today produces more in this projection than holding with no sale (holding counts the projected value with no tax deducted, plus net distributions). It also returns the tax a sale by the holder at the projected value would carry, which is not a measure of tax saved or avoided at death; the successor's tax is not computed. 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).
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 comparing an unsolicited tender offer with continuing to hold.
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): this tool does not model them.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description goes well beyond them: it discloses what is NOT computed (successor's tax, tax-saved-at-death), states the assumptions baked into the break-even (bracket persists through the horizon, §751 recapture estimated from default ROC), and limits scope to a single position and single lot. This is unusually candid about model boundaries for a read-only calculation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The structured 'Use when / Don't use / Limitations' scaffolding is well front-loaded, but the second sentence is an extremely dense, clause-stacked §1014/§754 paragraph and the closing author bio, methodology link, and tracked URL are promotional filler that does not help an agent invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly discharges the burden by stating both returned quantities (break-even sell price, tax a sale at projected value would carry). For a 6-parameter tool it stops short of explaining the remaining input semantics, but nothing blocks a correct call given the required ticker and units.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only years_held and years_to_project are documented), so the description must compensate. It partially does — the ticker list matches the enum and the bracket-persistence caveat implies tax_bracket's role — but units and purchase_price are never given semantic meaning (e.g., unit count basis for the §751(a) split, basis for the capital-gain leg), leaving real gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation (compare selling an MLP position today vs. holding with no sale) and a specific output (the break-even sell price). It explicitly scopes itself against siblings mlp_estate_planning and mlp_projection, so an agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It carries explicit 'Use when' criteria (direct MLP position, approaching a sell decision, wanting a single break-even threshold against market price) and an explicit 'Don't use for' list naming the alternatives for portfolio ordering, estate planning, and long-horizon projection. Alternatives and exclusions are both stated, not inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
mlp_estate_planning1 field changedInput schema / properties / community_propertyRemoved value: -{
- "description": "Whether positions are in a community property state (doubles step-up)",
- "type": "boolean"
-}mlp_sell_vs_hold1 field changedInput schema / properties / community_propertyRemoved value: -{
- "type": "boolean"
-}k1_basis_computek1_basis_multi_yearmlp_estate_planningmlp_infomlp_projectionmlp_sell_vs_hold9 deterministic IRS tax, RMD, Roth, Solo 401k, Form 1040, TALS, Estate & SBLOC calculators.
Deterministic cross-border tax engine: PE, GAAR, Indian TP, rule-level lookup. Compiled law, no LLM.
44 calculators for AI agents: US tax, finance, business + an MCP engineering & security suite.
Free, deterministic 530A (Trump Account) projections, verified rules, and searchable guides.
Add one secure layer between your agents and this server.
