Japan Residence Processing Times

Latest Japan residence processing time

residence_processing_latest

Read-only

How many days did ISA take on average, in its latest published period, to process a residence application for this status of residence? Give status (key, Japanese or English name), optionally procedure. Returns figures with period, blank cells, the PDF's notes, ISA's PDF URL and retrieval time. Status: found, not_listed (blank, not zero), unknown, unreadable_latest (older readable period, labelled). Averages of approved applications, not a forecast.

Input Schema

Name	Required	Description
`status`	Yes	Status of residence: key (e.g. engineer-humanities-international, student, highly-skilled-professional-1a), Japanese name as in ISA's table (e.g. 留学, 高度専門職1号イ) or English name (e.g. Student). Exact match only; see residence_processing_statuses
`measure`	No	Optional: disposition (days to issuance or notification of permission) or review_end (days to the end of examination; extension and change, from FY2020). Omit for both
`procedure`	No	Optional: coe (certificate of eligibility), extension (extension of period of stay) or change (change of status of residence). Omit for all

Output Schema

Name	Required	Description
`query`	Yes
`terms`	Yes	URL of the terms of service.
`answer`	Yes
`source`	Yes	Where the answer comes from: ISA's list page and PDF, and when this service read them.
`status`	Yes	found = figures in the latest period read; not_listed = blank cells in that period (not zero); unknown = no readable data yet; unreadable_latest = ISA's latest PDF could not be read, older_readable has the most recent readable period (older).
`disclaimer`	Yes	Read first: averages of applications approved in the period, as published by ISA; not a forecast for any individual application.
`provenance`	Yes	Freshness receipts for every upstream source used.
`answered_at`	Yes
`attribution`	Yes
`fixed_notes`	Yes	Notes that apply to every figure (approvals only, what disposition means, blank is not zero, seasonal peaks).
`status_note`	Yes
`legal_notice`	Yes
`older_readable`	Yes	Only with unreadable_latest: the most recent period this service could read. Older than ISA's latest.
`residence_status`	Yes
`latest_official_period`	Yes	ISA's latest period on the list page and whether this service could read its PDF.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 25, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations by disclosing response shape (period, blank cells, PDF notes, PDF URL, retrieval time) and, critically, the semantics of each status value: not_listed means blank rather than zero, and unreadable_latest falls back to an older readable period with a label. 'Averages of approved applications, not a forecast' heads off a likely misinterpretation.

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-loaded with the core question, then returns, then status semantics — a sensible ordering. The latter half is telegraphic and dense ('Returns figures with period, blank cells, the PDF's notes...'), but no sentence is wasted.

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?

An output schema exists, yet the description still clarifies the non-obvious parts: status-value semantics and that figures are historical averages. The main residual gap is routing guidance relative to the history sibling, which an agent must infer from 'latest published period'.

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 coverage is 100% and both enums are documented in-schema, so the baseline is 3. The description restates what status accepts and that procedure is optional, but adds nothing about the measure parameter (disposition vs review_end) beyond what the schema already says.

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 opening question states a precise verb and resource: average days ISA took to process a residence application for a given status, scoped to the latest published period. The 'latest published period' qualifier implicitly separates it from residence_processing_history, though no sibling is named explicitly.

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 by 'Give status (key, Japanese or English name), optionally procedure', but there is no explicit statement of when to pick this tool over residence_processing_history or residence_processing_statuses. The pointer to residence_processing_statuses for valid keys lives in the parameter schema, not the description.

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

All Japan Residence Processing Times 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?