Loading ToolBench
Remote MCP server for US paycheck & payroll-tax math (2026, all 50 states + DC) — the live engine behind tools-berry.com
Four well-defined payroll/tax tools with complete JSON schemas, clear descriptions (150 - 250 chars), and proper parameter typing. All tools are read-only, reducing error-handling complexity. Naming follows verb_noun pattern (compute_*, get_*). State resolution is flexible (name, abbr, slug). However, output schemas are not formally documented in the tool definitions themselves, only visible in the implementation code. Tool descriptions could be more explicit about when to use each tool vs. alternatives. No tool annotations (readOnlyHint) present despite all being read-only.
Net pay on the same salary in several states, ranked best-first, with each state's gap to the best one.
What is actually withheld from a bonus in 2026: the federal flat 22% supplemental rate (37% above $1,000,000 of supplemental wages), the state supplemental treatment (flat rate, aggregate/regular method, or none), and FICA.
Full 2026 paycheck breakdown for a salary in one state: federal income tax, Social Security, Medicare, state income tax, state payroll programs, net pay (annual/monthly/biweekly) and effective tax rate.
A state's 2026 schedule: flat rate or bracket ladder, standard deduction, employee payroll programs, bonus/supplemental method, and the statutory source the figures come from.
Output schemas not formally documented in tool definitions. Implementation returns structured objects (data + text), but the MCP tool registration does not declare the response schema. LLMs cannot plan downstream operations without knowing what fields to expect.
No tool annotations (readOnlyHint, idempotentHint) present. All four tools are read-only and idempotent, but this is not declared in the tool metadata. Agents cannot infer safety properties without explicit hints.
Tool descriptions lack guidance on when to use each tool vs. alternatives. E.g., compare_states vs. compute_take_home, when should an agent choose one over the other? Descriptions should include dependency hints and selection criteria.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Error handling in tools.js (ToolInputError) is present but not documented in tool descriptions. LLMs do not know what errors are possible or how to recover. E.g., 'unknown state' error should be mentioned with guidance to use valid state names.
Parameter 'filingStatus' defaults to 'single' but this default is not declared in the schema, only in the implementation. JSON Schema should include 'default' field so LLMs and clients know the fallback behavior.