Skip to main content
Glama
deenesjakoruzh
koundinya

Zendesk MCP Server

by koundinya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Zendesk MCP Server

npm version License: MIT

A Model Context Protocol (MCP) server that provides AI assistants like Claude with seamless integration to Zendesk Support. Enables natural language interactions with Zendesk tickets, allowing you to search, create, update, and manage support tickets through conversational AI.

✨ Features

  • 🎫 Complete Ticket Management: Create, read, update, and search Zendesk tickets

  • 💬 Comments & Notes: Add public comments and private internal notes

  • 🔍 Advanced Search: Search tickets using Zendesk's powerful query syntax

  • 🔗 Incident Management: Retrieve and manage linked incident tickets

  • 🏷️ Tag Management: Add and manage ticket tags and metadata

  • 🔒 Secure Authentication: Uses Zendesk API tokens for secure access

  • 🚀 Easy Installation: Available via npm, npx, or manual setup

Related MCP server: Zendesk MCP Server

🚀 Quick Start

Option 1: NPM Installation (Recommended)

npm install -g zd-mcp-server

Option 2: Use with npx (No Installation)

npx zd-mcp-server

Option 3: Development Setup

git clone https://github.com/koundinya/zd-mcp-server.git
cd zd-mcp-server
npm install
npm run build

⚙️ Configuration

Environment Variables

Set these environment variables in your system or MCP client configuration:

export ZENDESK_EMAIL="your-email@company.com"
export ZENDESK_TOKEN="your-zendesk-api-token"
export ZENDESK_SUBDOMAIN="your-company"  # from https://your-company.zendesk.com

Claude Desktop Setup

Add to your Claude Desktop configuration file:

Location:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%/Claude/claude_desktop_config.json

Configuration:

{
  "mcpServers": {
    "zendesk": {
      "command": "npx",
      "args": ["-y", "zd-mcp-server"],
      "env": {
        "ZENDESK_EMAIL": "your-email@company.com",
        "ZENDESK_TOKEN": "your-zendesk-api-token",
        "ZENDESK_SUBDOMAIN": "your-company"
      }
    }
  }
}

Alternative (if installed globally):

{
  "mcpServers": {
    "zendesk": {
      "command": "zd-mcp-server",
      "env": {
        "ZENDESK_EMAIL": "your-email@company.com",
        "ZENDESK_TOKEN": "your-zendesk-api-token",
        "ZENDESK_SUBDOMAIN": "your-company"
      }
    }
  }
}

Cursor IDE Setup

Add to ~/.cursor/mcp.json or .cursor/mcp.json in your project:

{
  "mcpServers": {
    "zendesk": {
      "command": "npx",
      "args": ["-y", "zd-mcp-server"],
      "env": {
        "ZENDESK_EMAIL": "your-email@company.com",
        "ZENDESK_TOKEN": "your-zendesk-api-token",
        "ZENDESK_SUBDOMAIN": "your-company"
      }
    }
  }
}

Other MCP Clients

For other MCP-compatible clients (Cline, Windsurf, etc.), refer to their documentation for MCP server configuration. The server supports standard MCP protocols.

🛠️ Available Tools

Tool

Description

Example Usage

zendesk_get_ticket

Retrieve a ticket by ID

"Get ticket #12345"

zendesk_get_ticket_details

Get detailed ticket with comments

"Show me full details for ticket #67890"

zendesk_search

Search tickets with query syntax

"Find all urgent tickets from last week"

zendesk_create_ticket

Create a new ticket

"Create a high priority ticket for login issues"

zendesk_update_ticket

Update ticket properties

"Set ticket #555 to solved status"

zendesk_add_private_note

Add internal agent notes

"Add a private note about investigation progress"

zendesk_add_public_note

Add public customer comments

"Reply to customer with solution steps"

zendesk_get_linked_incidents

Get incident tickets linked to problems

"Show incidents related to this problem ticket"

💬 Usage Examples

Once configured, you can use natural language with your AI assistant:

Ticket Management

"Show me all high priority tickets assigned to me"
"Create a new ticket: Customer can't access dashboard, priority urgent"
"Update ticket #12345 status to pending and add a note about waiting for customer response"

Search & Discovery

"Find all solved tickets from this week tagged with 'billing'"
"Search for open tickets containing 'password reset'"
"Show me tickets created by john@company.com in the last 30 days"

Customer Communication

"Add a public comment to ticket #789: 'We've identified the issue and working on a fix'"
"Add a private note: 'Customer confirmed the workaround is effective'"

Advanced Queries

"Find all problem tickets that have linked incidents"
"Show me escalated tickets that haven't been updated in 2 days"
"Get details for ticket #456 including all comments and history"

🔑 Authentication Setup

1. Generate API Token

  1. Log in to your Zendesk account

  2. Go to Admin Center → Apps and integrations → APIs → Zendesk API

  3. Click Add API token

  4. Add description: "MCP Server Integration"

  5. Click Create and copy the token

  6. Important: Save this token securely - you won't see it again

2. Find Your Subdomain

