de en es ja ko ru zh

Zendesk MCP Server

Name: Zendesk MCP Server
Author: koundinya

by koundinya

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Zendesk MCP 統合設定ガイド

リポジトリのセットアップ

リポジトリをクローンします。

git clone https://your-repo-url/mcp-experiments.git
cd mcp-experiments/zd-mcp-server

依存関係をインストールします:
```
npm install
```

開発環境で環境変数を設定します。

export ZENDESK_EMAIL="your-email@example.com"
export ZENDESK_TOKEN="your-zendesk-api-token"
export ZENDESK_SUBDOMAIN="your-zendesk-subdomain"

Related MCP server: Zendesk MCP Server

プロジェクトの構築

TypeScript プロジェクトをビルドします。
```
npm run build
```
これにより、TypeScript ファイルがdistディレクトリ内の JavaScript にコンパイルされます。
開発には以下を使用できます:
```
npm run dev
```

Claudeデスクトップアプリでインストール

Claude Desktop 構成ファイル ( claude_desktop_config.json ) を更新します。

{
  "tools": {
    "zendesk": {
      "command": "node",
      "env": {
        "ZENDESK_EMAIL": "internal@z3nmail.com",
        "ZENDESK_TOKEN": "your-zendesk-api-token",
        "ZENDESK_SUBDOMAIN": "your-zendesk-subdomain"
      },
      "args": [
        "/path/to/mcp-experiments/zd-mcp-server/dist/index.js"
      ]
    }
  }
}

環境変数を実際の Zendesk 資格情報に置き換えます。
ビルドした index.js ファイルの場所と一致するようにパスを更新します。
変更を有効にするには、Claude デスクトップアプリケーションを再起動します。

利用可能なZendeskツール

MCP Zendesk 統合では、次の機能が提供されます。

zendesk_get_ticket - IDでチケットを取得します
zendesk_get_ticket_details - コメントを含むチケットの詳細を取得します
zendesk_search - Zendeskクエリ構文でチケットを検索します
zendesk_create_ticket - 新しいチケットを作成する
zendesk_update_ticket - チケットのプロパティを更新します
zendesk_add_private_note - チケットに内部メモを追加します
zendesk_add_public_note - チケットにパブリックコメントを追加します

認証設定

Zendesk 管理センターで API トークンを生成します。
- 管理センター > アプリと統合 > API > Zendesk API に移動します。
- APIトークンを追加してコピーする
MCP設定でメールアドレスとAPIトークンを使用します

トラブルシューティング

認証エラーが発生した場合は、APIトークンが有効であることを確認してください。
Zendeskのサブドメインが正しいことを確認してください
環境変数が正しく設定されているか確認する
変更を加えたらMCPサーバーを再起動します

Available Tools

7 tools

zendesk_add_private_noteC

Add a private internal note to a Zendesk ticket

ParametersJSON Schema

Name	Required	Description	Default
`note`	Yes	The content of the private note
`ticket_id`	Yes	The ID of the ticket to add a note to

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, and the description fails to disclose behavioral traits such as permissions required, side effects, constraints (e.g., ticket status), or whether the note is appended. It only states the basic action.

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?

The description is a single short sentence, concise and front-loaded. However, it may be too terse, sacrificing completeness for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params, no output schema, no annotations), the description provides the core purpose but lacks context about ticket state requirements, visibility, or usage notes. It is adequate but not comprehensive.

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 baseline is 3. The description adds no additional meaning beyond the schema, which already provides descriptions for both parameters. No extra context is given.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (add) and the resource (private internal note to a Zendesk ticket). It implicitly distinguishes from the sibling 'zendesk_add_public_note' by specifying 'private', but does not explicitly differentiate.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like public note or update ticket. The description lacks context on appropriate scenarios or exclusions.

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

zendesk_add_public_noteB

Add a public comment to a Zendesk ticket

ParametersJSON Schema

Name	Required	Description	Default
`comment`	Yes	The content of the public comment
`ticket_id`	Yes	The ID of the ticket to add a comment to

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It fails to mention side effects, permissions, or whether comments are appended. The description is too minimal.

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?

The description is a single sentence with no wasted words. However, it could be slightly expanded to include key context without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple operation and no output schema, the description is adequate but lacks mention of return values or error conditions, leaving some gaps.

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 description coverage is 100%, so parameters are already well-defined. The description adds no extra meaning beyond the schema, resulting in a baseline score.

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 clearly states the verb 'Add' and the resource 'public comment to a Zendesk ticket', distinguishing it from the sibling 'zendesk_add_private_note'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'zendesk_add_private_note' or prerequisites such as ticket existence. Usage is only implied.

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

