Loading ToolBench
MCP server adapter exposing translation and paraphrasing workflows for manga/manhua localization over JSON-RPC
Server has 7 tools with clear verb-noun naming (list_, get_, submit_, update_). All tools have descriptions (avg 180 chars, within baseline 194). Input schemas are present and typed for all tools. However, parameter descriptions are minimal or absent in several tools (e.g., 'mapping' in submit_translation lacks detail on structure), and output schemas are not documented. Error handling returns generic error dicts without recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear read/write semantics. Composition is sound, tools chain logically (get_*_bundle → submit_*). Security: no secrets exposed as params. Overall: functional but lacks LLM-optimization depth.
Return the series-level locked glossary with character names and terms.
Return lines to rewrite for a chapter. Follow the READ_FIRST instructions in the returned bundle: rewrite dialogue into natural spoken English; preserve locked glossary terms verbatim; do not leave lines in raw literal English; submit the rewritten mapping via submit_paraphrase.
Return the bundle of lines that need translation for a chapter, with glossary.
List chapters in the series that are currently waiting for translation or paraphrase.
Write the paraphrase response mapping {region_id: final_english} for a chapter.
Write the translation response mapping {region_id: english} for a chapter.
Parameter 'mapping' in submit_translation and submit_paraphrase lacks detailed description. LLM cannot infer structure (region_id → string mapping) from name alone. Should document: 'Dict mapping region_id (string) to English translation (string). region_ids come from the bundle returned by get_translation_bundle.'
No output schemas documented. LLMs cannot plan downstream calls or extract fields. Each tool should document return structure: list_pending returns [{chapter, stage_awaiting}], get_translation_bundle returns {bundle, glossary, ...}, etc.
Error responses are generic dicts with 'error' key but no recovery guidance. E.g., 'Chapter folder not found' should suggest: 'Chapter folder not found. Call list_pending() to see available chapters.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | <=2025-11-25 | v2 |
Add or update series glossary terms. Pass a list of term objects shaped like entries in glossary.json: {"source_term": "姐姐", "target_term": "big sister", "locked": false, "notes": "..."}. 'source_term' and 'target_term' are required. A 'source_term' must be CJK text; entries whose source term contains no CJK characters are rejected with a warning. 'locked' (default false) and 'notes' (default "") are optional. Entries are matched against existing terms by 'source_term' and updated in place; new source_terms are appended. Terms already marked "locked": true are never overwritten - changing one requires unlocking it in a separate call. The response includes a 'warnings' array and 'warning_count'. If warnings is not empty, fix the flagged entries and resubmit - do not ignore them.
No tool annotations (readOnlyHint, destructiveHint). Tools clearly split into read-only (list_, get_) and write (submit_, update_), but LLM cannot infer this from schema. Add readOnlyHint=true to get_* and glossary read, destructiveHint=true to submit_* and update_glossary.
update_glossary 'terms' parameter is an array of objects but lacks clear schema for nested properties. Description mentions required/optional fields but JSON Schema should enforce this via 'required' array and property type constraints.