Your Zendesk URL format: https://YOUR-SUBDOMAIN.zendesk.com Use YOUR-SUBDOMAIN as the ZENDESK_SUBDOMAIN value.

3. Required Permissions

Ensure your Zendesk user account has:

  • Agent role (minimum)

  • Ticket access permissions

  • API access enabled

🔧 Development

Project Structure

zd-mcp-server/
├── src/
│   ├── index.ts          # Server entry point
│   └── tools/
│       └── index.ts      # Zendesk tool implementations
├── dist/                 # Compiled JavaScript
├── package.json
├── tsconfig.json
└── README.md

Building from Source

git clone https://github.com/koundinya/zd-mcp-server.git
cd zd-mcp-server
npm install
npm run build

Running Locally

# Start the server
npm start

# Development mode with auto-rebuild
npm run dev

Testing

# Test with MCP Inspector (if available)
npx @modelcontextprotocol/inspector zd-mcp-server

# Or test the built version
npx @modelcontextprotocol/inspector node dist/index.js

🔍 Troubleshooting

Common Issues

❌ "Authentication failed" errors

  • Verify your API token is correct and hasn't expired

  • Ensure your email address matches your Zendesk account

  • Check that your subdomain is spelled correctly (no .zendesk.com suffix)

❌ "Permission denied" errors

  • Verify your Zendesk user has Agent permissions or higher

  • Ensure API access is enabled for your account

  • Check if your token has the required scopes

❌ "Server not found" errors

  • Ensure you've installed the package: npm install -g zd-mcp-server

  • Try using npx instead: npx zd-mcp-server

  • Check that your MCP client configuration file syntax is correct

❌ "Environment variables not set" errors

  • Verify all three environment variables are set: ZENDESK_EMAIL, ZENDESK_TOKEN, ZENDESK_SUBDOMAIN

  • Restart your MCP client after setting environment variables

  • Check for typos in environment variable names

Debug Mode

Enable debug logging:

DEBUG=zd-mcp-server:* zd-mcp-server

Log Files

Check MCP client logs:

  • Claude Desktop: ~/Library/Logs/Claude/ (macOS) or %APPDATA%/Claude/logs/ (Windows)

  • Cursor: Check the output panel for MCP server logs

  • Terminal: Run server directly to see real-time logs

📚 Advanced Usage

Search Query Syntax

Zendesk search supports powerful query operators:

# Status-based searches
status:open status:pending status:solved

# Priority searches  
priority:urgent priority:high priority:normal priority:low

# Date-based searches
created>2024-01-01 updated<2024-01-31

# Tag searches
tags:billing tags:technical-issue

# Requester searches
requester:customer@company.com

# Complex combinations
status:open priority:high created>2024-01-01 tags:billing

Batch Operations

While the server doesn't directly support batch operations, you can chain commands:

"Search for all urgent tickets, then show me details for the first 3 results"
"Find tickets tagged 'billing', update them to normal priority, and add a note about the billing system maintenance"

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Development Setup

  1. Fork the repository

  2. Create your feature branch (git checkout -b feature/amazing-feature)

  3. Commit your changes (git commit -m 'Add amazing feature')

  4. Push to the branch (git push origin feature/amazing-feature)

  5. Open a Pull Request

Reporting Issues

Found a bug? Please open an issue with:

  • Description of the problem

  • Steps to reproduce

  • Expected behavior

  • Your environment (OS, Node.js version, MCP client)

  • Relevant log outputs

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

🔗 Links

🆘 Support

Made with ❤️ for the MCP and Zendesk communities

Available Tools

7 tools
zendesk_add_private_noteC

Add a private internal note to a Zendesk ticket

ParametersJSON Schema
NameRequiredDescriptionDefault
noteYesThe content of the private note
ticket_idYesThe 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
NameRequiredDescriptionDefault
commentYesThe content of the public comment
ticket_idYesThe 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
NameRequiredDescriptionDefault
descriptionYesThe initial description or comment for the ticket
priorityNoThe priority of the ticket
statusNoThe status of the ticket
subjectYesThe subject of the ticket
tagsNoTags to add to the ticket
typeNoThe 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
NameRequiredDescriptionDefault
ticket_idYesThe 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
NameRequiredDescriptionDefault
ticket_idYesThe 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_update_ticketB

Update a Zendesk ticket's properties

ParametersJSON Schema
NameRequiredDescriptionDefault
assignee_idNoThe ID of the agent to assign the ticket to
priorityNoThe new priority of the ticket
statusNoThe new status of the ticket
subjectNoThe new subject of the ticket
tagsNoTags to set on the ticket (replaces existing tags)
ticket_idYesThe ID of the ticket to update
typeNoThe 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.

  1. 7 tool updatesv1.0.0
    • 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 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

Related MCP Connectors

Related MCP Servers

  • zendesk-mcp-server

    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.
    7
    119
    Apache 2.0

  • 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.
    49
    6 npm
    -

  • mcp-server-zendesk

    KalchevS
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI assistants to search tickets, manage tags, create tickets, inspect automations, and more in Zendesk.
    MIT

Appeared in Searches