Skip to main content
Glama
Sign In

OpenCidian: open Chinese ↔ Vietnamese dictionary (Hán Việt, pinyin, character breakdown)

by io.github.OpenCidian
OverviewDiscussionsAdmin

Suggest a correction

suggest_correction

Sends a correction for a wrong or missing value (Hán Việt, Vietnamese meaning, English, pinyin, a missing word) as a public GitHub issue in OpenCidian/opencidian-data; a maintainer reviews it, nothing changes in the data until then. Returns the issue number and link. Only use it when the user asks to report a mistake or agrees to, with evidence from a dictionary or textbook, never for a guess. The issue is public: put no personal details in it. A few per minute for all callers together.

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": {
      "word": "<word>",
      "field": "<field>",
      "suggested": "<suggested>",
      "evidence": "<evidence>"
    },
    "name": "suggest_correction"
  }
}

Input Schema

NameRequiredDescriptionDefault
wordYesThe word or character the fix is for, in hanzi (说, 觉得).
fieldYesWhat is wrong: hanviet (Hán Việt reading), vi (Vietnamese meaning), en (English), pinyin, missing (a word the dictionary lacks), other.
pinyinNoThe pinyin, only when the fix is for one reading of the word (觉 jiào, not jué).
currentNoThe value OpenCidian gives now, copied from a lookup.
evidenceYesWhere the right value comes from: a dictionary (Thiều Chửu, hvdic.thivien.net, a textbook) with a page or link. Not your own guess.
suggestedYesThe value it should be.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false and openWorldHint=true; the description adds what actually happens (a public issue is filed, a maintainer reviews, data is unchanged until then), what comes back (issue number and link), a privacy constraint (no personal details since the issue is public), and a shared rate limit ('a few per minute for all callers together'). This is substantially more than the annotations convey.

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?

The core action and destination are front-loaded, followed by return value, usage gating, privacy, and rate limits in that order. Every sentence carries a distinct constraint; none is 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?

For a 6-parameter write-side tool with no output schema, the description covers mechanism, review process, return values, gating conditions, privacy, and throttling. An agent has everything needed to call it correctly and warn the user.

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 description coverage is 100%, so the schema already documents every field, the enum values, and even that evidence must not be a guess. The description's mention of the field categories and evidence sourcing largely restates that, adding only the privacy implication for free-text fields. Baseline 3 applies.

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 ('sends a correction for a wrong or missing value') plus the concrete destination (a public GitHub issue in OpenCidian/opencidian-data) and enumerates the value types covered. It also distinguishes itself from read-only siblings by noting nothing in the data changes until a maintainer reviews it.

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?

Gives an explicit trigger ('only use it when the user asks to report a mistake or agrees to'), a hard exclusion ('never for a guess'), and a prerequisite ('with evidence from a dictionary or textbook'). An agent knows both when to call it and when to hold back.

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

All OpenCidian: open Chinese ↔ Vietnamese dictionary (Hán Việt, pinyin, character breakdown) toolsInspect
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