Mart402

Jp Payroll Net

jp_payroll_net

Idempotent

Annual gross salary to net take-home (social insurance + income tax + resident tax). Exact NTA Beppyo-5 table. $0.02/call. Deterministic, cites primary sources; errors and unverified rules are never billed. Choose this for a whole YEAR: annual gross salary to annual take-home after social insurance, income tax and resident tax. For one bonus use jp_bonus_net; for one month's premiums only use jp_social_insurance; to check an actual payslip use jp_payslip_audit.

Input Schema

Name	Required	Description
`age`	No	Age in years (selects care-insurance and other age-gated rules)
`year`	No	Calendar year
`as_of`	No	Calculation reference date YYYY-MM-DD (default today); selects the rules version
`x_payment`	No	Optional: base64 X-PAYMENT header value (x402 exact scheme, USDC on Base mainnet). Omit it to receive the payment requirements (accepts[] + docs) for this call without being charged.
`dependents`	No	Dependents object (see /catalog input spec)
`prefecture`	Yes	Prefecture (romaji or Japanese), e.g. 'Tokyo'
`annual_bonus_yen`	No	Annual bonus total in yen
`annual_gross_yen`	Yes	Annual gross salary in yen

Output Schema

Name	Required	Description
`body`	Yes	JSON body of the underlying call (see /samples/{product} for each product's shape)
`status`	Yes	HTTP status of the underlying call (200 result, 402 payment terms, 4xx input error)
`how_to_pay`	No
`receipt_id`	No	set on paid results; free re-fetch via get_receipt
`payment_required`	No	true when status is 402: body holds x402 payment terms, not a result. Pay and call again with x_payment

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 19, 2026

addedOutput schema / properties / how_to_pay
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / payment_required

Added value: +{
+  "description": "true when status is 402: body holds x402 payment terms, not a result. Pay and call again with x_payment",
+  "type": "boolean"
+}

addedOutput schema / properties / receipt_id

Added value: +{
+  "description": "set on paid results; free re-fetch via get_receipt",
+  "type": "string"
+}

Changed1 schema field changedOct 18, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "body": {
+      "description": "JSON body of the underlying call (see /samples/{product} for each product's shape)"
+    },
+    "status": {
+      "description": "HTTP status of the underlying call (200 result, 402 payment terms, 4xx input error)",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "status",
+    "body"
+  ],
+  "type": "object"
+}

Changed4 schema fields changedSep 27, 2026
- addedInput schema / properties / age / default
```
Added value: +30
```
- addedInput schema / properties / annual_bonus_yen / default
```
Added value: +0
```
- addedInput schema / properties / as_of / format
```
Added value: +"date"
```
- addedInput schema / properties / year / default
```
Added value: +2026
```
Changed7 schema fields changedSep 27, 2026
- addedInput schema / properties / age / description
```
Added value: +"Age in years (selects care-insurance and other age-gated rules)"
```
- addedInput schema / properties / annual_bonus_yen / description
```
Added value: +"Annual bonus total in yen"
```
- addedInput schema / properties / annual_gross_yen / description
```
Added value: +"Annual gross salary in yen"
```
- addedInput schema / properties / as_of / description
```
Added value: +"Calculation reference date YYYY-MM-DD (default today); selects the rules version"
```
- addedInput schema / properties / dependents / description
```
Added value: +"Dependents object (see /catalog input spec)"
```
- addedInput schema / properties / prefecture / description
```
Added value: +"Prefecture (romaji or Japanese), e.g. 'Tokyo'"
```
- addedInput schema / properties / year / description
```
Added value: +"Calendar year"
```
AddedAug 19, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the cost model ($0.02/call), the billing guarantee (errors and unverified rules are never billed), determinism, and the primary-source citation claim. The 'exact NTA Beppyo-5 table' note and the paid nature of the call are consistent with readOnlyHint=false and openWorldHint=true, so nothing contradicts the annotations.

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?

Front-loads the core transformation and the sibling routing, which is the right ordering. However the same phrase is substantially restated twice ('Annual gross salary to net take-home (social insurance + income tax + resident tax)' then 'annual gross salary to annual take-home after social insurance, income tax and resident tax'), so one sentence could be trimmed.

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?

Complete for a paid calculation tool: cost, billing exceptions, determinism, scope and sibling alternatives are all covered, and an output schema exists so return shape needn't be described. The payment handshake is only covered by the schema's x_payment field rather than the description, which is a minor gap given this is a chargeable call.

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 the schema already explains annual_gross_yen, prefecture, age, year, as_of, dependents and the x_payment flow. The description adds no parameter-level detail beyond restating 'annual gross salary' and the deduction categories, so the baseline 3 applies.

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?

States a specific transformation (annual gross salary → net take-home) and enumerates the deduction components: social insurance, income tax, resident tax. It explicitly stakes out the annual scope and names the sibling tools that cover the adjacent cases, so an agent can distinguish it from jp_bonus_net, jp_social_insurance and jp_payslip_audit immediately.

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

Usage Guidelines5/5

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

Explicitly says to choose this 'for a whole YEAR' and then routes three concrete alternative intents: one bonus → jp_bonus_net, one month's premiums only → jp_social_insurance, verify a real payslip → jp_payslip_audit. Both the when and the when-not are stated with named alternatives.

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

All Mart402 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?