Japan 車検 statutory costs: weight tax, 自賠責, inspection fees, 自動車税 and 軽自動車税, sourced.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 1 tool
There is only one tool, so there is no possibility of misselection between tools. The category parameter enumerates distinct cost domains (weight-tax, cali, inspection-fee, auto-tax, kei-tax) so internal routing is also unambiguous.
A single, well-formed snake_case name with a clear domain prefix (jp_vehicle_costs_lookup) that states both scope and action. No competing conventions exist to conflict with.
One parameterized lookup is the correct shape for a static reference-data server; splitting each cost category into its own tool would be worse. It is slightly thin in that discovery of valid categories depends entirely on the parameter description.
The surface covers the major Japanese statutory cost categories (weight tax, eco-car reduction, compulsory insurance, inspection fees, auto tax, kei tax) with values, sources, and effective dates. Minor gap: there is no way to list available categories or enumerate records, since no category returns a listing.
Japan vehicle statutory costs (車検 法定費用 and annual car taxes), verified against the official pages, by category: weight-tax (自動車重量税 at continuing inspection 2026-05-01 – 2028-04-30: registered passenger cars per 0.5 t for eco, standard, 13-year and 18-year rates, 2-year and 1-year, the full 2-year table to 3 t, kei flat amounts, the 13/18-year counting rules), weight-tax-eco (エコカー減税 period, new-registration bands, first-inspection exemption), cali (自賠責保険 for private passenger and kei cars: 12/24/25/36/37 months for policies starting before 2026-11-01, and 12/24/36 months from 2026-11-01 as keys ending -from-2026-11), inspection-fee (継続検査 fees: 持込, 保安基準適合証 counter and OSS, standard/small/kei, from 2026-04-01, with the previous amounts), auto-tax (自動車税 by displacement for cars registered from / before 2019-10, the 13-year surcharge table and rule, the EV reduction) and kei-tax (軽自動車税 10,800 / 7,200 / 12,900 and the surcharge and EV reduction rules). Each figure carries its value in JPY, unit, the Japanese term, the quoted row from the page, its source URL and effectiveFrom (and effectiveTo where the source states an end); the answer carries verifiedDate, freshness and a citation permalink. No category returns the listing; an unknown category answers covered:false with the nearest keys.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | one of: weight-tax, weight-tax-eco, cali, inspection-fee, auto-tax, kei-tax (omit to list all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations: it discloses the effectiveFrom/effectiveTo windows per figure, that each value carries JPY unit, Japanese term, quoted source row, source URL and a citation permalink, that answers carry verifiedDate and freshness, and that unknown categories return covered:false with nearest keys instead of an error. That is exactly the failure-mode and payload-shape information the annotations cannot convey.
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 body is one enormous run-on sentence whose parenthetical category breakdowns rival the data itself. Nothing is front-loaded beyond the first clause; a reader must parse to the very end to learn the omit-to-list behavior and the unknown-category fallback. Much of the per-category detail duplicates what the response payload documents anyway.
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?
For a single-parameter read-only lookup with no output schema, the description supplies everything an agent needs: the category taxonomy, the returned field set, effective-date semantics, verification/freshness metadata, and the unknown-key fallback. Nothing material is missing.
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 100% and already lists the six category values, so the baseline is 3. The description earns more by explaining what each category actually contains (e.g., the cali keys ending -from-2026-11 for policies starting 2026-11-01, the 13/18-year counting rules) and by clarifying that an unknown value degrades to covered:false rather than throwing.
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 resource is stated with unusual precision: Japanese vehicle statutory costs (車検 legal fees and annual taxes) split into six named categories with their scope (rates, effective windows, vehicle classes). No verb like 'get' or 'look up' is used and the tool name carries it, so the agent must infer the action. There are no siblings to differentiate from, so the only missing piece is the explicit verb.
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 by the parameter: 'by category' plus 'No category returns the listing' tells the agent that omitting category yields the category listing rather than data. There is no explicit statement of when a caller should pick a specific category versus omit it, nor any prerequisites or exclusions. With no sibling tools, the practical risk is low, but the guidance remains implicit.
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.
jp_vehicle_costs_lookupJapan minimum wage by prefecture, 協会けんぽ rates, pensions, benefits, holidays, tax figures, sourced.
UK vehicle tax (VED) bands, expensive-car supplement, EV rules and MOT fees, sourced.
Japanese cars, sourced: genealogy, parts fitment, shaken and service shops, used cars, US import.
Japan payroll & social insurance. 日本の給与計算・社会保険。47都道府県の料率、源泉所得税、割増賃金、有給、標準報酬月額の改定、最低賃金。根拠の条文つき。
Add one secure layer between your agents and this server.