Ask Japan

Request a service in Japan

request_service

Send a request for a service in Japan. Fixed-price services (phone_call JPY 1,500, restaurant_booking JPY 3,000, interpreting JPY 5,000 per 30 min) return the quote and payment details immediately. Other services get a fixed quote from a person within 2 hours (JST 09:00-21:00); requests sent outside hours are handled from 09:00. No email is needed: follow up with get_request_status. Creating a request is free and does not move any money. Full refund if we cannot do the task or you cancel before work starts.

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": {
      "service": "<service>",
      "details": "<details>"
    },
    "name": "request_service"
  }
}

Input Schema

Name	Required	Description
`details`	Yes	What, where, when, how many people, names, constraints
`service`	Yes	Service id from list_services
`language`	No	Preferred language for replies, e.g. en, ja, zh
`budget_jpy`	No	Optional budget in JPY
`callback_url`	No	Optional public https URL that receives status updates as JSON
`contact_email`	No	Optional email for the quote and result

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that creating a request is free, that no money moves, the refund policy if the task cannot be done or is cancelled before work starts, and the out-of-hours handling. These are exactly the behavioral facts an agent needs before committing a user to a request.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Front-loads the core action, then pricing, then timing, then follow-up and cost/refund terms. Every sentence carries distinct information with no filler.

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?

With no output schema, the description compensates by describing what comes back (quote and payment details immediately, or a fixed quote within 2 hours) and how to retrieve results. Nothing essential for correct invocation is missing.

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 real meaning by attaching prices to specific service enum values (phone_call JPY 1,500, restaurant_booking JPY 3,000, interpreting JPY 5,000 per 30 min). It does not clarify details, budget_jpy, or callback_url beyond the schema.

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 verb and resource ('Send a request for a service in Japan') and immediately distinguishes itself from the follow-up sibling by naming get_request_status. An agent can tell this is the creation step versus a status-check step without opening the schema.

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?

Explains the two operating modes (fixed-price services return a quote immediately; other services get a human quote within 2 hours, JST 09:00-21:00) and routes the agent to get_request_status for follow-up. It does not explicitly say when to prefer list_services or check_availability first, so it stops short of full alternative routing.

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

All Ask Japan 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?