Skip to main content
Glama

Obriym CRM

by com.obriym-crm
OverviewDiscussionsAdmin

Set a product translation

upsert_product_translation
DestructiveIdempotent

Write ONE language of ONE product's translation — title, description, keywords, colour, material, pattern and its characteristics (attributes: keyed by the characteristic's name exactly as get_product returns it, each with a translated name and/or value) in that language — keeping the other languages and every field not named. A characteristic name the product does not have is refused with the list of its names. Call list_content_locales first and write only an offered language, never the base one. Use it when a marketplace publishes in another language (ebay.it reads Italian, Prom and Rozetka read uk and ru) or inspect_ebay_listings reports a title over 80 characters in the site's language. Translate the product's OWN text from get_product and add no fact it does not state; show the user the text before writing. For a product that belongs to a model the translation is the model's, so every article of it changes. Saves through the CRM's own Переклади tab operation with its version check (on CONFLICT re-read the product and retry). Idempotent. The result echoes the workspace.

Input Schema

NameRequiredDescriptionDefault
idYesThe product id returned by search_products or get_product.
nameNoThe product title in this language. eBay shows at most 80 characters. An empty string clears it, so the base name publishes.
colorNoColour name.
localeYesThe language to write, as an ISO 639-1 code — for a marketplace, the site's own language (it on ebay.it, de on ebay.de, uk or ru for Prom and Rozetka).
patternNoPattern.
keywordsNoSearch keywords in this language; replaces the list.
materialNoMaterial.
attributesNoTranslated characteristics, keyed by the characteristic's BASE name exactly as the product shows it (see get_product). Each key is merged into what is stored; other characteristics and languages stay. A name the product does not have is refused.
descriptionNoThe description in this language. An empty string clears it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / attributes
      Added value: +{
+  "additionalProperties": {
+    "properties": {
+      "name": {
+        "description": "The characteristic's name in this language. An empty string clears it.",
+        "maxLength": 160,
+        "type": "string"
+      },
+      "value": {
+        "description": "The characteristic's value in this language. An empty string clears it.",
+        "maxLength": 500,
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "description": "Translated characteristics, keyed by the characteristic's BASE name exactly as the product shows it (see get_product). Each key is merged into what is stored; other characteristics and languages stay. A name the product does not have is refused.",
+  "propertyNames": {
+    "maxLength": 160,
+    "minLength": 1,
+    "type": "string"
+  },
+  "type": "object"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructive=true and idempotent=true, but the description adds substantial extra context: what is preserved (other languages and every unnamed field), refusal behavior for an unknown characteristic name ('refused with the list of its names'), the underlying write path with its version check ('on CONFLICT re-read the product and retry'), model-level propagation, and the echoed result. This goes well beyond the structured safety hints.

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?

Front-loaded with the core action and dense with useful constraints, but the single long paragraph packs several distinct concerns (write semantics, locale precondition, translation sourcing, conflict retry) into run-on sentences that could be split for scannability. Nearly every sentence earns its place, so waste is low.

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 9-param nested mutation tool with no output schema, the description covers the critical gaps: conflict handling, idempotency, preservation of other fields, refusal paths, and the result shape. An agent has everything needed to call it correctly without opening the schema.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real merge semantics not in the schema: attributes are keyed by the characteristic's BASE name 'exactly as get_product returns it', each with a translated name/value, and unnamed fields/languages are kept rather than replaced. It also adds the 'never the base' locale constraint, though per-field clearing behavior largely duplicates the schema.

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 with scope: 'Write ONE language of ONE product's translation — title, description, keywords, colour, material, pattern and its characteristics'. This clearly distinguishes it from the sibling upsert_brand_translation/upsert_category_translation by naming the exact target (product) and enumerable fields.

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?

Explicit preconditions and alternatives: 'Call list_content_locales first and write only an offered language, never the base one', plus two concrete triggering scenarios (marketplace reads another language; inspect_ebay_listings reports a title over 80 characters). It also gives the source-of-truth rule ('Translate the product's OWN text from get_product') and a human-in-the-loop step ('show the user the text before writing').

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

All Obriym CRM 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