Deterministic MLP tax engine with IRS citations. 6 tools: basis, §751, estate, projections.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.7/5 across 6 of 6 tools scored.
Each tool serves a clearly distinct purpose: single-year vs multi-year basis from actual K-1s, long-term projection from defaults, estate planning, sell-vs-hold comparison, and reference data. The descriptions explicitly cross-reference each other and specify when not to use a tool, eliminating ambiguity.
Names follow a predictable pattern: tools based on actual K-1 data start with 'k1_' (k1_basis_compute, k1_basis_multi_year), while modeling tools start with 'mlp_' (mlp_projection, mlp_estate_planning, etc.). Minor inconsistency exists between 'compute' (verb) and 'multi_year' (adjective) within the k1_ prefix, but overall the convention is clear and readable.
Six tools is well-scoped for a specialized MLP tax domain. Each tool addresses a distinct workflow (basis computation, multi-year tracking, projection, estate planning, sell decision, reference lookup) without redundancy or bloat.
The tool surface covers the core MLP tax lifecycle: basis from actual K-1s (single and multi-year), forward-looking projection, estate planning with §1014 step-up, and sell-vs-hold break-even analysis. Minor gaps exist for multi-lot allocation and state-level adjustments, but these are explicitly noted as out of scope and do not impair the primary federal-level computation workflows.
k1_basis_computeAComputes 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.
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?
Goes well beyond annotations by detailing returns (ending adjusted basis, worksheet line values, §731 gain, §704(d) suspended losses) and limitations (single year, single lot, federal-only). Annotations readOnlyHint and idempotentHint are consistent with the read-only computation described, and the description adds rich behavioral context.
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 structured with clear sections (purpose, use, don't use, limitations, maintenance). Each section earns its place; it is thorough without being redundant. The front-loading of purpose makes it easy to grasp quickly.
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 tax basis computations and lack of output schema, the description fully enumerates outputs and limitations. It also provides auditability context, making the tool's behavior and boundaries clear for correct use.
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%, but the description maps key parameters to K-1 boxes (Box 1, Box 19A, Item K, Box 5, Box 11, Box 13W) and explains their role. It does not elaborate every parameter (e.g., box2, tax_bracket), but the description adds enough interpretive value beyond the schema.
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 and resource: 'Computes adjusted partner basis from a single year of Schedule K-1 data using the IRS Partner's Basis Worksheet methodology.' It explicitly lists return values and clearly distinguishes from siblings by naming 'k1_basis_multi_year' for multi-year cases and excluding 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use when' and 'Don't use for' sections with concrete scenarios and alternatives (e.g., 'use a standard cost-basis calculator instead', 'use k1_basis_multi_year'). This fully informs when to select this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
k1_basis_multi_yearAComputes 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.
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 only say readOnlyHint and idempotentHint, but the description adds meaningful limitations: single position/single lot, federal-level only, estimated §751 recapture, and no state adjustments. This provides valuable behavioral context beyond the structured annotations, 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 front-loaded with the core computation and return values, then structured into use cases and limitations. The final 'Maintained by' and methodology URL add credibility but are not necessary for tool invocation, creating minor verbosity.
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?
Despite having no output schema, the description enumerates all major return components (year-by-year basis trajectory, §751 recapture, zero-basis year, §1014 step-up, broker-basis gap) and documents limitations. For a complex multi-year tax tool, this is remarkably complete.
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 very low (17%), and the description fails to explain several key parameters such as units, tax_bracket, purchase_price, purchase_year, and liability fields. It contextualizes k1_years and ticker, but the lack of parameter-level detail requires the agent to infer most semantics from property names alone.
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 and resource: 'Computes a running adjusted partner basis across multiple years of Schedule K-1 data' and ties it to precise IRC sections. It also distinguishes itself from sibling tools via the 'Don't use for' section that names exact alternatives.
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 'Use when' and 'Don't use for' sections are explicit and actionable, naming specific alternatives such as k1_basis_compute, mlp_projection, and standard cost-basis calculators. This gives clear selection guidance and prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mlp_estate_planningAComputes §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.
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, but the description adds substantial behavioral context: it models only direct holdings, excludes trusts/IDGT/FLP, is federal-level only, and acknowledges the §751 recapture elimination is an estimate depending on hot-asset disposition. It also lists exact return values, making the tool's behavior fully transparent beyond annotations.
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 with clear sections for purpose, use cases, exclusions, and limitations. It is front-loaded with the core computation and outputs. Every sentence provides useful information, though some redundancy exists (e.g., repeating 'Direct unit holdings only' in limitations after the 'Don't use for' section). It earns a high score but not a perfect 5 due to 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?
Given the tool's complexity and absence of an output schema, the description fully compensates by listing all return values (total deferred federal tax eliminated, §751 recapture eliminated, per-beneficiary split, community-property amount, dollar advantage). It also covers legal context, limitations, and methodology source, making it complete for agent selection and invocation.
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 covers most parameters with descriptions (positions, beneficiaries, community_property), achieving 75% coverage. The description adds semantic meaning by linking beneficiary count to 'per-beneficiary inheritance split' and community_property to 'community-property double-step-up amount.' However, the tax_bracket parameter lacks a description in the schema and is not explicitly explained in the description, so a slight gap remains.
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 and resource: 'Computes §1014 stepped-up basis and estate-planning analysis for one or more direct MLP positions held until death.' It explicitly enumerates the IRC sections covered and the exact outputs. It also distinguishes from sibling tools by explicitly stating 'Don't use for' scenarios (trust-based, single-position projection, sell-vs-hold), making its purpose unique.
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 an explicit 'Use when' section listing concrete scenarios (direct MLP positions, quantifying step-up benefit) and a 'Don't use for' section with exclusions and named alternatives (mlp_projection, mlp_sell_vs_hold). This fully satisfies the when/when-not/alternatives condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mlp_infoAReturns 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 useful behavioral context: it returns reference data only, with 'no IRC citations' and 'no methodology disclosure attached'. It also notes the presence of a 'last-verified date' and maintenance owner, giving insight into data freshness and accountability.
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 (what it returns, when to use, when not to use, note), but it is somewhat verbose and ends with a non-essential 'Maintained by' line. The content is valuable, but slight trimming would improve focus.
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 simple (one parameter, no output schema), and the description fully compensates for the missing output schema by enumerating all return fields. It also provides comprehensive usage boundaries and alternative-tool references, making the description entirely self-contained for an agent.
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?
Though schema description coverage is 0%, the sole parameter is 'ticker', which is inherently self-explanatory and further constrained by a detailed enum. The description reinforces that the ticker must be 'supported' and enumerates the returned data for that ticker, which indirectly clarifies what the parameter represents. No additional parameter-level details are needed.
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 clear, specific action: 'Returns reference data for a supported MLP ticker' and enumerates the exact data fields (distribution, CAGR, return-of-capital, etc.), making the tool's purpose unmistakable. It also explicitly distinguishes itself from sibling computation tools by stating it provides 'reference data only'.
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 both explicit 'Use when' scenarios and a 'Don't use for' section with named alternative tools (mlp_projection, mlp_estate_planning, etc.), providing excellent guidance on when to choose this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mlp_projectionAComputes 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?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses limitations: single position/single lot, federal-level only, and estimated §751 recapture based on default ROC assumptions. It also states the methodology (IRS Partner's Basis Worksheet, IRC sections) and notes what values are returned, providing rich behavioral context without contradicting annotations.
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 (core computation, use cases, exclusions, limitations) and front-loads the primary functionality. However, the final paragraph about the author and methodology link is not strictly necessary for an agent to invoke the tool and slightly dilutes conciseness, so 4 rather than 5.
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 tool's complexity (multi-year MLP tax projection, multiple IRC sections) and the absence of an output schema, the description thoroughly explains return values (year-by-year basis erosion, terminal FMV, break-even sell price) and constraints (single position, federal-only, estimated recapture). It provides enough context for an agent to decide and correctly invoke the tool, making it complete.
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 already covers 100% of parameters with descriptions, including defaults and enum choices (e.g., 'ticker' has an explicit enum list, 'years' has range 1-50). The description adds no new parameter-specific syntax or format details beyond the schema; its limitations about single lot and federal-level align with but do not extend the schema. Therefore baseline 3 is appropriate.
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 and resource: 'Computes a multi-year tax projection for a publicly traded MLP position.' It details exact outputs (basis erosion, §751 accumulation, annual federal tax, §1014 step-up, break-even sell price), and the 'Don't use for' section explicitly distinguishes siblings like k1_basis_compute, k1_basis_multi_year, and mlp_estate_planning.
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 named alternatives (e.g., 'use k1_basis_compute (single year) or k1_basis_multi_year' for actual K-1 data, 'use mlp_estate_planning' for multi-position estate analysis). It also states exclusions like 1099-DIV ETFs (AMLP, MLPX, AMZA) with reasoning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mlp_sell_vs_holdACompares 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.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds substantial context: it models a comparison, returns a threshold, and discloses key assumptions and limitations (tax bracket persistence, §751 recapture estimated from default ROC assumptions). It also states it is a single-position/single-lot tool, which is important behavioral context. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured: purpose first, then use/when-not, then limitations, then maintenance. Every sentence delivers information (model logic, exclusions, alternative tools, assumptions, methodology source). Front-loading the outcome and naming the key tax code sections makes the purpose immediately clear.
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 tool's complexity, low schema coverage, and no output schema, the description is remarkably complete. It explains the tax mechanics, the return value (break-even price), when to use and avoid it, and even credits the methodology source. It addresses all likely agent questions about purpose, scope, and limitations, making it a model description for this kind of analytical tool.
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 only 29% (2 of 7 parameters have descriptions), so the description must compensate. It adds meaning for the tax bracket ('supplied tax bracket') and implies units/purchase price via 'selling' and 'unit price', but it does not explicitly explain purchase_price, community_property, or years_to_project. The explanation of the financial model helps, but several parameters remain under-specified.
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 ('Compares') and a clear resource ('MLP position'), then states the exact output: 'break-even sell price — the unit price above which selling today produces more after-tax wealth than holding through inheritance.' It also distinguishes itself from sibling tools by naming them ('mlp_estate_planning', 'mlp_projection') and describing when they apply instead.
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. It gives concrete scenarios (time-sensitive sell decisions, retirement-distribution planning) and explicitly names alternative tools for excluded cases (multi-position analysis, long-horizon projection, RIC-based ETFs). This leaves no ambiguity about when to invoke this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
