Skip to main content
Glama
fruggr

Zendesk MCP Server by Fruggr

by fruggr

Create or Update a Section Translation

set_section_translation
DestructiveIdempotent

Create or update a section translation in a given locale and publish it to make the section accessible even if only its articles are translated.

Instructions

Create or update the translation of a Help Center section in one locale, and return the resulting translation (locale, localized name, draft state). Creates the translation when the locale has none and updates it otherwise, so no listing call is needed first; only the fields you pass are written, which makes "publish this draft" a single draft: false. Use it to make a section reachable in a locale where its articles are already translated — a gap find_translation_gaps reports and list_sections cannot explain.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoLocalized section name for this locale (sent as the API's translation `title`). Required when the locale has no translation yet; omit on an existing one to leave its name untouched, for instance when only publishing a draft.
draftNoPublication state: false publishes the translation, making the section visible to end users in this locale; true keeps (or puts) it back as a draft. Defaults to false when creating; omit on an existing translation to leave its state unchanged.
localeYesLocale to write, e.g. "fr" or "de". Must be an active locale of the Help Center (zendesk-hc://topology lists them); list_section_translations shows which ones the section already has.
section_idYesSection ID — the numeric id of the section whose translation to write. Obtain it from list_sections, find_translation_gaps or the zendesk-hc://topology resource.
descriptionNoLocalized section description for this locale (sent as the API's translation `body`). Omit to leave an existing description untouched; pass an empty string to clear it.
Behavior5/5

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

Beyond annotations (readOnly=false, destructive=true, idempotent=true), the description discloses the upsert behavior (creates when absent, updates otherwise), partial-write semantics ('only the fields you pass are written'), and the use of draft:false to publish. It also specifies the return payload (locale, localized name, draft state), which is not already provided by annotations or schema.

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?

The description is three sentences, front-loaded with the primary function, and every sentence delivers distinct value: purpose, operational detail, and use-case context. There is no fluff or repetition.

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 tool with 5 parameters, no output schema, and moderate complexity (upsert plus draft states), the description covers the operation, scope, partial-update behavior, return value, and a concrete use case. It also differentiates from related sibling tools sufficiently.

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 description coverage is 100%, so this is a baseline 3. However, the tool description adds strategic context beyond the schema by explaining how parameters interact, such as 'only the fields you pass are written' and 'publish this draft' being a single draft:false call. This helps agents understand parameter semantics in context, though most details are already in 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?

The description begins with a specific verb phrase 'Create or update' and clearly identifies the resource: 'the translation of a Help Center section in one locale'. It also distinguishes the tool from siblings by referencing find_translation_gaps and list_sections, clarifying its unique role.

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?

The description provides explicit when-to-use guidance: 'Use it to make a section reachable in a locale where its articles are already translated — a gap find_translation_gaps reports and list_sections cannot explain.' It also states that no listing call is needed first, implying when not to use list_section_translations as a precursor.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fruggr/zendesk-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server