MCP server

BackTalk ships an MCP server so an AI agent can read and triage your signals directly — "what did developers complain about today?" answered from your live inbox. It uses the Streamable HTTP transport and the same API keys as the REST API.

Endpoint: https://backtalk.sh/api/mcp Auth: Authorization: Bearer btk_YOUR_KEY (create one in Settings → API keys).

Tools

The write tools (triage_signal, triage_signals, curate_answer, trigger_sync, trigger_probe) are only registered when your key has the write scope, so a read-only key never sees them; whoami needs no scope. The demo question "what did developers complain about today?" is answered by report (period=today) together with list_signals (sentiment=["negative"], since=<today>).

Prompt-injection note. Signal content (title, snippet, author, url) is untrusted third-party text scraped from the public internet. The tool descriptions say so, and your agent should treat returned content as data to analyse — never as instructions to follow.

Connect Claude Code

claude mcp add --transport http backtalk https://backtalk.sh/api/mcp \
  --header "Authorization: Bearer btk_YOUR_KEY"

Then ask Claude things like "Use backtalk: what did developers complain about today?" The exact claude mcp add command (with your key filled in) is shown on the Settings → API keys page after you create a key.

Connect Claude Desktop

Claude Desktop can't take a bearer header directly: its config file only launches local (stdio) servers, and the Add custom connector screen in Settings expects OAuth, which BackTalk doesn't support yet. Bridge the endpoint with mcp-remote instead; it needs Node.js installed.

First quit Claude Desktop fully (Cmd+Q on macOS). The app rewrites its config file on exit, so edits made while it's running are lost. Then add this to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json, Windows: %APPDATA%\Claude\claude_desktop_config.json, or Settings → Developer → Edit Config in the app) and relaunch:

{
  "mcpServers": {
    "backtalk": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://backtalk.sh/api/mcp",
        "--header",
        "Authorization: Bearer btk_YOUR_KEY"
      ]
    }
  }
}

On Windows, spaces inside args can get mangled before they reach the server; if the connection fails with an auth error, pass "--header", "Authorization:${AUTH_HEADER}" in args and add "env": { "AUTH_HEADER": "Bearer btk_YOUR_KEY" } to the entry.

Connect ChatGPT

In a ChatGPT client that supports custom MCP connectors (Developer mode / custom connectors), add a connector with:

• Transport / type: HTTP (Streamable HTTP)
• URL: https://backtalk.sh/api/mcp
• Header: Authorization: Bearer btk_YOUR_KEY

ChatGPT's MCP support leans on the read tools (list_signals, get_signal, report) for search-and-fetch style use.

Auth, scopes and limits

• Auth is the same bearer API key as REST; a bad or missing key gets a 401 with WWW-Authenticate: Bearer. OAuth / dynamic client registration is future work.
• Scopes work exactly as in the REST API: read tools need read, the write tools (triage_signal, triage_signals, curate_answer, trigger_sync, trigger_probe) need write, whoami needs only a valid key, and a read-only workspace refuses every write tool.
• Roles apply here too: a key whose creator has been demoted to viewer can still read, but every write tool refuses until they are promoted back. Removing them from the workspace stops the key entirely.
• Rate limits are the same per-key budget (120 requests/minute); over it, the server returns 429.

See the REST API guide for scopes, error codes, and rate-limit details in full.