Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jp-ocr-date-fix Fix the broken Japanese dates in this OCR text: 今和6年3月15曰, 平戒31年4月30日"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Repair Japanese dates that OCR broke (今和6年3月15曰 → 令和6年3月15日), and only when the calendar confirms the result.
OCR often misreads the era name 令和 as 今和 or 合和, 日 as 曰, and 0/1 as O/l. One public test of a document parser on Japanese PDFs found the 令→今 error on roughly all OCR-processed pages (source). An AI that reads that text then extracts a date that does not exist, or guesses.
This tool fixes those spans with fixed rules and checks each result:
the span must have a full date shape: era + year + 年 + month + 月 (+ day + 日), or YYYY年M月(D日)
characters are mapped through a fixed look-alike table (今合命冷→令, 戒威→成, 照→昭, 曰目→日, O→0, l|→1, …)
the repaired date must exist and fall inside its era (平成31年4月30日 is valid, 平成31年5月1日 is not)
if it cannot be confirmed, the text is left as it is and the span is returned in flags
Python standard library only. No network. MIT.
python -m jpocrdate scan.txt # repaired text to stdout, changes to stderr
python -m jpocrdate scan.txt --json # {"text", "changes", "flags"}from jpocrdate import fix_text, check_date
check_date("平戒31年4月30日")
# {'input': '平戒31年4月30日', 'status': 'fixed', 'date': '平成31年4月30日', 'iso': '2019-04-30'}
check_date("平成31年5月1日")
# {'input': '平成31年5月1日', 'status': 'invalid', 'reason': 'date is outside 平成'}{"mcpServers": {"jp-ocr-date-fix": {"command": "python", "args": ["-m", "jpocrdate.server"], "cwd": "/path/to/jp-ocr-date-fix"}}}Tools (read-only):
Tool | Input | Returns |
|
| repaired |
|
|
|
Related MCP server: Torify — Japanese Locale APIs for AI Agents
Eras: 明治, 大正, 昭和, 平成, 令和. Abbreviations such as R6.3.15 or H31/4/30 are not handled yet
Only dates are repaired. Company names and amounts are out of scope (see JaPOC for company-name correction)
The look-alike table is hand-made from common OCR confusions. It is not learned from data, and it will miss some errors
Tests: python -m unittest discover -s tests (18 tests)
OCRで崩れた日本の日付(今和6年3月15曰 など)を、決まったルールで直します。直した結果が暦に実在し、元号の期間内にあるときだけ直します。確かめられないものは直さずに flags で知らせます(推測しません)。
対応: 明治・大正・昭和・平成・令和、元年、全角数字、年月だけの日付
外部通信なし・Python標準ライブラリのみ・MIT
AIエージェントからは MCP サーバー(python -m jpocrdate.server)として使えます
Check one date string. status: ok (already correct), fixed (OCR look-alikes repaired; see date/iso), invalid (the date does not exist, e.g. 平成31年5月1日; nothing is guessed), not_a_date.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: 'invalid' means the date does not exist and 'nothing is guessed', and 'fixed' means OCR look-alikes were repaired — a meaningful disclosure about mutation of the returned value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with zero filler, front-loaded with the action and followed by the status glossary. Every clause (including 'nothing is guessed') carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden of explaining return values and does so via the status enumeration, including the 'see date/iso' pointer. The gap is that the exact result shape and the 'date' vs 'iso' fields are only gestured at, not defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the single `date` parameter has no documented format. The description partially compensates by embedding an example Japanese-era date ('平成31年5月1日') and referencing 'date/iso', implying era-style input and dual output forms, but it never states accepted input formats explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check one date string') and then enumerates the outcome statuses, which makes the operation concrete. It implicitly distinguishes itself from the sibling jp_ocr_fix_dates (check vs. fix) but never names that sibling or states the contrast explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: enumerating ok/fixed/invalid/not_a_date suggests this is a validation pass, and the 'fixed' status hints that repair happens here rather than in the sibling. There is no explicit statement of when to call this versus jp_ocr_fix_dates, nor any prerequisite or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Japanese dates in OCR output (e.g. '今和6年3月15曰', '2O24年l月5日') and repair OCR look-alike characters. A fix is applied only when the repaired date exists on the calendar and inside the era (令和/平成/昭和/大正/明治). Returns the repaired text, every change with its ISO date, and flags for spans that look like dates but cannot be confirmed. Use it before extracting dates from scanned Japanese invoices, forms or PDFs. OCRで崩れた和暦・日付を暦で確かめて直す。
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | OCR text (Japanese) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavior: repairs are applied only when the date is calendar-valid and within the era, and the tool returns repaired text, each change with ISO date, and flags for unconfirmed date-like spans. This gives the agent much more than the readOnly/idempotent safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is front-loaded and appropriately sized for a specialized OCR repair tool. The final Japanese sentence largely restates the English description, which is a minor redundancy, but the overall structure remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description compensates by explaining the return payload: repaired text, per-change ISO dates, and flags for uncertain spans. It also covers the key validation rule, making the definition complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter and schema description coverage is 100%, so the schema already documents the input adequately. The description's examples clarify the kind of OCR text expected, but they do not add parameter-level semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: finding and repairing Japanese dates in OCR text, with concrete corrupted examples. It is clear what the tool does, but it does not explicitly differentiate itself from the sibling jp_ocr_check_date, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear usage context: use before extracting dates from scanned Japanese invoices, forms, or PDFs. However, it does not explicitly state when to use jp_ocr_check_date instead, so the alternative-routing guidance expected for a 5 is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0jp_ocr_check_datejp_ocr_fix_datesScored across 2 tools
The two tools have related but distinguishable purposes: jp_ocr_fix_dates repairs dates in bulk text, while jp_ocr_check_date validates a single date string. There is some conceptual overlap because checking is a subset of fixing, but the descriptions make the batch-vs-single distinction fairly clear.
Both tools follow the same predictable pattern: a shared jp_ocr_ prefix followed by a verb_noun phrase (fix_dates, check_date). The convention is consistent and readable.
Two tools is a small surface, but the server has a narrow, well-defined purpose: repairing and checking Japanese OCR dates. The pair covers bulk and single-date use cases without obvious bloat, though it is on the thin side.
The surface covers the core workflow of finding/repairing dates and validating individual date strings, including edge cases like nonexistent calendar dates. Minor gaps exist, such as no dedicated pure-extraction or era-conversion tool, but these are not serious for the stated scope.
Japan data tools for AI agents: calendar (rokuyo), address, name splitting, corporate number lookup
Deterministic calendars and cosmic date JSON for AI agents via MCP (Gregorian 1900-2100).
Normalize and verify Japanese postal addresses into structured fields for agents.
Exact Japanese text & date tools: char count, business days with JP holidays, era, tax, units.
