@fruggr/zendesk-mcp-server 2.20.2 → 2.22.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +99 -7
- package/dist/index.js +806 -92
- package/package.json +4 -4
package/README.md
CHANGED
|
@@ -7,10 +7,19 @@
|
|
|
7
7
|
[](https://nodejs.org)
|
|
8
8
|
|
|
9
9
|
A [Model Context Protocol](https://modelcontextprotocol.io) (MCP) server that
|
|
10
|
-
puts Zendesk inside your AI assistant
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
10
|
+
puts Zendesk inside your AI assistant, for **both sides of the conversation**.
|
|
11
|
+
|
|
12
|
+
**For agents**: it finds answers in the Help Center; drafts, updates and
|
|
13
|
+
translates articles while keeping the languages in sync; and handles Support
|
|
14
|
+
tickets end to end, comments, triage and image attachments included.
|
|
15
|
+
|
|
16
|
+
**For your customers**: it opens the same door the Help Center's "Submit a
|
|
17
|
+
request" form does. They pick the kind of request, get walked through the
|
|
18
|
+
questions that form actually asks, attach a screenshot, then follow the
|
|
19
|
+
ticket — read the replies, answer back, close it when it's resolved. See
|
|
20
|
+
[End-user mode](#end-user-mode).
|
|
21
|
+
|
|
22
|
+
It all happens in plain language, without switching apps.
|
|
14
23
|
|
|
15
24
|
It does roughly what the
|
|
16
25
|
[Zendesk agent for Microsoft 365 Copilot](https://support.zendesk.com/hc/en-us/articles/9958331458458-Using-the-Zendesk-agent-in-Microsoft-365-Copilot)
|
|
@@ -39,6 +48,9 @@ then calls the right tools on your behalf.
|
|
|
39
48
|
- Draft and maintain knowledge-base articles. You can write a new one, or revise
|
|
40
49
|
a large one a single section at a time, so the whole HTML body never has to
|
|
41
50
|
round-trip through the model.
|
|
51
|
+
- Submit and follow a request as a customer, not an agent. Choose between the
|
|
52
|
+
kinds of request the vendor offers, answer only the questions that form asks,
|
|
53
|
+
and then track it: what was replied, what you replied, and whether it's done.
|
|
42
54
|
|
|
43
55
|
## Why this server
|
|
44
56
|
|
|
@@ -51,6 +63,10 @@ differently.
|
|
|
51
63
|
touches exactly what that person is allowed to, the same scoping you get by
|
|
52
64
|
signing into Zendesk directly. Static API tokens are deliberately not
|
|
53
65
|
supported ([why](#what-this-server-does-not-do)).
|
|
66
|
+
- Two audiences, one server. Because auth is per-user rather than a shared admin
|
|
67
|
+
key, the same install serves your agents and your customers — the end-user
|
|
68
|
+
surface is a namespace you switch on, speaking the API path Zendesk reserves
|
|
69
|
+
for requesters. Most Zendesk MCP servers are agent-only by construction.
|
|
54
70
|
- Section-based article editing. For large Help Center articles, read and
|
|
55
71
|
rewrite one section at a time (parsed by `h1`/`h2`/`h3` headings) instead of
|
|
56
72
|
shuffling the full HTML body through the assistant. On a targeted edit that
|
|
@@ -126,6 +142,10 @@ Signing in needs a Zendesk OAuth client, so register one first (next section).
|
|
|
126
142
|
`ZENDESK_OAUTH_CALLBACK_PORT` / `--callback-port` if you override it; Zendesk
|
|
127
143
|
accepts several redirect URLs, one per line)
|
|
128
144
|
|
|
145
|
+
If the client restricts its **allowed scopes**, it needs `read` — plus `write`
|
|
146
|
+
unless the server runs with [`--read-only`](docs/configuration.md), which asks
|
|
147
|
+
Zendesk for the `read` scope alone.
|
|
148
|
+
|
|
129
149
|
On the first tool call the server starts the sign-in flow: it opens a browser
|
|
130
150
|
window and returns the authorize URL in a tool message. The call does not block
|
|
131
151
|
waiting for sign-in, so authenticate in the browser and then retry the request.
|
|
@@ -197,9 +217,10 @@ job: **[docs/http-deployment.md](docs/http-deployment.md)**.
|
|
|
197
217
|
|
|
198
218
|
## Tool surface
|
|
199
219
|
|
|
200
|
-
Tools are grouped into
|
|
201
|
-
Organizations** and **
|
|
202
|
-
|
|
220
|
+
Tools are grouped into namespaces: **Tickets**, **Help Center**, **Users &
|
|
221
|
+
Organizations**, **Search**, and **Requests** — the end-user surface, which is
|
|
222
|
+
opt-in and covered under [End-user mode](#end-user-mode). The server registers
|
|
223
|
+
them in one of three modes, so you can trade granularity against context budget:
|
|
203
224
|
|
|
204
225
|
- **`all`**: every operation as its own tool, for clients with good tool selection;
|
|
205
226
|
- **`namespace`** (default): one proxy tool per namespace, a balanced middle ground;
|
|
@@ -210,10 +231,81 @@ Proxies take `{ "operation": "<tool_name>", "params": { … } }` and validate
|
|
|
210
231
|
filter tools *before* the proxies are built, so each proxy describes only the
|
|
211
232
|
operations that survive.
|
|
212
233
|
|
|
234
|
+
There's one way to pick the inventory (`--namespace` / `--tool`), `--mode`
|
|
235
|
+
packages it, and `--read-only` narrows it. When the combination isn't obvious,
|
|
236
|
+
don't guess — `--print-tools` has the server answer what it would expose, with
|
|
237
|
+
no credentials needed.
|
|
238
|
+
|
|
213
239
|
Every tool with its description and its `read`/`write` mode:
|
|
214
240
|
**[docs/mcp-tools-reference.md](docs/mcp-tools-reference.md)**. The flags and
|
|
215
241
|
worked examples: **[docs/configuration.md](docs/configuration.md)**.
|
|
216
242
|
|
|
243
|
+
## End-user mode
|
|
244
|
+
|
|
245
|
+
The audience for everything above is a Zendesk **agent**. This section is about
|
|
246
|
+
the other one: your **customers**.
|
|
247
|
+
|
|
248
|
+
On the web, a customer opens a ticket through the Help Center's "Submit a
|
|
249
|
+
request" form — they pick a kind of request, fill in the fields that kind asks
|
|
250
|
+
for, attach a file, and later come back to read the replies. End-user mode is
|
|
251
|
+
that same journey, in their assistant.
|
|
252
|
+
|
|
253
|
+
### Who it's for
|
|
254
|
+
|
|
255
|
+
A vendor pointing their customers at an MCP server, so support happens where
|
|
256
|
+
those customers already work. They install it themselves, sign in with their
|
|
257
|
+
own Help Center account, and never see anything that isn't theirs.
|
|
258
|
+
|
|
259
|
+
### Turning it on
|
|
260
|
+
|
|
261
|
+
The end-user tools live in the `requests` namespace, and it is **opt-in**: an
|
|
262
|
+
agent install shouldn't inherit tools built for someone else, and one of them
|
|
263
|
+
(marking a request solved) doesn't work under an agent token at all — Zendesk
|
|
264
|
+
accepts it and silently does nothing. `help_center` is worth serving alongside
|
|
265
|
+
it, since a customer who can search the knowledge base often doesn't need to
|
|
266
|
+
open a ticket in the first place.
|
|
267
|
+
|
|
268
|
+
The flags, and how to have the server print what a combination exposes:
|
|
269
|
+
**[docs/configuration.md](docs/configuration.md)**.
|
|
270
|
+
|
|
271
|
+
### The journey it supports
|
|
272
|
+
|
|
273
|
+
- **See what kinds of request are available.** The forms the vendor offers, by
|
|
274
|
+
their customer-facing names.
|
|
275
|
+
- **Learn what one of them asks.** The questions on that form, which are
|
|
276
|
+
required, and for dropdowns the exact choices — so the assistant can gather
|
|
277
|
+
them in conversation instead of guessing at a payload.
|
|
278
|
+
- **Submit it**, with attachments.
|
|
279
|
+
- **Follow it.** List their requests, read one with its whole conversation
|
|
280
|
+
(each reply attributed, and support agents marked as such), reply back, and
|
|
281
|
+
mark it solved when it is.
|
|
282
|
+
|
|
283
|
+
### What it asks of the Zendesk account
|
|
284
|
+
|
|
285
|
+
Nothing the agent side doesn't already need, plus one thing: at least one
|
|
286
|
+
ticket form marked visible to end users, because that is what a customer picks
|
|
287
|
+
between. Sign-in is interactive, through a browser, by design — there is no
|
|
288
|
+
scripted or headless path to an end-user token, which is the same protection
|
|
289
|
+
that stops anyone else signing in as your customer.
|
|
290
|
+
|
|
291
|
+
The prerequisites in full: **[docs/configuration.md](docs/configuration.md)**.
|
|
292
|
+
The step-by-step walkthrough, written for someone who doesn't work in a
|
|
293
|
+
terminal: **[docs/end-user-onboarding.md](docs/end-user-onboarding.md)**.
|
|
294
|
+
|
|
295
|
+
### What a customer can't do — and shouldn't
|
|
296
|
+
|
|
297
|
+
A customer can do less than an agent. That's the point, not a gap:
|
|
298
|
+
|
|
299
|
+
- **Only their own tickets.** Enforced by Zendesk, not by us.
|
|
300
|
+
- **No internal notes**, in either direction. Agent-only notes never appear in
|
|
301
|
+
what this surface returns — Zendesk filters them out of the requester's view
|
|
302
|
+
of a ticket entirely.
|
|
303
|
+
- **No priority or type.** Zendesk drops both when a customer sets them;
|
|
304
|
+
triage stays with the agents.
|
|
305
|
+
- **Closing a ticket only once an agent has picked it up.** Until then Zendesk
|
|
306
|
+
won't let the requester solve it, so the tool says so rather than pretending.
|
|
307
|
+
- **No search across the ticket base**, no user lookups, no views, no macros.
|
|
308
|
+
|
|
217
309
|
## Help Center context
|
|
218
310
|
|
|
219
311
|
Beyond tools, the server hands the LLM the structure of *your* Help Center: the
|