zendesk_create_ticketB

Create a new Zendesk ticket

ParametersJSON Schema

Name	Required	Description
`description`	Yes	The initial description or comment for the ticket
`priority`	No	The priority of the ticket
`status`	No	The status of the ticket
`subject`	Yes	The subject of the ticket
`tags`	No	Tags to add to the ticket
`type`	No	The type of the ticket

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the action. Does not disclose that it is a write operation, requires authentication, or may have rate limits. The description is too minimal.

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 a single, efficient sentence with no waste. It is front-loaded and directly conveys the purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain return values, error behavior, or optional versus required fields beyond what schema provides.

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 baseline is 3. The description adds no extra parameter meaning beyond the schema's own descriptions.

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 'Create a new Zendesk ticket' clearly states the verb (create) and resource (ticket), distinguishing it from sibling tools like update_ticket or get_ticket.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives such as zendesk_update_ticket. Lacks context of prerequisites or constraints.

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

zendesk_get_ticketC

Get a Zendesk ticket by ID

ParametersJSON Schema

Name	Required	Description	Default
`ticket_id`	Yes	The ID of the ticket to retrieve

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description must carry full burden. It only states the basic function without mentioning any behavioral traits like return format, required permissions, or rate limits.

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 extremely concise: 'Get a Zendesk ticket by ID' is front-loaded and contains no unnecessary words or details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple retrieval tool, the description is incomplete. It lacks information about the response structure, which is not covered by an output schema, and does not differentiate from similar sibling tools.

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?

The input schema has only one parameter with a description, achieving 100% coverage. The description does not add extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (Get) and resource (a Zendesk ticket by ID). However, among many sibling tools like 'get_ticket_details', 'get_ticket_audits', it does not differentiate what this specific tool returns versus those.

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

Usage Guidelines2/5

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

No guidance on when to use this tool over alternatives like 'get_ticket_details' or 'get_ticket_metrics'. The context of use is implied but not explicit.

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

zendesk_get_ticket_detailsC

Get detailed information about a Zendesk ticket including comments

ParametersJSON Schema

Name	Required	Description	Default
`ticket_id`	Yes	The ID of the ticket to retrieve details for

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only states that the tool returns details including comments, but does not mention read-only nature, rate limits, or any side effects. This is insufficient for a read operation.

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?

The description is a single, concise sentence that is clear and front-loaded. It could be slightly expanded to include more useful context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is incomplete. It does not specify what 'detailed information' includes beyond comments, such as status, priority, attachments, etc. More detail would aid accurate invocation.

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% with a clear description for the single parameter 'ticket_id'. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves detailed information about a Zendesk ticket including comments. It uses a specific verb and resource, but does not differentiate itself from the sibling tool 'zendesk_get_ticket', which may have similar functionality.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'zendesk_get_ticket' or others. No use cases, prerequisites, or exclusions are mentioned.

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

zendesk_searchB

Search for Zendesk tickets based on a query

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query (e.g., 'status:open', 'priority:urgent', 'tags:need_help')

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose all behavioral traits. It only says 'Search for Zendesk tickets' without clarifying output format, pagination, rate limits, or whether it is read-only. This is insufficient for an agent to understand side effects.

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 a single, concise sentence that clearly conveys the tool's purpose with no wasted words. It is front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the tool being simple with one parameter and no output schema, the description lacks critical context such as what the search returns (full tickets or summaries), pagination behavior, or any limitations. This leaves the agent underinformed.

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% for the single parameter. The description adds value by providing example query syntax (e.g., 'status:open', 'tags:need_help'), which enhances understanding beyond the schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches for Zendesk tickets based on a query, but it does not distinguish this from sibling tools like zendesk_search_by_brand and zendesk_search_by_field which have similar purposes.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, such as zendesk_search_by_brand or zendesk_get_ticket. The description simply states what it does without context for appropriate usage.

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

zendesk_update_ticketB

Update a Zendesk ticket's properties

ParametersJSON Schema

