Skip to main content
Glama

mlp-tax

by ai.lucasandersen.api

k1_basis_multi_year

Read-onlyIdempotent

Computes a running adjusted partner basis across multiple years of Schedule K-1 data, per IRC §705 (basis computation), §731(a)(1) (gain on distributions exceeding basis), §751(a) (accumulated ordinary recapture), §752 (liability share allocation across years), §704(d) (suspended-loss carryforward), and §1014(a) (step-up if death today). Returns year-by-year basis trajectory, accumulated §751 recapture estimate, projected zero-basis year, §1014 step-up value if death today, and the broker-basis gap — the dollar amount by which a typical 1099-B understates true IRS-adjusted basis.

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, identify the zero-basis year, quantify the gap between broker-reported basis and true IRS basis, or project §1014 step-up value if death occurred today.

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 — RIC structure, no K-1, no basis-erosion mechanism; use a standard cost-basis calculator). 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
unitsYes
tickerYes
k1_yearsYesArray of annual K-1 data, one per year held (max 50)
tax_bracketNo
purchase_yearNo
purchase_priceYes

TDQS

A4.1/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 bar for transparency is lower. The description adds context about the computation's legal basis (IRC sections), the specific outputs returned, and what it does not cover (state-level adjustments, multi-lot tracking). It consistently portrays a non-destructive read operation. However, it does not disclose the exact return format or any internal assumptions, keeping it from 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 front-loaded with the core purpose, followed by clear usage sections. It is somewhat lengthy but each sentence adds value. The inclusion of a promotional link and maintainer details slightly reduces conciseness. Overall, it is well-organized and efficient for its complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex (multi-year computation, six parameters, no output schema) and the description covers many aspects: purpose, usage, limitations, and supported tickers. However, it fails to compensate for the low schema coverage by not explaining the parameters in detail. The outputs are listed but not structured. Given the complexity, the description is moderately complete but has a clear gap in parameter documentation.

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

Parameters2/5

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

Schema description coverage is only 17% (one parameter, k1_years, has a description). The description does not compensate for the other five parameters (units, ticker, purchase_price, tax_bracket, purchase_year) — it does not explain their meaning, format, or relationship to the computation. The only parameter mention is the supported tickers listed in the 'Use when' section, but that is not a parameter description. With low schema coverage and no description elaboration, parameter semantics are weak.

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 opens with a specific verb ('Computes') and resource ('running adjusted partner basis across multiple years of Schedule K-1 data'), then lists exact outputs. It explicitly distinguishes from sibling tool k1_basis_compute by stating 'Don't use for: Single-year basis worksheet from one K-1 — use k1_basis_compute.' This meets the highest bar for purpose clarity.

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 contains a 'Use when:' section that specifies the exact scenario (direct MLP holdings, multiple K-1s, basis tracking needs) and a 'Don't use for:' section that lists three excluded cases with named alternatives (k1_basis_compute, mlp_projection, standard cost-basis calculator). It also provides limitations and a link for further support. This is exemplary usage guidance.

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

All mlp-tax toolsInspect
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