Skip to main content
Glama
ArcaTax
by Accuarion

upsert_w2

Add or replace a W-2 by matching its stable ID, enabling you to capture or update employer, wage, withholding, box 12, and box 14 details in ArcaTax.

Instructions

Add or replace a W-2 (matched by id). Enter boxes exactly as printed; box 12 codes go in box12.

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": {
      "w2": "<w2>"
    },
    "name": "upsert_w2"
  }
}

Input Schema

NameRequiredDescriptionDefault
w2Yes
tax_yearNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It usefully discloses that matching is by `id` and that the operation replaces, but it does not say what a replace discards (are omitted fields reset to their defaults?), what happens if `id` is absent, or whether the tax_year default of 2026 scopes or overwrites existing records.

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 short sentences, front-loaded with the operation and match key, then the input-format rule. Nothing is redundant or padded.

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?

An output schema exists so return values need no explanation, and 'enter boxes exactly as printed' covers the highest-risk input error. But for an unannotated mutation over a large nested document, the description omits replace semantics, id-omission behavior, and the meaning of the 2026 tax_year default.

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 reported as 0%, so the description must compensate; it adds real meaning for two things – values should be passed as printed (explaining the number-or-string union) and box 12 entries belong in `box12` rather than folded into a label. The remaining ~15 W-2Document fields, including box13 flags, box14 free-form labels, and `tax_year`, get no semantic help.

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?

Names a specific verb pair (add or replace) and an unambiguous resource (W-2), plus the matching key. The document type alone separates it from upsert_1099 and upsert_k1_1120s, but it never explicitly routes the agent among those siblings.

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?

'Add or replace ... matched by `id`' implies the create-vs-update condition, and 'Enter boxes exactly as printed' is a real usage instruction for input formatting. There is no guidance on when this tool applies versus sibling document upserts, and no exclusion or precondition such as filing status.

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