mcp-server/.env.example

# Shared bearer token every client must send to reach the server (the "gate").
# Generate: openssl rand -hex 32
MCP_AUTH_TOKEN=replace_with_a_long_random_token

# --- Single-user only -------------------------------------------------------
# Uncomment to bake ONE identity into the server. Every client then acts as
# this Freshservice user. For a shared/multi-user server, LEAVE THESE OUT and
# have each client send its own X-Freshservice-Domain / X-Freshservice-Key
# headers instead (see README → "Multiple users").
# FRESHSERVICE_DOMAIN=pesco
# FRESHSERVICE_API_KEY=your_freshservice_api_key
Support per-user identity via request headers Add multi-user auth: _config reads X-Freshservice-Domain/X-Freshservice-Key from the per-request headers (via the SDK request_ctx, set inside the tool's task) and prefers them over the container env. One shared server can now act as each caller's own Freshservice identity — actions attributed to them, their permissions, their rate limit — while the env vars remain a single-user fallback. Verified end-to-end that concurrent clients don't cross-wire and that a client with no creds errors instead of falling back silently. Docs/.env.example updated with the multi-user client config and the guidance to omit env FS creds on a shared deployment. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> 2026-07-10 08:23:52 -06:00			`# Shared bearer token every client must send to reach the server (the "gate").`
			`# Generate: openssl rand -hex 32`
Add Freshservice MCP server for Cowork deployment Cowork runs the agent in an isolated VM, so the uploaded skill can't see host credentials or reach the Freshservice host. Add an HTTP/streamable MCP server (bearer-auth, Dockerfile, compose) to run as a container on the LAN box and connect via mcp-remote like the existing sharepoint-lists server. The skill remains the right tool for the non-sandboxed Claude Code CLI. Also gitignore mcp-server/.env and include the desktop skill install package. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> 2026-06-16 18:41:02 -06:00			`MCP_AUTH_TOKEN=replace_with_a_long_random_token`
Support per-user identity via request headers Add multi-user auth: _config reads X-Freshservice-Domain/X-Freshservice-Key from the per-request headers (via the SDK request_ctx, set inside the tool's task) and prefers them over the container env. One shared server can now act as each caller's own Freshservice identity — actions attributed to them, their permissions, their rate limit — while the env vars remain a single-user fallback. Verified end-to-end that concurrent clients don't cross-wire and that a client with no creds errors instead of falling back silently. Docs/.env.example updated with the multi-user client config and the guidance to omit env FS creds on a shared deployment. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> 2026-07-10 08:23:52 -06:00
			`# --- Single-user only -------------------------------------------------------`
			`# Uncomment to bake ONE identity into the server. Every client then acts as`
			`# this Freshservice user. For a shared/multi-user server, LEAVE THESE OUT and`
			`# have each client send its own X-Freshservice-Domain / X-Freshservice-Key`
			`# headers instead (see README → "Multiple users").`
			`# FRESHSERVICE_DOMAIN=pesco`
			`# FRESHSERVICE_API_KEY=your_freshservice_api_key`