Skip to main content
Glama

Free Agent Tools

When does this Japan My Number Card expire, and what must the holder do (and by when) to keep it valid?

japan_my_number_card_expiry_check
Read-onlyIdempotent

Calculates Japan My Number Card (マイナンバーカード / Individual Number Card) validity from the ordinance (個人番号カード等に関する命令 art. 26, 27, 29; e-Gov, rules as of 2026-10-29) plus Digital Agency, ISA, Mynaportal and city guidance. holder: mid_long (foreign resident with a period of stay: work, student, spouse, etc.) | permanent | hsp2 | spr | japanese. Foreign residents with a period of stay: card expires on the period-of-stay expiry (under-18s: earlier of that and the 5th birthday), is NOT extended automatically by a visa renewal and no reminder is sent; after a grant the city extends it free if done BEFORE the old date, up to the 10th birthday after the card was made (5th if under 18). renewal=pending: one-time special extension to expiry + 2 months with proof (更新申請中 stamp, online completion email, receipt). 特定在留カード (since 2026-06-14): new card from ISA = no city-hall visit, pending = still extend at city hall. Japanese / PR / HSP2 / SPR: 10th birthday after issue (5th if under 18; age line 20 for cards made by 2022-03-31; Feb 29 → Feb 28), renewal from the day fewer than 3 months remain, new card to the 11th / 6th birthday. Also e-certificate expiry (5th birthday, capped at the card), マイナ保険証 grace (end of the 3rd month after the e-cert expiry month) and PR / HSP2 residence-card dates (7 years if issued by 2026-06-13, else 10th birthday). Returns verdict (ok | renew_window_open | extend_before_expiry | no_action_needed | expired), summary, card {expiry, expiryBasis, daysLeft, renewFrom, maxExtendableTo, newExpiryAfterAction}, specialExtension {applies, extendTo, mustApplyBy}, ecert {expiry, renewFrom, status, insuranceGraceEnds}, residenceCard, actions [{what, from, by, where, fee}], warnings, sources, disclaimer. Never send a My Number itself. Use for 'my My Number Card expires with my visa', 'マイナンバーカード 在留期間 更新 延長', 'My Number Card renewal pending visa', 'マイナンバーカード 有効期限 いつ', 'マイナ保険証 電子証明書 切れた'. Educational date calculator, not legal advice; not affiliated with the Digital Agency, J-LIS, ISA or any city office; the date on the card and the city office decide.

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": {
      "holder": "<holder>",
      "birthDate": "<birthDate>",
      "cardIssueDate": "<cardIssueDate>"
    },
    "name": "japan_my_number_card_expiry_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
todayNoYYYY-MM-DD (default: today in Japan).
holderYesmid_long = foreign resident with a period of stay (work, student, spouse, dependent, etc.) | permanent | hsp2 (Highly Skilled Professional ii) | spr (special permanent resident) | japanese.
renewalNoVisa renewal / change of status: none (default) | pending (applied, no decision yet) | granted (new residence card received).
birthDateYesYYYY-MM-DD date of birth.
cardExpiryNoOptional YYYY-MM-DD expiry printed on the card (overrides the calculation).
ecertExpiryNoOptional YYYY-MM-DD electronic-certificate expiry, if known.
specificCardNotrue if the card is a 特定在留カード (combined residence card + My Number Card, since 2026-06-14).
cardIssueDateYesYYYY-MM-DD date the current card was made (作成日 / issue date).
issuedAsRenewalNotrue if the card was made in the 3-month renewal window (runs to the 11th / 6th birthday).
residenceExpiryNomid_long: YYYY-MM-DD period-of-stay expiry the card currently shows (在留期間の満了日). Required for mid_long.
newResidenceExpiryNorenewal=granted: YYYY-MM-DD new period-of-stay expiry.
residenceCardExpiryNopermanent / hsp2: optional YYYY-MM-DD residence-card expiry.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already flag read-only, idempotent, closed-world, but the description adds substantial context: the full return shape (verdict, card, specialExtension, actions, warnings), the 'Never send a My Number itself' privacy constraint, and a clear 'educational date calculator, not legal advice, not affiliated' disclaimer. 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and trigger phrases are front-loaded, which is good, but the body is a single dense run-on cramming statutory citations, edge cases (Feb 29, age line 20, 5th/6th/11th birthdays) and output fields. Much of it earns its place, yet the volume and lack of structure hurt scannability and duplicate coverage of fields the schema already defines.

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 12-parameter, rule-heavy calculator with no output schema, the description supplies the calculation basis, holder-specific rules, the return contract, caveats and provenance (ordinance, Digital Agency, city guidance). An agent has everything needed to call it and interpret results without external lookup.

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 all 12 parameters are already documented in the schema. The description contributes rule semantics (e.g., that renewal=pending triggers the two-month special extension, what specificCard implies), but it doesn't clarify individual parameters like today, birthDate, or issuedAsRenewal beyond what the schema says, so 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?

Opens with a concrete verb+resource: 'Calculates Japan My Number Card ... validity', scoped to expiry/action timing. The resource is distinct from siblings like japan_permanent_residency_check or japan_reentry_deadline_check, and the holder/renewal framing makes the specific case it handles unmistakable.

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

Usage Guidelines4/5

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

Explicitly says 'Use for' with several trigger phrases in English and Japanese (e.g., 'My Number Card renewal pending visa', 'マイナ保険証 電子証明書 切れた'), which routes the agent well. It stops short of naming when not to use it or pointing to a sibling for adjacent questions, so no exclusions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.