Skip to main content
Glama
fruggr

Zendesk MCP Server by Fruggr

by fruggr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Compare Article Translations

compare_translations
Read-onlyIdempotent

Compare two locales of a Help Center article to see if the target translation needs updating, using freshness, outdated flags, and section alignment checks.

Instructions

Compare two locales of the same article to decide whether the target translation needs work, reporting independent signals instead of one ambiguous verdict. (1) Header — a "Freshness" verdict for the target, derived from the two translations' updated_at timestamps: if the source was edited after the target it is "likely behind, review recommended" (with the day gap), otherwise "up to date". This is the primary staleness signal and is always available. (2) Zendesk's own per-translation "outdated" flag for the target ("yes"/"no"/"unknown"), shown as a secondary overlay: it is only set through Guide's native "mark out of date" workflow and NOT by API edits, so a "no" does not by itself mean current — prefer Freshness. (3) A global structure check (section count and heading-tag sequence); on mismatch the header warns the per-index rows may be misaligned. (4) A per-section table matched by index, status "ok" (present in both), "missing" (present in source, absent in target) or "extra" (present in target, absent in source). (5) Per-section source/target word counts, INFORMATIONAL ONLY: a length difference between languages is normal and is deliberately NOT flagged as a divergence — do not read a word-count gap as an edit regression or staleness. Read-only; performs three Help Center GET calls (both translations plus the translations list for the outdated flag).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
article_idYesArticle ID — the numeric id of the Help Center article. Obtain it from list_articles or search_articles.
source_localeYesReference locale to diff against, e.g. "en-us". Usually the article source_locale (from get_article).
target_localeYesTarget locale to compare against source

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. Addedv2.15.0
  3. Removedv2.14.0
  4. Changed2 schema fields changedv2.6.0
    • changedInput schema / properties / article_id / description
      Previous value: -"Article ID"New value: +"Article ID — the numeric id of the Help Center article. Obtain it from list_articles or search_articles."
    • changedInput schema / properties / source_locale / description
      Previous value: -"Source (reference) locale"New value: +"Reference locale to diff against, e.g. \"en-us\". Usually the article source_locale (from get_article)."
  5. Changed1 schema field changedv2.3.1
    • addedInput schema / additionalProperties
      Added value: +false
  6. First observedv1.7.0

TDQS

A4.4/5.0
Behavior5/5

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

With annotations already covering the read-only/safe profile, the description adds substantial behavioral context: it discloses that the outdated flag is set only by Guide's native workflow and NOT by API edits, that structure mismatches warn of row misalignment, and that it performs three GET calls. This is exactly the beyond-schema context an agent needs to interpret output correctly.

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 purpose followed by five numbered signals, so structure is legible. It is dense and long, but with no output schema nearly every sentence carries necessary return-value semantics, so the length is largely earned.

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?

No output schema exists, and the description fully compensates by enumerating each returned signal (Freshness, outdated flag, structure check, per-section table, word counts) and their semantics. For a read-only comparison tool, nothing an agent needs to call and interpret it is missing.

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 coverage is 100%, so all three parameters are already documented with descriptions. The description consistently uses 'source' and 'target' but adds no format or constraint details beyond what the schema provides, 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 (compare) and resource (two locales of the same article) plus the decision it supports (whether the target translation needs work). An agent can distinguish this from siblings like find_translation_gaps or list_article_translations without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Strong guidance on how to use the result — 'prefer Freshness' over the outdated flag, and warnings that word-count gaps must not be treated as divergence. However, it never explicitly names when to choose this tool over sibling gap-analysis tools, so the comparison framing is left implicit.

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