Skip to main content
Glama
dma9527

irs-taxpayer-mcp

by dma9527
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

calculate_w4_withholding

Read-onlyIdempotent

Calculate recommended W-4 withholding and estimate per-paycheck federal tax. Get step-by-step W-4 form recommendations to avoid underpayment penalties.

Instructions

Calculate recommended W-4 withholding settings. Estimates per-paycheck federal tax and provides step-by-step W-4 form recommendations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taxYearYesTax year (2024, 2025, or 2026)
deductionsNoExpected itemized deductions (if more than standard)
dependentsNoNumber of qualifying child dependents
otherIncomeNoOther annual income (interest, dividends, side gigs)
spouseWorksNoDoes your spouse also work?
annualSalaryYesAnnual salary from this job
filingStatusYesFiling status
multipleJobsNoDo you hold multiple jobs simultaneously?
payFrequencyYesHow often you get paid

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYes
errorNo
isErrorYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.1
    • changedInput schema / properties / taxYear / description
      Previous value: -"Tax year (2024 or 2025)"New value: +"Tax year (2024, 2025, or 2026)"
    • 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

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds useful behavioral context—'estimates' signals approximate output and 'recommended'/step-by-step indicates advisory results—but does not go beyond that. 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.

Conciseness5/5

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

Two tightly written sentences with no filler. The primary purpose is front-loaded in the first sentence, and the second sentence efficiently describes what the user receives without introducing concepts not covered by the schema or output.

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?

Given the rich input schema (100% param coverage) and the presence of an output schema, the description is nearly complete for invocation. It explains the tool's purpose and result format; only a small gap is the absence of explicit caveats or assumptions (e.g., that the estimate assumes current federal withholding rules), but these are not necessary for selecting and calling the tool.

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

Parameters3/5

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

Schema description coverage is 100%, and the description does not explain any parameters. Each of the 9 parameters already has a meaningful schema description (e.g., taxYear with allowed years, filingStatus enum, payFrequency enum), so the description adds no additional semantic value.

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 'Calculate recommended W-4 withholding settings,' a specific verb and resource unique among the siblings (none mention W-4). It also specifies the output: per-paycheck federal tax estimate and step-by-step W-4 form recommendations, making the tool's role unambiguous.

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

Usage Guidelines2/5

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

No guidance is given on when to choose this tool over related siblings like calculate_federal_tax or analyze_paycheck. The W-4 focus is implicit, but there is no explicit 'use this when' context or exclusion, leaving the selection decision to inference.

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

Deploy Server

Other Tools