Nevent MCP

Nevent MCP

Talk to your live-events CRM (campaigns, analytics, paid ads, segments, short URLs) in Claude and ChatGPT.

Official MCP server for Nevent — the marketing platform for live event promoters. 63 tools across 10 groups (analytics, segmentation, campaigns, templates, deliverability, paid media, short URLs, media library, multi-tenant, and help/discovery) over OAuth 2.1 (hosted) or stdio (local).

📚 Full documentation: [https://help.nevent.ai/en/nevent-ai/](https://help.nevent.ai/en/nevent-ai/)

---

Install

Hosted (recommended — no install needed)

Add https://mcp.nevent.ai/ as a remote MCP server in your client. Works with Claude.ai, ChatGPT, Cursor, Cline, Continue and any compatible MCP client.

→ Step-by-step with screenshots: Connect with Claude · Connect with ChatGPT

Local (stdio via npm)

npx mcp-nevent

Required env: NEVENT_JWT_TOKEN. Optional: NEVENT_OPERATION_MODE (READ_ONLY | STANDARD | FULL).

→ Full local setup: Local installation

---

Quick add

Claude.ai · ChatGPT (hosted, no setup)

Settings → Integrations / Connectors → Add custom MCP → URL https://mcp.nevent.ai/. Authorize with your Nevent admin account.

Claude Code

# Hosted (OAuth)

claude mcp add --transport http nevent https://mcp.nevent.ai/

Or local (stdio)

claude mcp add nevent -- node /path/to/mcp-nevent/dist/index.js export NEVENT_JWT_TOKEN=your_token

→ Full guide: Claude Code

Claude Desktop

Add to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\):

{

"mcpServers": { "nevent": { "command": "node", "args": ["/path/to/mcp-nevent/dist/index.js"], "env": { "NEVENT_JWT_TOKEN": "your_nevent_jwt_token" } } } }

→ Full guide: Claude Desktop

Cursor · Cline · Continue · VS Code

→ Per-client setup: Cursor, Cline, Continue, VS Code

---

What you can ask

"Show me registrations for EventX broken down by ticket type"

"Which campaigns sent last month had an open rate above 30%?"

"Create a segment of attendees who bought a VIP ticket in 2025 but haven't opened any email in the last 90 days"

"Schedule the 'Summer Gala' campaign for next Monday at 10:00 CET"

"Compare ROAS across our Meta ad campaigns for March"

"Create per-user tracking links for the Summer Gala campaign and show me which users clicked"

→ More patterns: Ready-to-use prompts · Use cases

---

Documentation

For developers

---

How it works

LLM (Claude / ChatGPT / Cursor / …)

| | MCP (Streamable HTTP or stdio) v ┌─────────────────┐ │ Nevent MCP │ mcp.nevent.ai (hosted) or local └─────────────────┘ | | REST + JWT v Nevent APIs (analytics, campaigns, segments, paid media, short URLs)

Hosted mode uses OAuth 2.1: the MCP server issues short-lived JWT tokens after validating your Nevent credentials. Each session is isolated — no shared service accounts.

---

Restricting OAuth clients (self-hosted HTTP)

Optional environment variables for the HTTP server:

See CHANGELOG.md for the exact behaviour.

Advanced: bearer-passthrough mode (trusted clients, service key required)

MCP_AUTH_MODE=bearer-passthrough is a second HTTP auth mode for trusted clients that already hold a per-user nev-api JWT and want to call MCP tools on that user's behalf — for example nev-helpbot, the Chatwoot support bot, answering as the promoter currently chatting.

MCP_AUTH_MODE=bearer-passthrough \

MCP_BEARER_PASSTHROUGH_SERVICE_KEY=$(openssl rand -hex 32) \ node dist/index.js --transport=http --port=3000

Every request must carry BOTH the client's service key and the calling user's own nev-api JWT:

X-Nevent-Service-Key: <pre-shared service key>

Authorization: Bearer

