Free Agent Tools

Lost something in Japan: who to contact first, what to stop, how long is it kept, is it too late, and when must a lost residence card be replaced?

japan_lost_item_check

Read-onlyIdempotent

Applies Japan's Lost Property Act (遺失物法) and related rules as of 2026-11-03 (遺失物法 and 施行令 via e-Gov, NPA lost-property site, ISA residence card page, Digital Agency, operator lost-and-found pages) to a lost item. items: wallet, cash, phone, passport, residence_card, mynumber_card, credit_card, ic_card, drivers_license, keys, bag, laptop, camera, jewelry, umbrella, clothing, other (array or comma string; aliases 財布, スマホ, 在留カード, suica). place: train | subway | shinkansen | bus | taxi | airport | plane | shop | hotel | street | unknown. Rules: found items kept 3 months from hand-in (umbrellas / clothing may be disposed of 2 weeks after notice); shops, hotels, taxis pass items to police within 1 week; railways, route buses, ferries, scheduled airlines (特例施設占有者) may keep them if they report within 2 weeks (cash / securities / jewellery ≥ ¥100,000 to police within 1 week); reward 5–20% (facility split 2.5–10% each), claimable 1 month after return; personal-information items never go to the finder; residence card reissue within 14 days of noticing (or of re-entry if noticed abroad), police acceptance number required; My Number card suspension 0120-95-0178 (24 h). Contacts: Tokyo Metro, JR East / Central / West, Toei, Osaka Metro, Tokyo taxis, Narita, Haneda, Kansai; police search (Tokyo and Osaka own sites, 45 prefectures share the NPA system). Returns verdict (act_now | in_window | window_closing | likely_gone), summary, facility {kind, toPoliceWithinDays, highValue}, dates {safeLastClaimDate, daysLeft, likelyGoneAfter, shortHoldDisposalFrom}, timeline[], steps[], residenceCard {reissueBy, daysLeft, overdue}, reward {minJPY, maxJPY}, contacts {operator {name, url, phone, hours, note}, policeSearch}, links, note, sources, disclaimer. Use for 'lost my wallet on the Tokyo subway', 'left my phone in a taxi in Japan', '落とし物どうする', '忘れ物電車問い合わせ', '在留カード紛失期限', 'how long does Japan keep lost items'. Cannot search for the item. Educational, not legal advice; not affiliated with the police, NPA, ISA or any railway.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "japan_lost_item_check"
  }
}

Input Schema

Name	Required	Description
`items`	No	Lost item(s): wallet, cash, phone, passport, residence_card, mynumber_card, credit_card, ic_card, drivers_license, keys, bag, laptop, camera, jewelry, umbrella, clothing, other.
`place`	No	Where it was lost (default unknown).
`today`	No	As-of date, YYYY-MM-DD (default today JST).
`cashJPY`	No	Cash inside in yen (≥ ¥100,000 → 1-week high-value rule).
`visitor`	No	Leaving Japan soon (adds overseas contact / proxy / shipping steps).
`lostDate`	No	Date lost, YYYY-MM-DD (default today JST).
`operator`	No	Operator for a direct lost-and-found contact (shinkansen → jr_central, taxi → tokyo_taxi by default).
`valueJPY`	No	Value of the item(s) in yen → reward range.
`prefecture`	No	Prefecture in romaji (tokyo, osaka, kyoto…) for the police found-items search.
`noticedDate`	No	Date the loss was noticed (residence card 14 days run from here).
`departureDate`	No	Date leaving Japan, YYYY-MM-DD.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the read-only and idempotent annotations, it discloses that no item search is performed, dates the legal rules, identifies their sources, and states educational and non-affiliation limitations. It also previews the verdict, dates, steps, contacts, and sources so the agent is unlikely to mistake the result for a live police or operator lookup.

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?

The description is information-rich but compressed into one very long paragraph mixing purpose, legal rules, contacts, output fields, examples, and disclaimers. Most content earns its place, but the extensive enumeration and source-heavy opening reduce scannability and weaken front-loading.

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 an 11-parameter rules tool with no output schema, it supplies the key domain assumptions, timing rules, return-field contract, example invocations, and hard limitation that it cannot search. Dated sources and disclaimers make it complete enough to select, invoke, and interpret despite the dense presentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds Japanese and English aliases, comma-string input support, and useful connections between inputs and legal rules. Much of the item and place enumeration repeats structured schema information, which limits additional credit.

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?

Clearly defines a Japan-specific lost-property assessment covering contact routing, retention deadlines, residence-card replacement, and rewards. The item/place scope and example queries distinguish it from the other Japan travel, visa, and My Number tools.

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?

Multilingual example queries make the intended invocation scenarios concrete, including subway, taxi, railway, and residence-card losses. "Cannot search for the item" provides an important when-not boundary, while the educational-use disclaimer clarifies the nature of the guidance.

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

All Free Agent Tools 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.