Skip to main content
Glama
fruggr

Zendesk MCP Server by Fruggr

by fruggr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List Help Center Articles

list_articles
Read-onlyIdempotent

Retrieve article metadata from Zendesk Help Center with optional section, locale, sorting, pagination, and translation-locale filters; use get_article for full content.

Instructions

List articles (metadata only, no body). Use get_article for full content. Optionally filter by section ID and locale. Supports sort_by ("title", "created_at", "updated_at") and include_translations: true to show available translation locales per article. Note: include_translations must be re-sent on each paginated request.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cursorNoPagination cursor from a previous response; omit for the first page.
localeNoRestrict to a single locale, e.g. "en-us" or "fr". Omit for the default locale.
sort_byNoField to sort by; "position" (the default) is the manual order set in Guide.position
page_sizeNoArticles per page (1-100, default 100).
section_idNoRestrict the listing to one section (numeric id from list_sections). Omit to list articles across all sections.
sort_orderNoSort direction: ascending or descending.asc
include_translationsNoInclude available translation locales per article (causes 1 extra API call per article)

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. Changed4 schema fields changedv2.6.0
    • addedInput schema / properties / locale / description
      Added value: +"Restrict to a single locale, e.g. \"en-us\" or \"fr\". Omit for the default locale."
    • addedInput schema / properties / section_id / description
      Added value: +"Restrict the listing to one section (numeric id from list_sections). Omit to list articles across all sections."
    • changedInput schema / properties / sort_by / description
      Previous value: -"Sort field"New value: +"Field to sort by; \"position\" (the default) is the manual order set in Guide."
    • changedInput schema / properties / sort_order / description
      Previous value: -"Sort direction"New value: +"Sort direction: ascending or descending."
  3. Changed3 schema fields changedv2.3.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / cursor / description
      Added value: +"Pagination cursor from a previous response; omit for the first page."
    • addedInput schema / properties / page_size / description
      Added value: +"Articles per page (1-100, default 100)."
  4. First observedv1.7.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare the read-only, idempotent, non-destructive profile. The description adds real behavioral value beyond that: metadata-only returns, and the important caveat that include_translations must be re-sent on each paginated request (plus its per-article API cost).

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?

Front-loads the core purpose in the first clause, then adds filtering, sorting, and the pagination caveat in tight, waste-free sentences. No redundancy that could mislead.

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 read-only listing tool with no output schema and full schema coverage, the description supplies everything needed to call it correctly: scope, return granularity, optional filters, sorting, and the pagination re-send caveat.

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 the schema already documents all seven parameters in detail. The description adds little, and its enumeration of sort_by values ("title", "created_at", "updated_at") is actually incomplete versus the schema, which also includes "position" as the default.

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 ("List articles") and immediately bounds the scope ("metadata only, no body"). It also names the sibling get_article as the tool for full content, so an agent can distinguish the two without opening either 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?

Explicitly routes the agent to get_article when full content is needed, and describes the optional section/locale filtering context. It does not address when to prefer the sibling search_articles over this listing tool, so a routing gap remains.

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