Setup and configuration - MCP

What this integration does

The remote MCP (Model Context Protocol) server lets AI assistants and other tools that speak the standard talk directly to DockRay's monitoring data - search projects and errors, read their diagnostic detail, and, with the right permissions, change an error's status or manage a project. There is one endpoint: POST https://dockray.io/api/mcp, JSON-RPC 2.0, protocol version 2025-06-18. This is a paid plan component, separate from error ingest - an account without it cannot issue a working key.

Creating an access key

In the panel go to Settings → MCP Integration and create a new key. Name it after the client or automation that will use it, and only tick the permissions that tool actually needs. The generated token is shown once, at creation time - DockRay stores only its hash, so a lost token cannot be recovered, only replaced by generating a new key.

Connecting an MCP client

In a client that speaks MCP, set the endpoint to https://dockray.io/api/mcp and add an authorization header with the token:

Authorization: Bearer dockray_mcp_…

Once connected, the client should call the standard tools/list request - the response lists only the tools the key is allowed to use. A tool the key has no permission for simply does not exist from its point of view: it is absent from the list, and calling it fails as if it were never defined.

The first test

Call projects.list from the client - it should return the projects on the account the key belongs to, along with their current monitoring state. If you ticked the permission to read errors, also try issues.list on one of the projects. An empty response despite existing data usually means the key lacks the right permission - not that the account has nothing to show.

What a single call looks like

The server speaks plain JSON-RPC 2.0, so calling a tool is an ordinary POST request with the tools/call method:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "projects.list",
    "arguments": {"limit": 10}
  }
}

An unknown or disallowed tool gets exactly the same shape of response as a call to a method that never existed at all - from the protocol's point of view there is no difference between 'no permission' and 'this tool is not defined'.

Separate keys for separate clients

It is worth issuing a separate key for every client or automation, even when they need the same permissions. Keys are revoked independently: losing one tool, or ending work with one vendor, does not then require interrupting the other integrations.