Skip to main content
Glama
fruggr

Zendesk MCP Server by Fruggr

by fruggr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Update Article Translation

update_article_translation
DestructiveIdempotent

Update article content (title or full HTML body) in a specific locale, and save changes as a draft or publish them.

Instructions

Update article content (title, body) in a specific locale. For targeted edits on one or a few sections, prefer update_article_section — this tool replaces the FULL body and re-sends the entire article on each write. Use the article's source_locale (from get_article) for the default language, or another locale for translations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoNew full body (HTML) for this locale. Replaces the entire body — for a single-section edit prefer update_article_section. Omit to leave the body unchanged.
draftNoWhen true, keeps this translation as a draft; when false, publishes it.
titleNoNew title for this locale. Omit to leave the current title unchanged.
localeYesLocale of the translation to update, e.g. "en-us" or "fr". Use the source_locale (from get_article) to edit the default language.
article_idYesArticle ID — the numeric id of the article whose translation to update. Obtain it from list_articles or search_articles.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.24.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed5 schema fields changedv2.6.0
    • addedInput schema / properties / article_id / description
      Added value: +"Article ID — the numeric id of the article whose translation to update. Obtain it from list_articles or search_articles."
    • addedInput schema / properties / body / description
      Added value: +"New full body (HTML) for this locale. Replaces the entire body — for a single-section edit prefer update_article_section. Omit to leave the body unchanged."
    • addedInput schema / properties / draft / description
      Added value: +"When true, keeps this translation as a draft; when false, publishes it."
    • addedInput schema / properties / locale / description
      Added value: +"Locale of the translation to update, e.g. \"en-us\" or \"fr\". Use the source_locale (from get_article) to edit the default language."
    • addedInput schema / properties / title / description
      Added value: +"New title for this locale. Omit to leave the current title unchanged."
  3. Changed1 schema field changedv2.3.1
    • addedInput schema / additionalProperties
      Added value: +false
  4. First observedv1.7.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds real value beyond them by explaining WHY it is destructive: it 'replaces the FULL body and re-sends the entire article on each write.' It does not cover permission requirements or the omit-to-leave-unchanged semantics, but the core behavioral trait is disclosed.

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?

Three tight sentences with no filler; the destructive full-body replacement caveat and the sibling alternative are front-loaded before the locale guidance.

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?

For a destructive write tool with no output schema, the description covers the replacement behavior, the sibling alternative, and locale semantics. Only minor gaps remain (e.g., no mention of permission/auth requirements), which annotations partially cover.

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%, so the schema already documents every parameter including the source_locale/locale relationship. The description's locale guidance largely restates what the locale schema entry says, so baseline 3 applies.

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 ('Update article content (title, body) in a specific locale') and distinguishes itself from the closely-named siblings update_article and update_article_section. An agent can tell what it does and how it differs from neighboring tools.

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?

Explicitly names the alternative ('prefer update_article_section' for targeted edits) with the exact condition that selects it. Also gives positive routing guidance for locale selection ('Use the article's source_locale from get_article... or another locale for translations').

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

Deploy Server

Other Tools