@fruggr/zendesk-mcp-server 2.23.0 → 3.0.0

package/README.md

@@ -83,7 +83,7 @@ differently.
 - Two deployment shapes, same auth story. Run it on your laptop as a stdio MCP
   server, or deploy it as a private remote MCP server reached over HTTP, with one
   Zendesk session per request and each client carrying its own user's token.
-- A lean stack: the official `@modelcontextprotocol/sdk` plus `zod`, speaking to
+- A lean stack: the official MCP TypeScript SDK (`@modelcontextprotocol/server`) plus `zod`, speaking to
   the Zendesk Support and Help Center (Guide) APIs.
 
 Look elsewhere when:
@@ -117,7 +117,7 @@ it. A few are listed under
 ## Quick start: local (stdio)
 
 The default shape: one developer, one Zendesk account, OAuth 2.1 PKCE in the
-browser. You need **Node.js >= 20** and a **Zendesk** instance (Support or
+browser. You need **Node.js >= 22** and a **Zendesk** instance (Support or
 Suite).
 
 ### Install
@@ -139,7 +139,7 @@ Signing in needs a Zendesk OAuth client, so register one first (next section).
 2. Create a **public** client:
    - **Identifier**: `<your-subdomain>_zendesk` (or set `ZENDESK_OAUTH_CLIENT_ID`)
    - **Redirect URL**: `http://localhost:27439/callback` (change the port to match
-     `ZENDESK_OAUTH_CALLBACK_PORT` / `--callback-port` if you override it; Zendesk
+     `OAUTH_CALLBACK_PORT` / `--callback-port` if you override it; Zendesk
      accepts several redirect URLs, one per line)
 
 If the client restricts its **allowed scopes**, it needs `read` — plus `write`
@@ -151,7 +151,7 @@ window and returns the authorize URL in a tool message. The call does not block
 waiting for sign-in, so authenticate in the browser and then retry the request.
 The token is persisted to an owner-only file and reused across restarts, so you
 don't authenticate again every time your MCP client respawns the server (path
-and overrides: [`ZENDESK_TOKEN_FILE`](docs/configuration.md#zendesk_token_file)).
+and overrides: [`OAUTH_TOKEN_FILE`](docs/configuration.md#oauth_token_file)).
 Several instances can run side by side — a read-write one and a `--read-only`
 one, say — without trading credentials.
 
@@ -210,12 +210,15 @@ Something not working? See [Troubleshooting](docs/troubleshooting.md).
 > end-to-end against a real Zendesk tenant from every MCP client. Local stdio is
 > the supported path.
 
-You can also deploy a private remote MCP server for **one** Zendesk account,
-where every MCP client presents its **own** user's OAuth bearer in
-`Authorization:` and the server never sees a shared admin key. The full guide
-covers OAuth setup, `--public-url` behind a reverse proxy, per-platform config,
-the discovery endpoints, MCP client wiring, CORS and what stays the operator's
-job: **[docs/http-deployment.md](docs/http-deployment.md)**.
+You can also deploy a private remote MCP server for **one** Zendesk account.
+It is its own OAuth authorization server: web clients such as claude.ai and
+ChatGPT add it by URL and register themselves, each user signs in to Zendesk
+through it, and no shared admin key or per-client Zendesk setup is involved. Its
+packages install on top of the server, so stdio users never download them. The
+full guide covers that install, the one redirect URL to add to your Zendesk OAuth client, the
+master secret and grant store, `--public-url` behind a reverse proxy, trusted
+clients, MCP client wiring, CORS and what stays the operator's job:
+**[docs/http-deployment.md](docs/http-deployment.md)**.
 
 ## Tool surface
 
@@ -326,7 +329,7 @@ to turn each piece off: **[docs/help-center-context.md](docs/help-center-context
 
 The complete reference for the CLI flags (`--mode`, `--namespace`,
 `--read-only`, `--transport`, `--public-url`, and so on) and the environment
-variables (`ZENDESK_SUBDOMAIN`, `ZENDESK_TOKEN_FILE`, `PUBLIC_URL`, the
+variables (`ZENDESK_SUBDOMAIN`, `OAUTH_TOKEN_FILE`, `PUBLIC_URL`, the
 attachment-vision caps) lives in
 **[docs/configuration.md](docs/configuration.md)**. Every variable has its own
 anchor, so you can deep-link a specific setting.