Connect an AI assistant to Helpdash with MCP

Helpdash exposes a Model Context Protocol (MCP) server, so an AI assistant can work inside your workspace directly instead of you copy-pasting tickets into a chat window. Ask "which tickets breach SLA today?" or "summarise this thread for the handover" and the assistant queries Helpdash itself.

This post covers what the connector exposes, how to connect one, and — the part worth reading twice — what it is not allowed to do.

What the connector exposes

The server ships 46 tools, four ready-made prompts, and one resource listing every enum value the tools accept. The tools cover tickets, live chat, the knowledge base, canned responses, projects and teammates, the dashboard, CSAT, automation rules, webhooks, settings, the activity log and billing.

Reads and writes are always separate tools. There is no catch-all api_request tool with a method parameter — searching tickets and changing one are different tools with different permissions, so an assistant granted read access cannot mutate anything by varying an argument.

The four prompts are workflows worth having pre-written:

• Triage a ticket — recommends a priority, category and assignee. Changes nothing.
• Draft a customer reply — drafts the text using your knowledge base and canned responses. It cannot send; the reply comes back for you to review.
• Summarize a thread — condenses a long ticket or chat transcript for a shift handover.
• Weekly support report — volume, SLA, CSAT and what needs attention.

Connecting a client

Open Settings → AI connectors (MCP) and issue a token. Give it a label you'll recognise later, leave every write switch off for your first one, and copy the key — it is shown exactly once.

Then register it. For Claude Code:

claude mcp add --transport http helpdash https://your-workspace.helpdash.io/mcp \
  --header "Authorization: Bearer hd_mcp_..."

For any client that reads an .mcp.json:

{
  "mcpServers": {
    "helpdash": {
      "type": "http",
      "url": "https://your-workspace.helpdash.io/mcp",
      "headers": { "Authorization": "Bearer hd_mcp_..." }
    }
  }
}

Both snippets are generated for you, filled in with your workspace URL, on the same screen where the token appears.

Clients that prefer browser sign-in can use OAuth 2.1 instead of a static token: the server publishes standard discovery documents, supports PKCE and dynamic client registration, and shows a consent screen listing exactly which scopes are being requested. No token to copy, and no key to store on disk.

What it cannot do

The connector is not a second, looser API. Every call passes the same four gates a human request does.

It acts as you. A token is bound to the operator who issued it. It inherits that person's roles and permissions exactly — if you cannot open a ticket in the app, an assistant holding your token cannot open it either. And it is bound to one workspace: there is no argument that reaches another tenant's data.

Read-only unless you say otherwise. A new token with every switch off can search, read and report, and nothing more. Write access is granted per area — change tickets, reply in live chat, edit the knowledge base, manage projects, invite teammates, change settings, change automation rules — and only the ones you tick. Reading is always included, because an assistant that can write but not read is useless.

Write tools ask first. Every tool that changes data is annotated as destructive, so a well-behaved client prompts you before each call rather than acting silently. The tools that reach a customer say so in their own description: sending a live chat message is delivered instantly and cannot be recalled, and a ticket comment defaults to an internal note so nothing reaches a customer by accident.

Secrets stay server-side. Reading your settings over a connector returns integration credentials masked. There is no argument that unmasks them.

Customer text is fenced. Ticket descriptions, comments and chat transcripts are written by other people, and a support inbox is exactly where someone would try planting instructions for an AI reading it. Helpdash wraps that text in an explicit untrusted-content block and tells the model, in the server's own instructions, that nothing inside it is a command.

Everything is logged. Each call is recorded with the operator, the tool and the outcome, in the same audit log as the rest of the workspace. If you ever need to answer "what did the assistant actually do on Tuesday?", the record is there.

Revocation is immediate. Deleting a token in Settings stops the assistant's very next request. We only ever store a SHA-256 hash of the key, so we cannot recover it for you — lose it and you issue a new one.

Tightening a token further

Two optional controls are worth knowing about. A token can carry an expiry date, which is the easiest way to make a short-lived experiment clean itself up. And it can carry an IP allowlist, so a token meant for one server cannot be used from anywhere else. Both are on the same creation form.

A reasonable first token

Issue one with no write scopes and give the assistant a read-only week. Ask it to find SLA risks, summarise noisy threads, and draft replies you send yourself. That covers most of the value with none of the exposure. When you know which write scope you actually want, issue a second token with just that one — expanding an existing token is deliberately not possible.

Every claim above describes behaviour that ships today; the connector is available on every Helpdash workspace.