MLP Tax Computation Engine

k1_basis_compute

Read-onlyIdempotent

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 (basis computation), §722 (initial basis), §731(a)(1) (gain on distribution exceeding basis), §733 (basis reduction), §752 (liability share allocation), §704(d) (loss limitation and suspended-loss carryforward), and §199A (QBI deduction). 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 — these use RIC structure, no K-1, different tax regime — use a standard cost-basis calculator instead). 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.

Input Schema

TableJSON Schema

Name	Required	Description
`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

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint true, but the description adds context beyond that: it mentions return values (ending basis, worksheet lines, §731 gain, §704(d) suspended losses) and a reference to external methodology. No contradiction with annotations.

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?

At about 200 words, it is detailed but slightly verbose. The information is front-loaded with the core function and legal references, but the ending paragraph on maintenance and external links adds extra fluff. Could trim redundant legal citations and author bio.

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?

For a complex tax computation tool with 12 parameters, no output schema, and multiple legal considerations, the description covers purpose, usage, limitations, and return values. It lacks example inputs or output format, but provides external methodology link. The sibling distinction helps fill gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, so the schema already documents most parameters. The description adds meaning by grouping box values (e.g., 'Box 1 ordinary income', 'Box 19A cash distributions') and referencing key parameters in the usage context (e.g., 'Item K liability change'). Could be slightly more organized for the 12 parameters.

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 verb 'computes' and the resource 'adjusted partner basis from a single year of Schedule K-1 data', specifying the IRS methodology and legal code sections. It distinguishes itself from siblings by explicitly naming k1_basis_multi_year and contrasting with 1099-DIV ETFs.

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?

Provides explicit when-to-use via specific MLP tickers and K-1 box inputs, and when-not-to-use with alternatives for 1099-DIV ETFs (AMLP, MLPX, AMZA) and multi-year tracking (k1_basis_multi_year), plus general partnerships. Also lists limitations like single tax year, single lot, federal-only.

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?