Loading ToolBench
Lara API official MCP server for translation management, glossaries, and translation memories
The server provides 22 translation tools with mostly complete schemas and descriptions. Strengths: all tools have explicit input schemas with Zod validation, descriptions are present for all tools and parameters, consistent naming conventions (verb_noun), and strong separation of concerns. Weaknesses: several descriptions are generic or generic-placeholder text ('Retrieved list of supported languages', 'Glossary import status'), parameter descriptions occasionally lack actionable detail (e.g., format expectations for IDs), output schemas are mostly inferred rather than explicitly documented in the tool definitions, and error handling lacks recovery guidance. Tool composition is solid (each tool does one thing), but parameter documentation could be more prescriptive about format and constraints.
Adds a new entry to a glossary with terms in one or more languages.
Adds a translation unit to one or more translation memories.
Glossary import status
Checks the status of a TMX import job.
Creates a new glossary with the specified name.
Creates a new translation memory with the specified name.
Generic and placeholder descriptions reduce LLM tool selection confidence. 'Retrieved list of supported languages' (list_languages) and 'Glossary import status' (check_glossary_import_status) are not actionable for an LLM deciding when to invoke these tools. Descriptions should state what the tool returns, when to call it, and how results are structured.
Output schemas are not documented inline with tool definitions. Handlers return complex objects (e.g., translateHandler returns segments with confidence scores, add_glossary_entry returns structured glossary entries), but the MCP server does not publish output schemas to clients. This forces LLMs to infer result structure from context rather than having a contract.
Parameter descriptions lack actionable format specifications. Example: 'memory' and 'glossary' parameters accept IDs (mem_xyz123, gls_xyz123) but descriptions only state 'Memory ID(s)' or 'Glossary ID(s)' without explicit format guidance. A parameter description like 'Memory ID (format: mem_xyz123; max 50 memories per request)' would better guide LLM input construction.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Deletes a glossary by its ID.
Deletes an entry from a glossary.
Deletes a translation memory by its ID.
Deletes a translation unit from one or more translation memories.
Detects the language of the provided text. Returns the detected language, content type, and a list of predictions with confidence scores. Accepts a single string or an array of strings (up to 128 elements).
Exports a glossary as a CSV file.
Retrieves detailed information about a glossary, including its entries.
Retrieves entry count statistics for a glossary.
Queues a CSV file for import into a glossary. Returns an import job ID for monitoring progress.
Queues a TMX file for import into a translation memory. Returns an import job ID for monitoring progress.
Lists all glossaries in the user's Lara account.
Retrieved list of supported languages
Lists all translation memories in the user's Lara account.
Translates text from a source language to a target language. Returns the translated segments, with support for multiple segments, formatting preservation, and context.
Updates the name of a glossary.
Updates the name of a translation memory.
Error handling lacks recovery guidance. The code catches LaraApiError and LaraTimeoutError but does not indicate which errors are retryable, which require user action (e.g., verify memory ID format), or which are unrecoverable. LLMs receive raw error messages with no suggestion for next steps.
No input validation or constraint feedback. Tools accept arrays (e.g., 'text' can be an array of up to 128 strings in detect_language, 'id' can be array of memory IDs in add_translation) but constraints are buried in descriptions and not enforced with clear error messages. If an LLM passes 200 strings, the error should be: 'Array too large: passed 200 items, max 128 allowed.'
Destructive operations (delete_memory, delete_translation, delete_glossary, delete_glossary_entry) have no confirmation or dry-run capability. An LLM in a planning loop could accidentally trigger irreversible deletions. Consider adding optional 'dry_run' parameter or separate 'confirm_delete' tool.
Batch operations lack granular per-item error reporting. If add_translation is called with an array of memory IDs and one ID is invalid, the entire call fails. The response should indicate: 'Added to 3 of 4 memories; failed for mem_456 (not found).' This allows agents to handle partial success.