mcp

submit_news_translation

Publish your own translation of an already-published English article into a new locale. Unlike draft_news's target_locales (which asks Datronis's own server to translate it), the translated title/body you pass here is published as-is — you (the calling AI) do the translation. Open to anyone with an account, same as draft_news; the source article must already be live, and only one translation may exist per (article, locale) — a locale that already has a translation is rejected, use get_missing_news_translations to find real gaps first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "news_id": "<news_id>",
      "locale": "<locale>",
      "title": "<title>",
      "body": "<body>"
    },
    "name": "submit_news_translation"
  }
}

Input Schema

Name	Required	Description	Default
`body`	Yes	Translated body, in the target locale — HTML or plain text, same format as the source
`title`	Yes	Translated title, in the target locale
`locale`	Yes	2-letter target locale code (e.g. "fi") — see get_missing_news_translations for what a given article still needs
`api_key`	No	Your Datronis personal access token (starts with "dtk_"). Generate one at /app/api-keys/. Required unless sent as an `Authorization: Bearer <token>` HTTP header instead (preferred — see search_jobs' api_key description for why). Publishing is open to anyone with an account — this token exists for rate-limiting and an audit trail, not to gate who may publish.
`news_id`	Yes	The news_id of the published English source article (from get_news or get_missing_news_translations)
`content_format`	No	Body format. Use "markdown" for headings, tables, lists, code blocks, links and images; use "html" for rich HTML with classes and inline CSS. Defaults to html for backward compatibility.	html

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 17, 2026

addedInput schema / properties / content_format

Added value: +{
+  "default": "html",
+  "description": "Body format. Use \"markdown\" for headings, tables, lists, code blocks, links and images; use \"html\" for rich HTML with classes and inline CSS. Defaults to html for backward compatibility.",
+  "enum": [
+    "html",
+    "markdown"
+  ],
+  "type": "string"
+}

Changed2 schema fields changedAug 4, 2026

changedInput schema / properties / api_key / description

Previous value: -"Required: your Datronis personal access token (starts with \"dtk_\"). Generate one at /app/api-keys/. Publishing is open to anyone with an account — this token exists for rate-limiting and an audit trail, not to gate who may publish."New value: +"Your Datronis personal access token (starts with \"dtk_\"). Generate one at /app/api-keys/. Required unless sent as an `Authorization: Bearer <token>` HTTP header instead (preferred — see search_jobs' api_key description for why). Publishing is open to anyone with an account — this token exists for rate-limiting and an audit trail, not to gate who may publish."

changedInput schema / required

Previous value: -[
-  "news_id",
-  "locale",
-  "title",
-  "body",
-  "api_key"
-]New value: +[
+  "news_id",
+  "locale",
+  "title",
+  "body"
+]

AddedJul 24, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries full behavioral burden and excellently discloses constraints: 'published as-is' (no server translation), source must be live, one translation per (article, locale), duplicate rejection, and the auth token's purpose (rate limiting/audit trail). This is rich, transparent context.

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?

The description is compact given the tool's complexity, with three long sentences each carrying distinct info: purpose, contrast, and constraints. It is slightly dense but well-structured and front-loaded with the core action.

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

Completeness4/5

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

Given no output schema or annotations, the description covers publishing rules, preconditions, duplicate behavior, and auth. It omits what a successful response looks like (e.g., created translation ID), which would improve completeness, but the provided context is substantial for a complex write operation.

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. The description adds value by clarifying the api_key's role ('not to gate who may publish'), pointing news_id to get_news/get_missing_news_translations, and suggesting locale values come from get_missing_news_translations. This goes beyond 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?

The description opens with a specific verb+resource: 'Publish your own translation of an already-published English article into a new locale.' It clearly distinguishes from sibling draft_news by contrasting the translation mechanism, so the agent knows exactly what this tool does.

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 when-to-use vs alternatives: 'Unlike draft_news's target_locales...' tells the agent when not to use this tool and instead draft_news. It also directs to get_missing_news_translations to find valid gaps before publishing, providing a concrete workflow.

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

All mcp tools Inspect

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

Need Help?