• Service key (mandatory). The instance may be reachable from outside, so a JWT alone is not enough. MCP_BEARER_PASSTHROUGH_SERVICE_KEY (at least 32 characters) is required: the server refuses to start without it. It is compared in constant time (crypto.timingSafeEqual over SHA-256 digests) and checked before the token is introspected, so outsiders cannot make this server call nev-api. A missing or wrong key gets a bare 401 (Unauthorized.) with no hint of which check failed. For rotation, set MCP_BEARER_PASSTHROUGH_SERVICE_KEY_PREVIOUS to the old key while the client moves to the new one, then remove it. Keep it in a secret store, never in the repository. Requests are also capped per IP (600/min, applied before body parsing) and per token (300/min). GET /health is unauthenticated for load balancers and returns only {status, version, commitSha}.

• Write policy (off by default). By default every session is READ-only (47 tools). MCP_BEARER_PASSTHROUGH_WRITES=human additionally exposes, to sessions of a person (principalType HUMAN verified in /auth/me), 12 write tools: nevent_create_segment, nevent_update_segment, nevent_create_template, nevent_update_template, nevent_clone_template, nevent_rename_template, nevent_send_test_template, nevent_create_campaign, nevent_schedule_campaign, nevent_create_short_url, nevent_update_short_url, nevent_create_bulk_user_short_urls. SERVICE sessions never get writes. upload_image, delete_image, reset_tenant, switch_tenant and list_tenants are never exposed, and an unclassified tool is denied. The policy is fixed per session at initialize. Writes are not safe to enable yet: the real barrier is the signed single-use write grant (NEV-1855), so the server refuses to start with human until that exists (override for non-production only: MCP_BEARER_PASSTHROUGH_WRITES_UNSAFE_NO_GRANT=true). Each tenant+user is limited to MCP_BEARER_PASSTHROUGH_WRITES_PER_HOUR writes per hour (default 30; over it, a write_rate_limit_exceeded tool error and nothing is executed; READ is never limited). Every tool call is logged with user_id, principal_type and the verified tenant (no email or token). Calls also need NEVENT_OPERATION_MODE=STANDARD for writes and FULL for nevent_schedule_campaign (classified DELETE because it sends for real); startup refuses human with READ_ONLY. The hourly limit is per process (in memory, each instance has its own budget, a restart resets it), counts only calls that actually execute (not invalid arguments, not calls the operation-mode guard rejects; a handler that fails does count) and accepts 1-1000. The no-grant override is rejected when NODE_ENV=production.

• No OAuth flow, no `MCP_JWT_SECRET`, no `MONGODB_URI` required. MONGODB_URI stays optional: set it to also enable the Mongo-backed read tools (campaigns/templates/deliverability), each still scoped by the caller's own JWT tenant.
• Every request is verified against nev-api before anything is exposed. On every request — initialize, tools/list, tools/call, not only at session start — this server calls GET {NEVENT_API_URL}/auth/me with the forwarded token. A 200 confirms the session is live and the request proceeds; 401, 403, a network error, or a timeout are all treated the same way — the MCP request is rejected with 401 and no tool, no `tools/list`, and no session is ever created or advanced from it. There is no permissive fallback: if nev-api cannot be reached to confirm the token, the request is refused, it is never let through anyway.
• A successful check is cached briefly (~60 s) by a hash of the token so a single session does not call /auth/me on every message, but the cache never serves an entry past the token's own expiry.
• The token's signature is still never checked locally by this server. nev-api signs session JWTs with a symmetric secret (HMAC256); shipping that secret here so it could be verified offline would mean compromising this process could forge a session for *any* Nevent user, not just read their data. Introspecting against nev-api avoids that trade-off entirely and is the only mechanism this mode uses to confirm a token is real, live, and unexpired. nev-data-api and nev-api additionally validate the token themselves on every downstream call they receive, exactly as they do for stdio mode's shared NEVENT_JWT_TOKEN.
• Human and service sessions. GET /auth/me also reports principalType (HUMAN or SERVICE), effectiveTenantId and serviceSession. Technical service sessions minted by POST /auth/service-token (unattended agents) are accepted like a human token only with `TENANT` scope (PLATFORM, i.e. global SUPERADMIN, is refused). The session is locked to effectiveTenantId, which comes only from this answer (never from the JWT payload; also correct for hierarchical admins navigating a child tenant). Fail-closed: an unknown principalType, a SERVICE response without effectiveTenantId, or any response with no tenant at all is refused. A SERVICE verification is cached for 10 s instead of 60 s so a disabled account or revoked session stops working almost immediately.
• Verification cache. Positive verdicts are cached (max 1000 entries, LRU, expired ones purged first); a token nev-api explicitly