Skip to main content
Glama
fruggr

Zendesk MCP Server by Fruggr

by fruggr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List Help Center Sections

list_sections
Read-onlyIdempotent

Lists Zendesk Help Center sections so you can browse categories, filter by category_id, and paginate to related articles using section IDs.

Instructions

List Help Center sections. Sections are the middle level of the Guide hierarchy (category → section → article) and group related articles; each entry includes its id, name, category_id and locale. Results are cursor-paginated. Pass category_id to list only one category's sections (ids come from list_categories), then use a section id with list_articles. Pass a locale to read section names in that translation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cursorNoPagination cursor from a previous response; omit for the first page.
localeNoLocale for section names (e.g., "en-us", "fr"). Defaults to the Help Center default locale.
page_sizeNoSections per page (1-100, default 100).
category_idNoRestrict to sections of this category (id from list_categories). Omit to list every section.

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. Changed1 schema field changedv2.3.1
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed4 schema fields changedv2.2.0
    • addedInput schema / properties / category_id / description
      Added value: +"Restrict to sections of this category (id from list_categories). Omit to list every section."
    • addedInput schema / properties / cursor / description
      Added value: +"Pagination cursor from a previous response; omit for the first page."
    • addedInput schema / properties / locale / description
      Added value: +"Locale for section names (e.g., \"en-us\", \"fr\"). Defaults to the Help Center default locale."
    • addedInput schema / properties / page_size / description
      Added value: +"Sections per page (1-100, default 100)."
  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 readOnly/idempotent/non-destructive, so the safety bar is low. The description adds real behavioral context the annotations lack: results are cursor-paginated and locale defaults to the Help Center default if omitted. It stops short of describing ordering or empty-page behavior.

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, then hierarchy, return fields, pagination and workflow in four tight sentences. Each sentence carries distinct information, though the hierarchy explanation is somewhat parenthetical to the call itself.

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, but the description compensates by listing the returned fields, the pagination mechanism, and the default locale behavior. Combined with full schema coverage, an agent has everything needed to call it correctly on the first try.

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 cursor, locale, page_size and category_id with types, defaults and bounds. The description largely restates these ('ids come from list_categories', 'pass a locale'), adding only light sourcing context rather than new semantics. 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 ('List Help Center sections') and situates it precisely in the Guide hierarchy (category → section → article), which cleanly separates it from siblings list_categories and list_articles. It also enumerates the returned fields, so an agent knows exactly what it gets.

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 routes the agent: pass category_id (which comes from list_categories) to scope to one category, then use a returned section id with list_articles. This names the prerequisite call and the downstream call, covering both when and how to use it.

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