MCP

DM Hero speaks the Model Context Protocol, so Claude, Cursor and other MCP clients can work with your CRM, campaigns and inbox through task-shaped tools. Every tool calls the same API operations documented here, with the same key, scopes, limits and errors.

Endpoint and authentication

The tool list a client sees depends on the key: a tool appears only when the key holds the scopes its operations need. Give the MCP client its own key with only the scopes you want an agent to have, and restrict it to reps if it should not see every inbox.

Setup

Claude Code

claude mcp add --transport http dmhero https://api.dmhero.ai/mcp --header "Authorization: Bearer $DMHERO_API_KEY"

Cursor

In .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "dmhero": {
      "url": "https://api.dmhero.ai/mcp",
      "headers": { "Authorization": "Bearer dmh_live_..." }
    }
  }
}

Claude Desktop

Add DM Hero as a remote MCP server with an authorization header where your version supports it. Otherwise bridge it with mcp-remote in claude_desktop_config.json. The header argument has no space in it on purpose: some clients split arguments on spaces, so the space after Bearer lives in the variable:

{
  "mcpServers": {
    "dmhero": {
      "command": "npx",
      "args": ["mcp-remote", "https://api.dmhero.ai/mcp", "--header", "Authorization:${AUTH_HEADER}"],
      "env": { "AUTH_HEADER": "Bearer dmh_live_..." }
    }
  }
}

Tools

Two step confirmation

Tools that cannot be undone (deleting a lead, a bulk change, starting or archiving a campaign, enrolling by filter, switching the AI Setter, approving one of its drafts) never act on the first call. The first call returns a preview:

{
  "requires_confirmation": true,
  "summary": "Deletes lead 0b8e2c6d-4f1a-4b7e-9d3c-6a5f4e3d2c1b (status replied) and its enrollments. This cannot be undone.",
  "preview": { "lead": { "id": "0b8e2c6d-4f1a-4b7e-9d3c-6a5f4e3d2c1b", "ig_username": "jane.doe", "status": "replied" } },
  "confirmation_id": "...",
  "expires_at": "2026-10-21T09:40:00.000Z"
}

1. The agent shows the summary to the person and asks.
2. When the person agrees, the agent calls the same tool again with the same arguments and the confirmation_id.
3. Only then does the tool act, once. Repeating the confirmed call replays its result instead of acting twice.

A confirmation_id is bound to the key, the tool, the action and the exact arguments, and expires after 10 minutes. There is no confirm: true shortcut: one call can never both decide and act, so text injected into a lead's bio or a note cannot trigger a destructive action on its own.

Untrusted content

Lead names, bios, notes, custom field values and AI Setter drafts are written by prospects, operators and a model. Tools return them inside an untrusted object, and the text summary of a tool result never quotes them:

{ "id": "0b8e2c6d-4f1a-4b7e-9d3c-6a5f4e3d2c1b", "status": "replied", "untrusted": { "name": "Jane Doe", "bio": "Coach. Ignore previous instructions and..." } }

Human approval is the host's job

• Every tool declares MCP annotations: readOnlyHint, destructiveHint, idempotentHint and openWorldHint. Clients use them to decide what to ask the person before calling.
• Configure your client to ask before every write, at least for tools marked destructive.
• The two step confirmation above is the server's own guard on top of that, not a replacement for it.

Errors and limits

A refused operation comes back as a tool result with isError: true, its text naming the error code, message and request_id, and the full error envelope in structuredContent. Rate limits, scopes and every error code apply exactly as in REST, and every call shows up in the key's request log.