Skip to main content
Glama
Sign In
irs-taxpayer-mcp

irs-taxpayer-mcp

by dma9527
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

get_state_tax_info

Read-onlyIdempotent

Retrieve state income tax rates, brackets, and key details for any U.S. state using a two-letter state code. Use it to compare state tax rules or support taxpayer calculations.

Instructions

Get state income tax information — rates, brackets, and key details for any US state.

Input Schema

NameRequiredDescriptionDefault
stateCodeYesTwo-letter state code (e.g., 'CA', 'TX', 'NY')

Output Schema

NameRequiredDescriptionDefault
textYes
errorNo
isErrorYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.4
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed1 schema field changedv1.0.1
    • 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"
+}
  3. First observedv0.5.3

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered elsewhere. The description adds modest value by naming the kind of content returned ('rates, brackets, and key details'), but it says nothing about coverage gaps (e.g., states with no income tax) or data vintage.

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?

One short sentence, front-loaded with the verb and resource, and no filler. It could not easily be trimmed further, though the trailing 'key details' is slightly vague.

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

Completeness3/5

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

With an output schema present and full parameter documentation, return values and inputs are already specified. What remains missing is the sibling disambiguation in a crowded state-tax tool cluster, which is the main thing an agent needs to select this tool correctly.

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 coverage is 100% and the single stateCode parameter is documented with format and examples in the schema. The description's 'for any US state' only loosely reinforces the input domain, adding no format or edge-case detail beyond the schema, so baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource ('Get state income tax information') and enumerates the content returned (rates, brackets, key details). It is clear what the tool does, but it offers no differentiation from close siblings such as get_tax_brackets, estimate_state_tax, or compare_state_taxes.

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?

There is no guidance on when to use this instead of estimate_state_tax (which presumably computes a liability) or get_tax_brackets (which may overlap on bracket data). The agent must infer the boundary from the tool name alone, and no exclusions or prerequisites are given.

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