Skip to main content
Glama

US Solo 401(k) contribution

solo_401k_shield
Read-onlyIdempotent

Maximize tax-deferred retirement sheltering by comparing Solo 401(k) vs. SEP-IRA contribution limits and calculating immediate cash tax savings under statutory IRS Notice 2023-75 caps ($69,000 / $76,500).

Behavior: Deterministic, idempotent calculation with zero external side effects. Computes employee elective deferral (up to $23,000 or $30,500 if age 50+) plus employer profit-sharing (20% of adjusted net earnings for LLC/sole prop, 25% of W-2 salary for S-Corp) subject to annual statutory additions cap. Multiplies total deductible contribution by marginal tax rate to return net cash saved.

Usage Guidelines: Use when an owner-only business, independent contractor, or partner wants to optimize pre-tax retirement deductions. Do not use for multi-year exponential compound investment growth modeling; use compound_wealth instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_of_dateYesCivil date YYYY-MM-DD. Selects the rule pack in force on that date. Required: the engine will not assume a date.
entityTypeNoTax treatment of the business, which changes the contribution limits. The previously advertised value "llc" is not accepted: an LLC may be taxed either way, so choosing one on the caller's behalf would be a guess. State the tax treatment, not the legal form.
isAge50PlusNoWhether the account holder is age 50 or older, unlocking the statutory $7,500 catch-up contribution.
netEarningsYesAnnual net business profit (Schedule C) or W-2 officer salary (S-Corp) in USD ($/yr). Must be a positive number.
participant_ageYesParticipant age in years. Required: it decides catch-up eligibility (IRC s.414(v), SECURE 2.0 s.109).
marginalTaxRatePercentNoCombined federal and state marginal income tax bracket percentage (e.g. 28 for 28%).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / as_of_date
      Added value: +{
      +  "description": "Civil date YYYY-MM-DD. Selects the rule pack in force on that date. Required: the engine will not assume a date.",
      +  "example": "2026-09-26",
      +  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "netEarnings",
      -  "participant_age"
      -]New value: +[
      +  "netEarnings",
      +  "participant_age",
      +  "as_of_date"
      +]
  2. Changed2 schema fields changed
    • addedInput schema / properties / participant_age
      Added value: +{
      +  "description": "Participant age in years. Required: it decides catch-up eligibility (IRC s.414(v), SECURE 2.0 s.109).",
      +  "example": 45,
      +  "maximum": 100,
      +  "minimum": 18,
      +  "type": "integer"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "netEarnings"
      -]New value: +[
      +  "netEarnings",
      +  "participant_age"
      +]
  3. Changed4 schema fields changed
    • removedInput schema / properties / entityType / default
      Removed value: -"llc"
    • changedInput schema / properties / entityType / description
      Previous value: -"Legal entity tax structure: 'llc' (sole proprietorship / single-member LLC using 20% adjusted SE earnings) or 'scorp' (corporation using 25% W-2 wage)."New value: +"Tax treatment of the business, which changes the contribution limits. The previously advertised value \"llc\" is not accepted: an LLC may be taxed either way, so choosing one on the caller's behalf would be a guess. State the tax treatment, not the legal form."
    • changedInput schema / properties / entityType / enum
      Previous value: -[
      -  "llc",
      -  "scorp"
      -]New value: +[
      +  "sole_prop",
      +  "scorp"
      +]
    • removedInput schema / properties / netEarnings / default
      Removed value: -120000
  4. Changed4 schema fields changed
    • changedInput schema / properties / entityType / description
      Previous value: -"Entity structure: 'llc' or 'scorp'"New value: +"Legal entity tax structure: 'llc' (sole proprietorship / single-member LLC using 20% adjusted SE earnings) or 'scorp' (corporation using 25% W-2 wage)."
    • changedInput schema / properties / isAge50Plus / description
      Previous value: -"Eligible for $7,500 age 50+ catch-up"New value: +"Whether the account holder is age 50 or older, unlocking the statutory $7,500 catch-up contribution."
    • changedInput schema / properties / marginalTaxRatePercent / description
      Previous value: -"Combined federal and state marginal tax bracket %"New value: +"Combined federal and state marginal income tax bracket percentage (e.g. 28 for 28%)."
    • changedInput schema / properties / netEarnings / description
      Previous value: -"Annual net business profit or W-2 salary ($/yr)"New value: +"Annual net business profit (Schedule C) or W-2 officer salary (S-Corp) in USD ($/yr). Must be a positive number."
  5. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces this ('Deterministic, idempotent calculation with zero external side effects'). It adds substantial behavioral context beyond annotations: the exact calculation steps (employee elective deferral limits, employer profit-sharing percentages for different entity types, statutory caps, and marginal tax rate multiplication), and even clarifies a common pitfall (the rejected 'llc' entityType). This is exactly the kind of additional context that helps an agent trust and correctly use the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with clear labels ('Behavior:', 'Usage Guidelines:') and the primary purpose is front-loaded in the first sentence. It is a bit long, but every sentence contributes: the calculation logic, statutory caps, entity type caveat, and usage alternative all earn their place. It avoids fluff and maintains focus, though it could be tightened by removing the redundant 'zero external side effects' phrase that duplicates annotations.

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

Completeness4/5

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

The tool is a complex financial calculation with six parameters and no output schema, so the description carries the burden of explaining the return value. It does state that it 'returns net cash saved' and describes the computation pipeline, which is sufficient for an agent to understand the output. It also covers statutory limits, entity type rules, and catch-up eligibility, addressing the main edge cases. Minor gaps: it doesn't specify the exact output format (e.g., a single number vs. an object), and it doesn't mention error handling for invalid inputs, but these are not critical given the schema's explicit requirements.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining how parameters interact: it specifies that entityType changes the profit-sharing percentage (20% for sole prop/LLC, 25% for S-Corp), that isAge50Plus unlocks the $7,500 catch-up, and that marginalTaxRatePercent is used to compute the cash tax savings. This adds meaningful semantic value, though the schema descriptions are already quite detailed. A 4 is appropriate—not a 5 because the schema already covers the basics, but the description enriches understanding of parameter relationships.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Maximize tax-deferred retirement sheltering') and resource ('Solo 401(k) vs. SEP-IRA contribution limits'), then details the exact computation (elective deferral + profit-sharing, capped at IRS Notice 2023-75 limits) and the output (net cash saved). This clearly distinguishes it from siblings like compound_wealth, which is explicitly named as the alternative for investment growth modeling. No ambiguity remains about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states precisely when to use it ('Use when an owner-only business, independent contractor, or partner wants to optimize pre-tax retirement deductions') and when not to ('Do not use for multi-year exponential compound investment growth modeling'), naming the specific sibling tool to use instead (compound_wealth). This leaves no inference to the agent.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources