MCP server

Step 1 — create an API key

In WatchCat, an organization owner opens Administration → API keys and creates a key. The full token (it starts with wc_) is shown once, so copy it straight away. Choose a scope:

Step 2 — connect your assistant

Add the server to any MCP-capable client. In Claude Code, one command registers it:

claude mcp add --transport http watchcat https://watchcat.io/mcp \
  --header "Authorization: Bearer wc_your_token_here"

For clients configured through a JSON file (such as Claude Desktop), add an HTTP server entry:

{
  "mcpServers": {
    "watchcat": {
      "type": "http",
      "url": "https://watchcat.io/mcp",
      "headers": { "Authorization": "Bearer wc_your_token_here" }
    }
  }
}

What the assistant can do

Once connected, the assistant has tools for every resource you manage in the app. Everything is scoped to the key's organization — it can never reach another organization's data.

A read key is offered only the read tools, so an assistant connected with it can answer questions about your monitoring but cannot change anything. Plan limits apply exactly as they do in the app.

Tool names

Each operation is a tool named <verb>_<resource> — for example list_service_monitors, create_cron_monitor, regenerate_cron_monitor_token, resolve_incident, and get_account_usage. A read_write key is offered the full set; a read key is offered only the read-only tools (the list_* and get_* tools, plus get_account_usage). Each tool takes the same arguments as its REST API counterpart, so that reference doubles as the argument reference for every tool.

Calling the server directly

Your MCP client handles the wire protocol for you, but it helps to know what sits underneath when you are testing a key or building your own client. The endpoint speaks JSON-RPC 2.0 over a single HTTP POST and is stateless — every request carries its own bearer token, so there is no session to open first. List the tools the key can use:

curl -X POST https://watchcat.io/mcp \
  -H "Authorization: Bearer wc_your_token_here" \
  -H "Content-Type: application/json" \
  -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }'

Run one with tools/call, passing the tool name and its arguments:

curl -X POST https://watchcat.io/mcp \
  -H "Authorization: Bearer wc_your_token_here" \
  -H "Content-Type: application/json" \
  -d '{
        "jsonrpc": "2.0",
        "id": 2,
        "method": "tools/call",
        "params": {
          "name": "create_service_monitor",
          "arguments": { "url": "https://example.com", "interval_seconds": 300 }
        }
      }'

A tool's output comes back as text inside the JSON-RPC result — the same JSON the REST API would return, carried in a text block:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      { "type": "text", "text": "{ \"created\": true, \"monitor\": { \"id\": 74, ... } }" }
    ],
    "isError": false
  }
}

Errors

• A missing, unknown, or revoked token returns 401 with a JSON-RPC error.
• An unknown tool or method returns a JSON-RPC error object — the request itself was not understood.
• When a tool runs but cannot complete — a validation failure, a plan limit, a missing argument, or a record that does not exist — the call still succeeds at the protocol level and returns a normal result with isError set to true and the reason in its text, so the assistant can read it and correct itself.