Skip to main content
Glama
riverai

ebook-translator-mcp

by riverai

get_original_to_file

Export a book chunk's original text to a local file while returning only metadata, keeping bulk text out of the conversation for translation workflows.

Instructions

Export one chunk's original text to a local file and return only metadata — the text itself never enters the conversation (zero content tokens, no truncation risk on huge chunks). Mirrors get_original (same metadata fields, same stripped text as the UI proofreading panel shows) and is the symmetric counterpart of write_chunk_from_file: originals flow cache -> file, translations flow file -> cache, bulk text never passes through the agent.

Typical use: the first pass of a formal translation workflow — export the original to a file, translate against the file, write the result back with write_chunk_from_file. For ad-hoc inspection prefer get_original directly.

File handling: UTF-8 without BOM, LF line endings. Missing parent directories are created automatically (creating a directory destroys nothing; the resolved path is echoed as exported_file). An existing file is NOT overwritten unless overwrite=True — a mistyped path must never silently destroy an existing file (e.g. a finished translation draft). After writing, the file is read back and verified; verify_mismatch appears only if it differs. Relative paths resolve against the server process's working directory, which may differ from the caller's — absolute paths are strongly recommended. chunk_id is this book's database cache id (see list_chunks); the response echoes book_id and title — verify it is the intended book.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
book_idYes
chunk_idYes
file_pathYes
overwriteNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so: zero content tokens, UTF-8 without BOM/LF, auto-created parent directories, no overwrite unless overwrite=True, post-write read-back verification with verify_mismatch, and a relative-path warning. This is far beyond what annotations would supply.

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

Conciseness4/5

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

Well-structured into purpose, typical use, and file handling sections with the key point front-loaded. It is dense and slightly repetitive on the 'text never passes through the agent' idea, but virtually every sentence carries actionable information.

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?

An output schema exists, so return values need little explanation, yet the description still flags exported_file and verify_mismatch. Combined with the file-handling and safety details and absent annotations, an agent has everything needed to invoke it correctly and safely.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate and it does: file_path resolution behavior and the absolute-path recommendation, the overwrite default and its safety rationale, chunk_id's meaning as the book's cache id (pointing to list_chunks), and book_id/title echoing for verification. All four params gain meaning.

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+resource+scope: export one chunk's original text to a file and return only metadata, explicitly noting the text never enters the conversation. It also names the siblings it mirrors (get_original) and counterparts (write_chunk_from_file), so an agent can place it precisely without opening schemas.

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 typical workflow (first pass of a formal translation flow), names the alternative for ad-hoc inspection (get_original), and contrasts its direction against write_chunk_from_file. When-to-use and when-not-to-use are both covered.

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