mlp-tax

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.5/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true and idempotentHint=true, consistent with the description's computation-only nature. The description adds context on methodology (IRS worksheet), return values (ending basis, line values, gains, suspended losses), and limitations (single year, single lot, federal-only). No contradiction. Slightly less explicit about auth or rate limits, but acceptable for a read-only compute tool.

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 long but well-structured, front-loading the core purpose in the first sentence. Subsequent sections ('Use when', 'Don't use for', 'Limitations') are clearly labeled and each adds distinct value. Given the domain complexity (12 parameters, tax rules), the length is justified. Could be slightly trimmed, but still strong.

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 12 parameters, no output schema, and moderate annotations, the description explains what is returned (ending basis, worksheet line values, §731 gain, suspended losses) and covers methodology, limitations, and alternative tools. It does not specify the exact output JSON structure, but for a computation tool without an output schema, the level of detail is sufficient.

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 coverage is 75% (high), so baseline is 3. The description adds meaning by linking specific box numbers to IRC sections (e.g., §704(d) for loss limitation, §752 for liability changes) and explaining what each parameter represents (e.g., 'Item K liability change'). This goes beyond the schema's short descriptions, earning a 4.

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 begins with a specific verb ('Computes adjusted partner basis') and resource ('single year of Schedule K-1 data'), explicitly naming the IRS methodology and IRC sections. It clearly distinguishes from siblings by referencing k1_basis_multi_year for multi-year needs and other tools.

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 provides explicit 'Use when' conditions (direct MLP units, structured K-1 box values, single year, single lot) and 'Don't use for' exclusions (1099-DIV ETFs, multi-year carryforward, general partnerships), with alternative tools named (k1_basis_multi_year, standard cost-basis calculator).

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?