FedSalary: official pay data

US take-home pay after tax

take_home

Read-onlyIdempotent

Take-home pay on a US salary or hourly wage in a state or one of the 50 largest metro areas: federal income tax, Social Security, Medicare, the state's income tax and the state's employee payroll contributions where it has them (disability insurance, paid family leave, long-term care, employee unemployment insurance), using the state's newest published rules with the federal rules of the same year. Single filer, no dependents, standard deduction, wage income only; city and county income taxes are not included. Returns the yearly, monthly and per-paycheck amounts with each tax line and a link to the state's calculator page.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pay": "<pay>",
      "place": "<place>"
    },
    "name": "take_home"
  }
}

Input Schema

Name	Required	Description
`pay`	Yes	Pay before tax: a yearly salary, or an hourly wage with unit hour.
`unit`	No	year (default) or hour; hourly pay is annualized at 2,080 hours.
`place`	Yes	A US state (ohio or OH) or a large US metro area (austin, seattle). us gives federal taxes only.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4/5.0

Behavior5/5

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

Beyond the annotations (which already declare read-only, idempotent, closed-world), the description discloses the modeling assumptions, which tax lines are included, that state rules are the newest published ones paired with federal rules of the same year, and what a non-covered case looks like (no city/county tax). It also states the return shape, which matters because there is no output schema.

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 tax scope is front-loaded in the first clause, followed by assumptions, exclusions, and return values, so the reader gets the essentials immediately. It is dense and slightly overlong in the parenthetical payroll-contribution list, but every element carries information.

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

Completeness5/5

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

For a read-only calculator with no output schema, the description supplies everything needed: inputs accepted, geographic scope, the exact tax model, the assumptions that bound the answer, the explicitly excluded taxes, and the granularity of the returned breakdown. Nothing an agent needs to call or interpret this correctly is missing.

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%, so 'pay', 'unit' and 'place' are already fully documented including the 2,080-hour annualization and the 'us means federal only' case. The description's only added detail is the geographic scope limit of the 50 largest metro areas, so it neither compensates for nor meaningfully extends the schema — baseline 3.

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?

The description opens with a specific verb and resource ('Take-home pay on a US salary or hourly wage') and enumerates exactly which taxes are modeled, so an agent knows precisely what it computes. It falls short of a 5 only because it never names or contrasts the sibling tools (check_pay, get_pay, compare_offers) that an agent must choose between.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the assumptions (single filer, no dependents, standard deduction, wage income only) and the explicit exclusion of city and county income taxes tell the agent when the result is not applicable, which is useful. However, there is no explicit guidance on when to pick this tool over check_pay or get_pay, leaving the sibling routing to inference.

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

All FedSalary: official pay data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?