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.

Input Schema

TableJSON 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

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

The admin_* tools are clearly separated by permission level, and most tools have distinct resource+action purposes. There is some overlap between admin_create_news and draft_news (both create news) and between admin_translate_news and submit_news_translation (both translate), but the descriptions clarify the differences. Overall, an agent can usually tell tools apart.

Naming Consistency4/5

Most tools follow a snake_case verb_noun pattern (admin_create_news, get_news, search_jobs). Minor inconsistencies include apply_to_job instead of apply_job, and using get_my_applications vs list_my_resumes for similar user-specific listings. Despite these, the naming is predictable and readable.

Tool Count4/5

Seventeen tools is slightly heavy, but the server covers multiple domains: news management, translations, job search/application, and platform statistics. Each tool appears to serve a distinct need, so the count is reasonable for the platform's scope.

Completeness3/5

The core workflows are covered: searching and applying to jobs, reading and translating news, and getting stats. However, there is no delete or non-admin edit for news articles (only resubmit_news for flagged drafts), and no resume creation/update tools. These gaps require workarounds or admin privileges.

Resources

Need Help?