AI Assistants (MCP)

What it is#

Reliable runs an MCP server (Model Context Protocol, the standard way AI tools call outside services) at:

https://reliablebackend.ziloris.com/mcp

Point Claude Code, Cursor, VS Code or Claude Desktop at it with an API key and the assistant can list your frontend errors, open one with its source-mapped stack trace, breadcrumbs and browser context, read the dashboard metrics, and look through incidents and their timelines. With a key that allows it, it can also acknowledge, resolve and annotate incidents.

Every key belongs to one project and only ever sees that project. The server speaks streamable HTTP and keeps no session: each request carries the key in an Authorization: Bearer rl_pak_... header.

Create an API key#

1. Open Dashboard → MCP Server with the project selected.
2. Click Create key and name it after where it will be used ("Claude Code on my laptop").
3. Tick Allow write actions only if the assistant should be able to change incidents (see Read and write).
4. Copy the key. It starts with rl_pak_ and is shown once; Reliable only keeps a hash. The same dialog shows the setup below for each client with your key already filled in.

Connect your client#

Replace YOUR_API_KEY with your key. The server registers as reliable.

Claude Code

Run in your project's directory:

claude mcp add --transport http reliable https://reliablebackend.ziloris.com/mcp --header "Authorization: Bearer YOUR_API_KEY"

Cursor

Add to .cursor/mcp.json in your project:

{
  "mcpServers": {
    "reliable": {
      "url": "https://reliablebackend.ziloris.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

VS Code

Add to .vscode/mcp.json. VS Code asks for the key when the server first starts, so the file holds no secret and can be committed:

{
  "servers": {
    "reliable": {
      "type": "http",
      "url": "https://reliablebackend.ziloris.com/mcp",
      "headers": {
        "Authorization": "Bearer ${input:key}"
      }
    }
  },
  "inputs": [
    {
      "type": "promptString",
      "id": "key",
      "description": "Reliable API key",
      "password": true
    }
  ]
}

Claude Desktop

Custom connectors in Claude Desktop can't send an Authorization header, so connect through mcp-remote, a small local bridge that adds the header (it needs Node.js). Add this to claude_desktop_config.json and restart Claude Desktop:

{
  "mcpServers": {
    "reliable": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://reliablebackend.ziloris.com/mcp",
        "--header",
        "Authorization: Bearer YOUR_API_KEY"
      ]
    }
  }
}

Tools#

Tools that take a frontend_project accept its uuid, name or slug, and it can be left out when the project has only one frontend project.

• list_frontend_projects: the project's frontend apps, with uuid, name, domain, environment and when each last sent data.
• list_errors: JavaScript error groups of one frontend project in the last 24h, 7d or 30d, most recent or most frequent first (up to 50), with counts, affected sessions and users, page path and release; plus failing network requests and headline totals.
• get_error: everything about one error: the stack trace resolved to your original files and lines through uploaded source maps (when there are any), the React component stack, breadcrumbs, router history, browser state, the linked failing request, and whether a session replay was recorded.
• get_metrics: the dashboard numbers for one frontend project and window, by kind: errors, network, vitals, websockets or ux.
• list_incidents: incidents, most recent activity first, filtered by status, severity, source or a title search (up to 50).
• get_incident: one incident with its activity timeline, the pages sent, and for frontend incidents the latest matching error's context.

With the write scope, four more:

• acknowledge_incident: mark an open incident as being worked on, which stops further paging and escalation for it.
• resolve_incident: close an incident and cancel its pending pages. If the error happens again, a new incident opens.
• add_incident_note: add a note to the incident's timeline, for example the root cause or the fix.
• mark_not_an_issue: mute a frontend error incident as expected noise, either just that error (scope: "error") or all similar ones (scope: "similar"). See Not an issue.

Actions taken this way show up on the incident timeline under the key's name (as api-key:<name>), and stop paging and escalation the same way an engineer's would. The server also offers a prompt, investigate_error, that walks the assistant through looking up one error, reading its context and proposing a fix.

Read and write#

Every key can read. A key created with Allow write actions also gets the four incident tools above; a read-only key does not see them at all, and the server tells the assistant that acting on incidents needs a key with write access. The write tools change what your on-call engineers see (an acknowledged incident stops paging), so only give write access where you want that.

Rate limit#

Each key can make 120 requests per minute. Past that the server answers 429 with a Retry-After header. An interactive session stays far below this; the limit is there for an assistant stuck in a loop.

What the assistant sees#

Tool results go into the AI model's context, and from there to whoever runs the model. So before anything leaves the server:

• Credentials are masked. JWTs, bearer tokens, Authorization and cookie headers, and fields whose names look secret (password, token, secret, api key, ...) in captured bodies, URLs, storage and messages are replaced with a [redacted] marker.
• Long fields are capped. Stack traces, request and response bodies, breadcrumbs and storage are cut to a few KB each, with a ...[truncated N chars] marker where text was dropped.

Masking works on patterns, so it is a safety net rather than a guarantee. The SDK's own scrubbing still applies before anything is stored.

Try it#

With the server connected, ask your assistant in the repository of the app you instrumented:

Look at the latest errors in my-web-app and fix the top one.

A typical run lists the frontend projects, lists the errors, opens the top one with get_error, reads the resolved stack and breadcrumbs, finds the code in your repository and proposes a change. Use your frontend project's name in place of my-web-app.