This server provides a set of AI-powered tools for Zendesk support workflows:
search_similar_tickets: Find past tickets similar to an issue via semantic and keyword search; accepts issue and optional topK (default 5, max 20).
get_customer_context: Retrieve a customer's organization and full ticket history by requesterEmail or organization name.
assess_solutions_by_version: Search past solutions/workarounds for an issue and check applicability to a given customerVersion, with optional topK limit.
summarize_daily_work: Summarize a day's Zendesk activity (tickets touched, solved, open, high-priority follow-ups) for a date (defaults to today) and optional assignee.
sync_rag_store: Incrementally update the local RAG vector store with recently updated Zendesk tickets (no parameters).
Provides tools for Zendesk support workflows, including searching similar tickets, retrieving customer context (organization and ticket history), assessing solutions by version, and summarizing daily work activity.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@zendesk-mcp Search similar tickets for 'email not sending'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A custom MCP (Model Context Protocol) server for Zendesk support workflows, built with Node + TypeScript
and the official @modelcontextprotocol/sdk.
Exposes five tools that Claude (or any MCP client) can call:
Tool | Purpose |
| Semantic search (via an external vector index) + live Zendesk keyword search for similar past issues |
| Pull a customer's org + full ticket history before responding |
| Find past fixes for an issue and check if they apply to the customer's version |
| Roll up a day's Zendesk activity: tickets touched, by status, high-priority follow-ups |
| Incrementally pull Zendesk tickets updated since the last run and upsert them into the local RAG vector store |
Related MCP server: Zendesk MCP Server
Each tool's parameters are defined by its inputSchema in src/tools/*.ts — that file is the source of truth if this
table drifts. Params are passed as a JSON object matching the schema below.
Tool | Parameter | Type | Required | Default | Notes |
|
| string | yes | — | Description of the issue/symptom to search for |
| integer (1-20) | no |
| Max number of similar past tickets to return | |
|
| string (email) | one of | — | Single customer/requester email address |
| string | one of | — | Customer organization name, e.g. | |
|
| string | yes | — | Issue description to search past solutions for |
| string | yes | — | Customer's current product version, e.g. | |
| integer (1-20) | no |
| Max number of past-solution matches to consider | |
|
| string ( | no | today | Day to summarize |
| string (email) | no |
| Scopes results to this assignee; defaults to you | |
| — | (no parameters) | — | — | Safe to run any time; only processes tickets updated since the last sync |
Describe what you want in plain language — Claude fills in the parameters:
Run summarize_daily_work for 2026-07-20
Search similar tickets for "PDF export hangs on large files", top 10
Get customer context for jane@example.com
Get customer context for the organization AnthologyThis is the tools/call request the client actually sends (see test-client.mjs for a working example):
{
"method": "tools/call",
"params": {
"name": "summarize_daily_work",
"arguments": {
"date": "2026-07-20",
"assignee": "sophia.banda@nutrient.io"
}
}
}Omit any optional argument to fall back to its default (e.g. omit date for "today", omit assignee to scope to
ZENDESK_EMAIL).
The server is just a Node process speaking MCP over stdio — any MCP client can talk to it, including a terminal
script. Use run.mjs (loads your real .env, unlike test-client.mjs which uses fake credentials for smoke
testing):
node run.mjs <tool_name> '<json_args>'
# examples
node run.mjs get_customer_context '{"organization":"Anthology"}'
node run.mjs get_customer_context '{"requesterEmail":"jane@example.com"}'
node run.mjs summarize_daily_work '{"date":"2026-07-20"}'
node run.mjs search_similar_tickets '{"issue":"PDF export hangs on large files","topK":10}'
node run.mjs sync_rag_store '{}'Run npm run build first if you've made source changes — this calls the compiled server in build/, not the
TypeScript source directly.
The lancedb vector DB provider (see Setup below) is a local, file-based store extracted from a one-time export.
To keep it current without re-pulling that full export, run the incremental sync whenever you want — it only
processes Zendesk tickets updated since the last run (tracked in data/rag-store/.sync-state.json):
npm run sync-rag
# or, equivalently, via the MCP tool:
node run.mjs sync_rag_store '{}'src/
clients/
zendesk.ts – thin wrapper over the Zendesk REST API (search, tickets, users, orgs)
vectorDb.ts – adapter interface (VectorDb) + a mock implementation + a generic HTTP
implementation + a lancedb implementation, so the real backend can be
swapped in via .env only
embedder.ts – shared embedding model (Xenova/all-MiniLM-L6-v2) used by both the
lancedb query path and the ingestion pipeline, so vectors stay comparable
ingest/
syncRagStore.ts – incremental sync: fetch changed tickets, embed, upsert into LanceDB
cli.ts – thin CLI wrapper around syncRagStore.ts (`npm run sync-rag`)
tools/
searchSimilarTickets.ts
customerInfo.ts
assessSolutions.ts
dailySummary.ts
syncRagStoreTool.ts
index.ts – wires everything together and starts the server over stdio
test-client.mjs – a tiny MCP client used to sanity-check the server without wiring it into ClaudeThe exact shape of the backing RAG index isn't fixed yet. Rather than hard-coding a client, vectorDb.ts defines
a one-method interface:
interface VectorDb {
search(query: string, topK?: number): Promise<VectorMatch[]>;
}Everything else in the codebase (the tools) only depends on that interface, not on a specific backend.
VECTOR_DB_PROVIDER=mock in .env gives a fake in-memory index for building and testing end-to-end. Once the
real index's API is known:
use the built-in HttpVectorDb if there's a query endpoint in front of it (adjust the request/response shape
in vectorDb.ts to match the actual API), or
add a new class (e.g. PineconeVectorDb, QdrantVectorDb) implementing the same interface, and add a case
for it in vectorDbFromEnv().
No changes needed anywhere else.
npm install
cp .env.example .env # fill in your Zendesk subdomain/email/API token
npm run build.env fields:
ZENDESK_SUBDOMAIN / ZENDESK_EMAIL / ZENDESK_API_TOKEN — from Zendesk Admin Center > Apps and integrations > APIs > Zendesk API. Generate a token there and enable token access.
VECTOR_DB_PROVIDER — mock to start; lancedb once you have the real store extracted locally (see below); switch
to something else once you have other real connection info.
VECTOR_DB_PATH — only used by the lancedb provider. Path to the extracted LanceDB store, e.g.
./data/rag-store/store. The store itself is a one-time export from a coworker (an AES-encrypted zip — get the
password from them directly, never paste it into chat) extracted into data/rag-store/ (gitignored). Once
extracted, keep it current with npm run sync-rag — see "Syncing the RAG store" above.
node test-client.mjsThis spawns the built server, lists its tools, and calls assess_solutions_by_version against the mock vector
data — useful for iterating without wiring the server into an actual MCP client.
Add it to your MCP client config (e.g. Claude Desktop's claude_desktop_config.json, or Claude Code's
.mcp.json):
{
"mcpServers": {
"zendesk-mcp": {
"command": "node",
"args": ["/absolute/path/to/zendesk-mcp/build/index.js"],
"env": {
"ZENDESK_SUBDOMAIN": "your-company",
"ZENDESK_EMAIL": "you@company.com",
"ZENDESK_API_TOKEN": "...",
"VECTOR_DB_PROVIDER": "mock"
}
}
}
}(Internal notes — may be stale, keep or prune as they're resolved.)
The real vector index's query interface isn't confirmed yet (REST endpoint? Python service? direct DB
connection to Pinecone/Qdrant/pgvector/etc). That determines whether HttpVectorDb works as-is, needs
tweaking, or a new adapter class is needed.
Once wired to the real index, revisit the metadata shape assess_solutions_by_version expects
(fixedInVersion, product, tags) — align it with whatever fields the index actually stores per chunk.
Consider adding a list_products or list_versions tool if there's a canonical version list to validate
customerVersion against.
Add tests (e.g. with node --test) for compareVersions in assessSolutions.ts — it's a naive semver
comparator and worth hardening for versions like 8.4.2-rc1.
Search past solutions/workarounds for an issue and check whether each fix applies to a given product version. Use this to figure out if a known fix should already cover the customer's version, or if they need to upgrade.
| Name | Required | Description | Default |
|---|---|---|---|
| topK | No | ||
| issue | Yes | Issue description to search past solutions for | |
| customerVersion | Yes | The product version the customer is currently running, e.g. '8.2.0' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read-only search, but does not disclose specific behaviors (e.g., what happens if no solutions found, or performance characteristics). Adequate but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence explains the action, the second explains the use case. Highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, yet the description does not explain what the tool returns (e.g., list of solutions with applicability flags). The description covers purpose and usage but lacks output details and edge-case behavior, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, meaning two of three parameters have descriptions. The tool description does not add extra meaning beyond the schema; for example, topK has no description in the schema and is not elaborated in the description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (search/check) and resource (past solutions/workarounds, product version). It distinguishes from siblings like search_similar_tickets by focusing on version applicability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'figure out if a known fix should already cover the customer's version, or if they need to upgrade.' No exclusions or alternatives are mentioned, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull together everything known about a customer: their org, past tickets, and prior reported issues. Look up by requester email for a single contact, or by organization name for the whole account. Use this before responding to a ticket to understand history and avoid repeating past answers.
| Name | Required | Description | Default |
|---|---|---|---|
| organization | No | Customer organization name to search by, e.g. 'Anthology'. Use instead of requesterEmail to pull the whole account's tickets. | |
| requesterEmail | No | Email address of the customer/requester |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the tool gathers org, tickets, and issues—a read-only operation. Without annotations, description carries burden; no side effects or limitations (e.g., data freshness, rate limits) are mentioned, but basic behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. First sentence states purpose, second gives usage guidance. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains output: org, past tickets, prior issues. Could specify format or additional details, but sufficient for understanding the tool's value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with basic descriptions. The description adds value by differentiating the two parameters: organization for whole account, requesterEmail for single contact, and gives an example ('Anthology').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pulls together customer information including org, tickets, and issues. It distinguishes from sibling tools like search_similar_tickets by focusing on customer context rather than similarity search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this before responding to a ticket to understand history. Explains when to use each parameter (email vs. organization). Does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find past Zendesk tickets similar to a described issue, using semantic search over ticket history plus a live Zendesk keyword search. Use this before triaging a new ticket to check for precedent.
| Name | Required | Description | Default |
|---|---|---|---|
| topK | No | Max number of similar past tickets to return | |
| issue | Yes | Description of the issue or symptom to search for, e.g. 'PDF export hangs on large files' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states the tool uses semantic search over ticket history plus keyword search, implying a read-only operation. However, it lacks details on rate limits, ordering of results, or what 'similar' means. The description is adequate but could be more informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is only two sentences: the first explains the tool's action and method, the second gives usage guidance. There is no unnecessary information, and every sentence serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters fully described in the schema, no output schema, and no annotations. The description explains the purpose and usage, but lacks details on the output format (e.g., what fields are returned, how similarity is scored) and more behavioral context. While functional, it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds an example for the `issue` parameter ('PDF export hangs on large files') but does not provide additional semantics beyond what the schema already offers. Both parameters are well-documented in the schema, so the description does not need to add much.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool finds past Zendesk tickets similar to a described issue using semantic search and keyword search. The verb 'find' is specific, the resource is clearly identified as past Zendesk tickets, and the description distinguishes it from sibling tools that focus on customer context, solution assessment, or daily work summarization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says to use this tool 'before triaging a new ticket to check for precedent,' providing a clear usage context. While it does not mention when not to use it or alternative tools, the provided context is sufficient for an AI agent to understand when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize Zendesk activity for a given day (default: today) — tickets touched, solved, still open, and any high-priority items needing follow-up. Ask for this at end of day or during standup prep.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ISO date (YYYY-MM-DD) to summarize; defaults to today | |
| assignee | No | Assignee email to scope the summary to; defaults to ZENDESK_EMAIL (you) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes what the summary includes (tickets touched, solved, open, high-priority) and notes assignee defaults. Omits output format, but is acceptable for a read-only summary tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second gives usage context. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description covers purpose, key content, and usage context. Could mention output type, but overall complete for a simple summary tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already includes default descriptions. The tool description adds no additional meaning beyond what is in the schema, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (summarize) and resource (Zendesk activity for a day). Distinct from sibling tools like search_similar_tickets which are different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends when to use ('end of day or during standup prep'). No explicit exclusions or alternatives, but context is clear given distinct sibling purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0assess_solutions_by_versionget_customer_contextsearch_similar_ticketssummarize_daily_workEach tool has a clearly distinct purpose: finding similar tickets, gathering customer context, assessing solutions by version, and summarizing daily work. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., search_similar_tickets, get_customer_context), making them predictable and easy to navigate.
Four tools are appropriate for a focused support assistant server. Each tool addresses a specific need without superfluous or missing functionalities.
The tool set covers information retrieval and analysis but lacks core actions like creating, updating, or commenting on tickets, which are essential for full ticket lifecycle management. This creates dead ends for agents needing to take action.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Team knowledge base for snippets, API calls and docs. Agents search and file items; humans review.
Search your customer interviews, calls, feedback, competitor intel and roadmap from any AI agent.
Enterprise memory, search, and context for frontier AI. 38 tools for business intelligence.
Versioned documentation registry and semantic search for AI tools and coding assistants.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sophiabanda/zendesk-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
