Deterministic MLP tax computation engine. 6 tools: basis projection, estate planning, sell vs hold comparison, MLP vs ETF tax analysis, distribution stress test, and MLP reference data. Returns IRS-cited calculations for K-1 basis tracking, §751 recapture, and §199A QBI.
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.
| 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 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.
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.
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.
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.
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.
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.
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.
| 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=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.
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.
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.
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.
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.
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.
Computes §1014 stepped-up basis and estate-planning analysis for one or more direct MLP positions held until death, per IRC §1014(a) (basis at death), §1014(b)(6) (community-property double step-up), §751(a) (ordinary recapture eliminated at death), §731 (distributions), and §705 (basis). Returns total deferred federal tax eliminated, §751 ordinary recapture eliminated, per-beneficiary inheritance split, community-property double-step-up amount when applicable, and the dollar advantage of holding to death versus selling today.
Use when: User has one or more direct MLP positions (EPD, ET, MPLX, WES, PAA, NRP, USAC, SUN) and wants to quantify the §1014 step-up benefit for estate planning, compare holding to death versus selling now across a portfolio, model community-property double step-up for spouses in CA/TX/WA/etc., or compute per-beneficiary inheritance values across multiple heirs.
Don't use for: Trust-based estate strategies (revocable trusts preserve §1014; irrevocable trusts and IDGTs typically destroy it — this tool models direct holdings only). Single-position long-horizon tax projection — use mlp_projection. Single-position sell-now-versus-hold-to-death break-even — use mlp_sell_vs_hold. 1099-DIV ETFs (AMLP, MLPX, AMZA — RIC structure receives §1014 step-up but has no §751 to eliminate because no K-1; the analysis is materially different).
Limitations: Direct unit holdings only — does not model trust, IDGT, FLP, or charitable structures (these can destroy the §1014 benefit; for guidance on trust selection, see lucasandersen.ai). Federal-level only — does not include state estate tax. §751 recapture eliminated at death is estimated; 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) | |
| community_property | No | Whether positions are in a community property state (doubles step-up) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description builds on that by disclosing limitations: it only models direct holdings, excludes state estate tax, and notes that §751 elimination is estimated. It also provides a link to a basis workpaper. This adds useful context beyond annotations, though it could explicitly state that it does not persist data (though annotations cover that).
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-structured with clear sections (purpose, outputs, use cases, limitations) and is front-loaded with the main function. However, it is somewhat lengthy due to boilerplate like the maintenance note and methodology link. Every sentence adds value, but some trimming could improve conciseness without losing important context.
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?
Given the complexity of the tool (4 parameters, no output schema), the description is quite complete. It explains the function, outputs, use cases, and limitations. It does not describe the exact return format, but it lists the specific outputs. The annotations provide readOnly and idempotent hints. The description is sufficient for an AI agent to understand what the tool does and when to use it, though it could elaborate on how parameters affect results.
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 75%, and the description does not add significant detail about individual parameters beyond what is in the schema. It mentions the overall input of 'one or more direct MLP positions' and implies parameters like tax_bracket and beneficiaries from the output description, but it does not explain how tax_bracket is used or how units and purchase_price interact. The schema provides some descriptions (e.g., positions, beneficiaries, community_property), so the description adds marginal value.
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 clearly states the tool computes §1014 stepped-up basis and estate-planning analysis for direct MLP positions held until death, citing specific IRC sections. It lists specific return outputs and distinguishes from siblings by naming alternative tools for different use cases (e.g., mlp_projection, mlp_sell_vs_hold). The verb 'computes' and resource 'estate-planning analysis' are specific and unambiguous.
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 includes explicit 'Use when:' and 'Don't use for:' sections that provide clear guidance on when to apply this tool versus alternatives. It names sibling tools (mlp_projection, mlp_sell_vs_hold) and excludes trust-based strategies, ETFs, and other structures. This is exceptional guidance for an AI agent to decide when to invoke the tool.
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 (Lines 1-14) per IRC §705 (basis computation), §731(a) (distributions exceeding basis), §733 (basis reduction), §751 (hot asset recapture), §752 (liability allocation), §1014 (stepped-up basis at death), and §199A (QBI deduction). Returns year-by-year basis erosion, §751 accumulation, annual federal tax, terminal FMV, §1014 step-up value at death, 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, deferred tax eliminated by §1014 step-up at death, or the unit price at which selling matches holding through inheritance. Single position, single lot.
Don't use for: 1099-DIV ETFs (AMLP, MLPX, AMZA — these use RIC structure, pay corporate-level tax, and issue 1099-DIV instead of K-1; use a standard cost-basis calculator instead). 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?
Even though annotations already declare readOnlyHint=true and idempotentHint=true, the description adds extensive behavioral context: limitations (single position, single lot, federal-only), estimation details (§751 recapture from default ROC assumptions), and what the return values are. This goes far beyond the annotation hints.
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 long but every section earns its place: purpose, return values, use cases, exclusions, limitations, and maintenance context. It is structured with clear paragraph breaks and front-loaded with the core computation, making it efficient despite the length.
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?
For a complex tool with no output schema, the description covers all necessary context: what it returns, when to use, when not to use, limitations, and methodology references. It even states the expected inputs (MLP tickers, single lot) and the absence of state-level calculations. This is comprehensive for an AI agent to select and invoke the tool 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 input schema provides 100% coverage with clear descriptions for all 5 parameters. The tool description itself does not add additional parameter-level meaning beyond the schema, though it does reinforce constraints like 'single position, single lot' that relate to the tool's scope rather than individual parameters. Baseline 3 is appropriate given high schema coverage.
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 opening sentence states a specific verb ('Computes') and resource ('multi-year tax projection for a publicly traded MLP position'), with detailed methodology. It also distinguishes from siblings by explicitly naming alternatives like mlp_estate_planning and k1_basis_compute, making the purpose unambiguous.
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 includes explicit 'Use when' and 'Don't use for' sections, providing clear context for when to choose this tool and when to select a sibling tool. It names exact alternatives (e.g., 'use mlp_estate_planning', 'use k1_basis_compute') and describes non-qualifying scenarios like 1099-DIV ETFs.
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 (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.
| 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) | |
| community_property | No |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
k1_basis_computek1_basis_multi_yearmlp_estate_planningmlp_infomlp_projectionmlp_sell_vs_holdClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
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.
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.
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.
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.