MLP Tax Computation
Server Details
MLP tax computation: basis erosion, §751 recapture, estate planning, sell-vs-hold.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.5/5 across 6 of 6 tools scored.
Each tool serves a distinct purpose: single-year basis, multi-year basis, estate planning, reference info, long-term projection, and sell-vs-hold comparison. No two tools overlap in function, and descriptions clearly differentiate related tools.
Tool names follow a broad pattern (k1_ vs mlp_ prefixes) but verbs and naming conventions are mixed: 'compute' vs 'multi_year' (adjective), 'estate_planning' (noun), 'info', 'projection', 'sell_vs_hold' (verb phrase). Not fully consistent but still readable.
Six tools cover the core MLP tax domain: basis computation (single and multi-year), estate planning, projection, sell-decision analysis, and reference data. This is well-scoped without being bloated or thin.
The tool set covers the essential MLP lifecycle: basis tracking, projection, estate planning, and sell decisions. Minor gaps exist (e.g., multi-lot handling is not internal), but these are acknowledged and directed to external resources.
Available Tools
6 toolsk1_basis_computeARead-onlyIdempotentInspect
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.
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral context: it computes and returns worksheet lines, §731 gains, and §704(d) suspended losses, and explicitly states limitations (single year, federal-only). 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?
Well-structured with clear sections (Use when, Don't use for, Limitations). Information-dense but not verbose; each sentence serves a purpose. Slightly long but justified by 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?
Despite no output schema, the description sufficiently explains inputs, outputs (worksheet values, gains, suspended losses), legal basis, and limitations. Covers usage context and hypothetical examples for a complex 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 description coverage is 75%, so baseline is 3. The description adds context by naming specific K-1 box values (Box 1, 19A, etc.) and liability changes, but does not explain all parameters (e.g., box2, tax_bracket, liability_increase/decrease in detail). It adds moderate 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 clearly states the tool computes adjusted partner basis from a single year of Schedule K-1 data using IRS methodology, with specific legal references. It distinguishes itself from sibling tools by emphasizing single-tax-year and single-lot scope.
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?
Explicitly provides 'Use when' conditions (direct MLP holdings, structured K-1 values) and 'Don't use for' cases (ETFs, multi-year, general partnerships) with alternative tools listed, offering clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
k1_basis_multi_yearARead-onlyIdempotentInspect
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.
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details what the tool returns (year-by-year basis trajectory, §751 recapture estimate, zero-basis year, §1014 step-up, broker-basis gap) and its limitations (single position/ lot, federal-only, estimated recapture). Annotations already indicate readOnlyHint and idempotentHint, and the description adds context without 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 lengthy but well-structured: it starts with the core computation and IRC references, then provides use-conditions, exclusions, limitations, and credits. Every sentence adds value, though some compression could improve efficiency.
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 basis, multiple IRC sections, broker-gap projection), the description covers all necessary aspects: outputs, use cases, non-use cases, limitations, and even auditable methodology. No output schema exists, but the description compensates thoroughly.
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%, meaning few parameters are described in the schema. The description does not explain individual parameters beyond mentioning ticker list and k1_years as an array. It does not detail units, purchase_price, tax_bracket, or purchase_year, leaving the agent to infer from context. With low coverage, more parameter-level detail was expected.
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 it computes a multi-year adjusted partner basis, referencing specific IRC sections (705, 731, 751, 752, 704(d), 1014(a)). It differentiates from sibling tools by explicitly stating not to use for single-year basis (use k1_basis_compute) or long-horizon projections (use mlp_projection), and confirms it handles one position per call.
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' and 'Don't use for' sections, listing conditions (direct MLP position, multiple consecutive years, need for basis trajectory or broker-gap) and exclusions (single-year, long-horizon, ETFs, multi-position). It also names alternative tools for excluded cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mlp_estate_planningARead-onlyIdempotentInspect
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.
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) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, and the description adds extra behavioral context: limitations (federal-only, estimated §751, no state tax), scope (direct holdings only), and maintenance details. 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 front-loaded with the main purpose, then clearly divided into 'Use when', 'Don't use for', and 'Limitations' sections. While verbose, every sentence conveys necessary context and earns its place.
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 (multiple IRC sections, multiple outputs, no output schema), the description is thorough: it lists all outputs, covers limitations, references sibling tools explicitly, and aligns with annotations. No gaps remain for an agent to misunderstand the tool's role.
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% (tax_bracket missing description). The description elaborates on tickers (specific MLP list), community_property (double step-up), and beneficiaries (inheritance splits), adding meaning beyond basic schema types. However, tax_bracket receives no extra explanation.
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 starts with a clear verb 'Computes' and identifies the exact resource: '§1014 stepped-up basis and estate-planning analysis'. It lists specific outputs and explicitly distinguishes from sibling tools like mlp_projection and mlp_sell_vs_hold in the 'Use when' and 'Don't use for' sections.
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' section enumerates precise scenarios (direct MLP positions, estate planning, community property, multiple beneficiaries) and the 'Don't use for' section lists exclusions with alternative tool names (mlp_projection, mlp_sell_vs_hold) and specific inapplicable cases (trusts, ETFs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mlp_infoARead-onlyIdempotentInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is safe. The description adds context that it returns reference data only, with no IRC citations or methodology. This is useful but not critical 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?
Thorough yet concise, with clear sections. Every sentence adds value, including maintenance contact. No redundancy or fluff.
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 simplicity (one param, read-only, no output schema), the description covers all needed context: what data is returned, when to use, when not to, and sibling tools. No gaps.
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?
Only one parameter (ticker) with enum values fully described in schema. Schema coverage is 0% as description doesn't add parameter details, but schema itself is sufficient. Description does not enhance parameter understanding beyond 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 clearly states it returns reference data for a supported MLP ticker, listing specific fields. It distinguishes from siblings by explicitly naming alternative tools and their purposes.
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, listing alternative tools like mlp_projection, mlp_estate_planning, etc. This gives clear guidance on when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mlp_projectionARead-onlyIdempotentInspect
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) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, and the description does not contradict them. It adds behavioral context by listing limitations (single position, federal-only, estimated recapture) and maintained by a domain expert, which goes beyond what annotations provide.
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 distinct sections (what, when, limitations) and is front-loaded with the core purpose. While verbose, the level of detail is justified for a complex financial tool; could be slightly more concise but effective.
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 and lack of output schema, the description fully explains return values (basis erosion, tax, etc.), use cases, limitations, and methodology. It compensates for missing output schema with a clear list of outputs.
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 100%, so the schema already documents all parameters. The tool description does not add significant extra meaning for parameters beyond contextual usage hints, thus 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 clearly states it computes a multi-year tax projection for MLP positions, applying specific IRS methodologies and returning detailed outputs. It distinguishes from sibling tools by specifying when to use and when not to use, such as avoiding for 1099-DIV ETFs or multi-position analysis.
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?
Explicit 'Use when' and 'Don't use for' sections provide clear guidance on appropriate contexts, including specific tickers and scenarios. It also names alternative tools like mlp_estate_planning and k1_basis_compute for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mlp_sell_vs_holdARead-onlyIdempotentInspect
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.
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds extensive transparency: tax methodology, assumptions (default ROC), limitations (single position, single lot), and maintenance info. No contradictions.
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?
Well-structured with clear sections and front-loaded purpose. Some minor extraneous info (maintenance details) but overall efficient for the 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?
Thoroughly covers all aspects: tax code references, return value, limitations, assumptions. No output schema but return value is clearly stated. Highly complete for a complex calculation 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 description coverage is only 29%. Description mentions most parameters (ticker, units, tax_bracket, etc.) but does not fully explain each one, e.g., community_property is not described. Adds context but not enough to fully compensate for missing schema descriptions.
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?
Clearly states the tool compares selling now vs holding to death for MLP positions, returns break-even price. Distinguishes from siblings by naming alternatives and explaining when not to use.
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?
Explicit 'Use when' and 'Don't use for' sections with specific scenarios, reasons, and alternative tool names. Provides clear guidance on appropriate and inappropriate usage.
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.
Discussions
No comments yet. Be the first to start the discussion!