Lara Translate MCP Server

delete_translation

DestructiveIdempotent

Deletes a translation unit from a translation memory in your Lara Translate account, using the source and target sentences to identify it.

Instructions

Deletes a translation from a translation memory in your Lara Translate account.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	The ID or list of IDs where to delete the translation unit from. Format: mem_xyz123
`tuid`	No	Translation Unit unique identifier
`source`	Yes	The source language code of the sentence
`target`	Yes	The target language code of the translation
`sentence`	Yes	The source sentence
`translation`	Yes	The translated sentence
`sentence_after`	No	The sentence after the source sentence to specify the context of the translation unit
`sentence_before`	No	The sentence before the source sentence to specify the context of the translation unit

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Import job identifier
`end`	No	End offset of the import
`size`	No	Total number of units in the import
`begin`	No	Begin offset of the import
`channel`	No	Channel identifier used by the import
`progress`	No	Import progress between 0 and 1 (1 means complete)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.0.0Sep 29, 2026
- removedOutput schema / additionalProperties
```
Removed value: -{}
```

Changed1 schema field changedv1.0.4May 29, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "begin": {
+      "description": "Begin offset of the import",
+      "type": "number"
+    },
+    "channel": {
+      "description": "Channel identifier used by the import",
+      "type": "number"
+    },
+    "end": {
+      "description": "End offset of the import",
+      "type": "number"
+    },
+    "id": {
+      "description": "Import job identifier",
+      "type": "string"
+    },
+    "progress": {
+      "description": "Import progress between 0 and 1 (1 means complete)",
+      "type": "number"
+    },
+    "size": {
+      "description": "Total number of units in the import",
+      "type": "number"
+    }
+  },
+  "required": [
+    "id"
+  ],
+  "type": "object"
+}

Addedv1.0.0Jan 2, 2026

TDQS

B3.1/5.0

Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered elsewhere. The description adds nothing beyond confirming the resource: it does not say the deletion is permanent, what happens when the id array holds several memories, or whether the unit can be restored. Also, it describes deleting 'a translation' singular while the schema's id parameter is an array.

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?

A single sentence, front-loaded with the verb and resource, with no filler or repetition of the name. Nothing could be trimmed without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists, so return values need not be explained, and annotations cover the destructive/idempotent profile. However, for a destructive delete requiring 5 of 8 parameters and supporting optional context fields (sentence_before/sentence_after), the description supplies no matching or scoping guidance, leaving it barely adequate.

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% across all 8 parameters, so the schema carries the full burden of parameter meaning (id format mem_xyz123, tuid, language codes, sentence context fields). The description contributes no additional param semantics, which is the baseline-3 case when the schema is this rich.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (deletes) plus resource (a translation from a translation memory in the Lara Translate account), which is enough to separate it from delete_memory, delete_glossary and delete_glossary_entry. It is slightly ambiguous whether the unit being removed is the 'translation' field or the whole translation unit, a distinction the annotation title supplies but the description does not.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as update_memory or delete_memory. The agent gets no signal about when this destructive call is appropriate versus other memory-mutating siblings.

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