Skip to main content
Glama
Sign In
Zendesk MCP Server by Fruggr

Zendesk MCP Server by Fruggr

by fruggr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create Zendesk Ticket

create_ticket

Open a new Zendesk support ticket with subject, description, priority, type, assignee, and tags. The description becomes the ticket's first public comment, and the new ticket ID is returned.

Instructions

Create a new Zendesk support ticket with subject, description, and optional priority/type/assignee/tags. The description becomes the first public comment of the ticket, and the new ticket id is returned. After creation, use update_ticket to change status or assignee, add_public_comment or add_private_note to reply, and manage_tags to adjust tags. Look up valid assignee_id / group_id and custom field ids via search_users or your Zendesk admin settings. Discover custom field ids and their accepted option values with list_ticket_fields.

Input Schema

NameRequiredDescriptionDefault
tagsNoTags to set on the new ticket. Each tag is a single lowercase token (join multi-word tags with an underscore). Use manage_tags later to add or remove individual tags.
typeNoTicket type. One of problem, incident, question, task.
subjectYesTicket subject — the short summary line shown in ticket lists and search results.
group_idNoId of the group to assign the ticket to.
priorityNoTicket priority. One of urgent, high, normal, low.
assignee_idNoUser id of the agent to assign the ticket to.
descriptionYesTicket description — the body of the request. It becomes the ticket's first public comment (visible to the requester). Markdown is rendered (**bold**, lists, links): wrap code, identifiers containing _ or * and <placeholders> in backticks so they show literally. HTML is not rendered (tags show as literal text), so do not send HTML.
custom_fieldsNoCustom field values as { id, value } pairs (field ids come from your Zendesk admin settings). Call list_ticket_fields first to discover the numeric field ids and, for dropdown/multiselect fields, the exact option values Zendesk accepts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.9.1
    • changedInput schema / properties / description / description
      Previous value: -"Ticket description — the body of the request. It becomes the ticket's first public comment (visible to the requester)."New value: +"Ticket description — the body of the request. It becomes the ticket's first public comment (visible to the requester). Markdown is rendered (**bold**, lists, links): wrap code, identifiers containing _ or * and <placeholders> in backticks so they show literally. HTML is not rendered (tags show as literal text), so do not send HTML."
  2. Changed2 schema fields changedv3.7.0
    • addedInput schema / properties / custom_fields / items / properties / id / description
      Added value: +"Numeric id of the ticket field to set, as listed by list_ticket_fields."
    • addedInput schema / properties / custom_fields / items / properties / value / description
      Added value: +"Value typed after the field: the option tag (a string) for a dropdown, an array of option tags for a multiselect, true or false for a checkbox, text or a number for a text or numeric field. For any other type (a date, a lookup), follow the type list_ticket_fields reports; it also lists each dropdown's accepted tags."
  3. Changed1 schema field changedv3.3.1
    • addedInput schema / properties / custom_fields / items / additionalProperties
      Added value: +false
  4. 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"
  5. Changed1 schema field changedv2.9.0
    • changedInput schema / properties / custom_fields / description
      Previous value: -"Custom field values as { id, value } pairs (field ids come from your Zendesk admin settings)."New value: +"Custom field values as { id, value } pairs (field ids come from your Zendesk admin settings). Call list_ticket_fields first to discover the numeric field ids and, for dropdown/multiselect fields, the exact option values Zendesk accepts."
  6. Changed3 schema fields changedv2.6.0
    • changedInput schema / properties / description / description
      Previous value: -"Ticket description"New value: +"Ticket description — the body of the request. It becomes the ticket's first public comment (visible to the requester)."
    • changedInput schema / properties / subject / description
      Previous value: -"Ticket subject"New value: +"Ticket subject — the short summary line shown in ticket lists and search results."
    • changedInput schema / properties / tags / description
      Previous value: -"Tags to set on the ticket."New value: +"Tags to set on the new ticket. Each tag is a single lowercase token (join multi-word tags with an underscore). Use manage_tags later to add or remove individual tags."
  7. Changed1 schema field changedv2.3.1
    • addedInput schema / additionalProperties
      Added value: +false
  8. Changed6 schema fields changedv2.2.0
    • addedInput schema / properties / assignee_id / description
      Added value: +"User id of the agent to assign the ticket to."
    • addedInput schema / properties / custom_fields / description
      Added value: +"Custom field values as { id, value } pairs (field ids come from your Zendesk admin settings)."
    • addedInput schema / properties / group_id / description
      Added value: +"Id of the group to assign the ticket to."
    • addedInput schema / properties / priority / description
      Added value: +"Ticket priority. One of urgent, high, normal, low."
    • addedInput schema / properties / tags / description
      Added value: +"Tags to set on the ticket."
    • addedInput schema / properties / type / description
      Added value: +"Ticket type. One of problem, incident, question, task."
  9. First observedv1.7.0

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the annotations (write, open-world, non-idempotent), the description discloses a real side effect: the description body becomes the first public comment visible to the requester, and markdown is rendered while HTML is not. That is valuable context an agent would otherwise miss. It stops short of stating who the requester becomes (no requester_id parameter exists) or any permission/auth requirements, which leaves a meaningful gap for a creation tool.

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?

Four sentences, front-loaded with what is created and what is returned, followed by follow-up routing and lookup guidance. Every sentence carries information an agent needs; nothing is repeated from the schema or annotations.

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?

With no output schema, the description compensates by stating the new ticket id is returned, and it covers side effects, follow-up tools and id-discovery for the non-obvious parameters. The one unresolved question for a creation tool is who the ticket is created for / whether the caller becomes the requester, which is not addressed.

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 coverage is 100%, so the baseline is 3, but the description adds actionable meaning by pointing to search_users for assignee_id/group_id and to list_ticket_fields for custom field ids and accepted dropdown tags. It does not add anything about subject or priority beyond what the schema enums and descriptions already state.

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 first sentence names a specific verb and resource ('Create a new Zendesk support ticket') and enumerates the fields it accepts (subject, description, optional priority/type/assignee/tags), so an agent can immediately separate it from read tools like get_ticket and from adjacent creators such as create_request or create_article.

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?

It explicitly routes post-creation work to update_ticket, add_public_comment, add_private_note and manage_tags, and states prerequisites for the harder parameters (resolve assignee_id via search_users, discover custom field ids and accepted option values via list_ticket_fields). This is a complete when/when-next/where-to-look map rather than a vague hint.

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