DOCUMENTATION

Connect your AI agent

The console speaks MCP: one command and Claude Code, Claude Desktop or Cursor can read your errors and act on them.

The console speaks the Model Context Protocol, so Claude Code, Claude Desktop, Cursor or anything else that speaks MCP can read your errors and act on them. One command, no plugin, no agent process to run.

Before you start

You need two things:

  • the console's base URL, e.g. https://yourconsole.cloud;
  • an MCP token — instance-level, issued by an administrator.

1. Get the token

An administrator generates it once:

php cli.php token generate mcp

In the console, the footer's ✦ AGENT button opens the CONNECT dialog, which hands you the finished command. The token is masked for everyone; an admin's REVEAL or COPY fills it in through an audited call, so who took the token is on record. Until MCP[TOKEN] is set the dialog stays dark.

2. Add the server

Claude Code
claude mcp add --transport http console https://yourconsole.cloud/mcp \
  --header "Authorization: Bearer YOUR_MCP_TOKEN"
Claude Desktop / Cursor
{
  "mcpServers": {
    "console": {
      "type": "http",
      "url": "https://yourconsole.cloud/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_MCP_TOKEN"
      }
    }
  }
}
Raw JSON-RPC
# everything the agent does is one POST; useful for testing the token
curl -s https://yourconsole.cloud/mcp \
  -H "Authorization: Bearer YOUR_MCP_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"get_console_info","arguments":{}}}'

Two consoles? Each needs its own server name — the field above the command in the CONNECT dialog sets it.

3. Check it answered

Ask the agent to call get_console_info. It is the first call any agent should make and it answers:

fieldwhat it tells you
featureswhat is switched on here — AI, GitHub, pull requests, ticketing, inbox, policies
scopewhat this token may do
projects, toolshow much it can see, how many tools it was offered
release, retention_dayswhich console it is talking to, and how far back

4. Know what the token may do

The scope is instance-level (MCP[SCOPE]). Tools outside the scope are not offered to the agent at all — it cannot call what it cannot see.

scopewhat it adds
readthe search, get and list tools — nothing writes
operate(the default) plus the issue, rule and policy actions
admineverything, including accounts, projects and keys

5. The three things agents are actually for

Triage. get_inbox is the landing question: what needs a person now, across issues, attack campaigns, CVE findings, late monitors and release cohorts — each row with the one action that is ready.

Fixing. The path is short and each step exists to save the next one work:

search_issues  →  get_issue  →  get_fix_context  →  (patch in your checkout)
               →  set_issue_state resolved + set_issue_note
               or link_pull_request, and the console verifies the fix itself

get_fix_context is the call worth knowing: one request returns the occurrence with its stacks and code slice, source slices from the mapped GitHub repository at the release ref, the suspect commits on a regression, the repo name so the agent can find the files in its own checkout, and the cached analysis.

Keeping the rules. list_rules, create_rule (with dry_run to preview a pattern against stored events before writing it), set_rule_mode, expire_rule, delete_rules — and the same set for policies. Project names instead of ids, and every write leaves an audit line.

6. What it will not do

  • It cannot exceed its scope. A read token is a read-only console.
  • Every write is audited with the token's identity.
  • It never merges. An agent can open a pull request and record what it found; a person merges it.

Next: Send your first error if the console has no data yet, or Ingest API v1 for the wire contract underneath.