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:
| field | what it tells you |
|---|---|
features | what is switched on here — AI, GitHub, pull requests, ticketing, inbox, policies |
scope | what this token may do |
projects, tools | how much it can see, how many tools it was offered |
release, retention_days | which 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.
| scope | what it adds |
|---|---|
read | the search, get and list tools — nothing writes |
operate | (the default) plus the issue, rule and policy actions |
admin | everything, 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
readtoken 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.