Name	Required	Description
`assignee_id`	No	The ID of the agent to assign the ticket to
`priority`	No	The new priority of the ticket
`status`	No	The new status of the ticket
`subject`	No	The new subject of the ticket
`tags`	No	Tags to set on the ticket (replaces existing tags)
`ticket_id`	Yes	The ID of the ticket to update
`type`	No	The new type of the ticket

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so the description must fully disclose behavioral traits. It fails to mention critical details like whether updates are partial or replace values, required permissions, idempotency, or side effects (e.g., notifications).

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?

A single, concise sentence with no wasted words. All content is relevant and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 7 parameters and no output schema, the description provides no information about return values, partial update behavior, or restrictions. It is inadequate for a mutation tool with no annotations.

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%, and the description adds no meaning beyond the schema's parameter descriptions. It simply restates 'update properties' without elaborating on how parameters interact (e.g., tags replace existing tags). Baseline 3 is appropriate.

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 'Update a Zendesk ticket's properties' uses a specific verb ('Update') and resource ('ticket properties'), clearly distinguishing it from sibling tools like 'zendesk_create_ticket' and 'zendesk_get_ticket'.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool vs alternatives (e.g., adding notes via 'zendesk_add_public_note'). Usage is implied by the name and context, but the description lacks exclusions or prerequisites.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv1.0.0Apr 11, 2025
- First observedzendesk_add_private_note
- First observedzendesk_add_public_note
- First observedzendesk_create_ticket
- First observedzendesk_get_ticket
- First observedzendesk_get_ticket_details
- First observedzendesk_search
- First observedzendesk_update_ticket

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored 2026-04-18 10:30 across 7 tools

Disambiguation3/5

Most tools have distinct purposes, but there is notable overlap between 'zendesk_get_ticket' and 'zendesk_get_ticket_details'—both retrieve ticket information, which could confuse agents about which to use for basic vs. detailed data. The other tools are clearly differentiated by their actions (create, update, search, add notes).

Naming Consistency5/5

All tool names follow a consistent 'zendesk_verb_noun' pattern with snake_case, using clear verbs like 'add', 'create', 'get', 'search', and 'update'. This predictability makes it easy for agents to understand and navigate the toolset.

Tool Count5/5

With 7 tools, the server is well-scoped for managing Zendesk tickets, covering core operations like create, read, update, search, and adding notes. This count is appropriate, avoiding bloat while providing essential functionality for the domain.

Completeness4/5

The toolset covers key CRUD and lifecycle aspects for Zendesk tickets, including creation, retrieval, updating, searching, and adding notes. A minor gap is the lack of a tool to delete tickets, but this is often intentional in support systems, and agents can work around it.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

ZoteusOAuth
io.github.oscardvs
Zotero MCP server for Claude and ChatGPT: search, citations, safe writes, PDF passages and pages.
Research & Data Search
144
zendesk A
io.usefulapi
Read tickets, users, orgs, macros and satisfaction ratings; create, update and comment on tickets.
Customer Support CRM
191
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
LeadFoxConnectOAuth
io.github.LeadFox-Shay
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
Marketing CRM
2

Related MCP Servers

zendesk-mcp-server
Customer Support Knowledge & Memory
reminia
A
license
A
quality
B
maintenance
This server provides a comprehensive integration with Zendesk. Retrieving and managing tickets and comments. Ticket analyzes and response drafting. Access to help center articles as knowledge base.
Updated a month ago (2026-08-27 18:12 UTC)
7
121
Apache 2.0
Zendesk MCP Server
Customer Support Search RAG Systems
larryfang
F
license
Not graded
quality
D
maintenance
A lightweight, AI-native server that enables GPT-based AI agents to fetch real-time customer and organization context from Zendesk APIs dynamically.
Updated a year ago (2025-04-12 10:44 UTC)
-
Zendesk API MCP Server
JurreBrandsenInfoSupport
F
license
C
quality
D
maintenance
A comprehensive server that allows users to interact with the Zendesk API, providing tools and resources for managing Zendesk Support, Talk, Chat, and Guide products including tickets, users, organizations, and more.
Updated a year ago (2025-08-25 09:10 UTC)
49
4 npm
-
mcp-server-zendesk
Customer Support
KalchevS
A
license
Not graded
quality
C
maintenance
Enables AI assistants to search tickets, manage tags, create tickets, inspect automations, and more in Zendesk.
Updated a month ago (2026-08-26 15:15 UTC)
MIT

Appeared in Searches

Software for Specific Professions or Business Sectors