Skip to main content
Glama
dma9527

irs-taxpayer-mcp

by dma9527

estimate_self_employment_tax

Read-onlyIdempotent

Calculate a detailed self-employment tax breakdown from Schedule C profit: SE tax, QBI deduction, and recommended quarterly payments, plus SSTB classification when above the QBI threshold.

Instructions

Detailed self-employment tax breakdown including Schedule C profit, SE tax, QBI deduction, and recommended quarterly payments. Above the annual QBI threshold, provide SSTB classification, W-2 wages, and qualified-property basis, using 0 where none apply.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taxYearYesTax year
dependentsNo
filingStatusYes
grossRevenueYesTotal business revenue (Schedule C line 1)
otherW2IncomeNoW-2 income from other jobs
businessExpensesYesTotal business expenses (Schedule C)
healthInsurancePremiumsNoSelf-employed health insurance premiums
qualifiedBusinessIsSstbNo
retirementContributionsNoSEP IRA or Solo 401k contributions
qualifiedBusinessW2WagesNo
qualifiedBusinessPropertyBasisNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYes
errorNo
isErrorYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.0.1
    • addedInput schema / properties / qualifiedBusinessIsSstb
      Added value: +{
      +  "type": "boolean"
      +}
    • addedInput schema / properties / qualifiedBusinessPropertyBasis
      Added value: +{
      +  "minimum": 0,
      +  "type": "number"
      +}
    • addedInput schema / properties / qualifiedBusinessW2Wages
      Added value: +{
      +  "minimum": 0,
      +  "type": "number"
      +}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "error": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "code": {
      +          "type": "string"
      +        },
      +        "message": {
      +          "type": "string"
      +        },
      +        "suggestion": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "code",
      +        "message",
      +        "suggestion"
      +      ],
      +      "type": "object"
      +    },
      +    "isError": {
      +      "type": "boolean"
      +    },
      +    "text": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "text",
      +    "isError"
      +  ],
      +  "type": "object"
      +}
  2. First observedv0.5.3

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly and idempotent, so the description's incremental value lies in the conditional behavior: above the QBI threshold it will include SSTB classification, W-2 wages, and qualified-property basis, defaulting to 0 when not applicable. This gives the agent useful expectation-setting about output variation. No contradiction with the safety annotations.

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

Conciseness5/5

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

Two sentences with no filler; the first fronts the core purpose and output list, the second adds conditional behavior. The wording is slightly dense, but every clause carries information. Efficient for an 11-parameter estimation tool.

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 combination of a rich output schema and detailed conditional description covers what the tool returns and when it changes behavior. The 'annual QBI threshold' is not defined, and no alternative tools are mentioned, but the required inputs are in the schema and the main ambiguity (zero-filling unapplicable QBI values) is resolved. Sufficient for correct invocation.

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?

With schema description coverage at 55%, the schema already documents revenue, expenses, W-2 income, premiums, and retirement contributions. The description adds meaning for the otherwise under-documented QBI parameters by naming them and explaining that W-2 wages and property basis default to 0 when not applicable. It does not detail every remaining optional parameter, but the most ambiguous ones are addressed.

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 phrase ('Detailed self-employment tax breakdown') and names distinct outputs: Schedule C profit, SE tax, QBI deduction, and quarterly payments. This makes the tool's scope evident and separates it from sibling calculators like calculate_total_tax or estimate_quarterly_tax. The conditional QBI sentence further specifies the resource's behavior.

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

Usage Guidelines4/5

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

The description establishes clear context: it is the tool for a comprehensive self-employment tax estimate, not a general tax calculation. It stops short of explicitly naming alternatives or stating when not to use it, but the 'detailed breakdown' framing differentiates it from sibling quarterly-payment and total-tax tools. No misleading exclusions are present.

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