MCP Server Settings

The MCP Server tab of Settings lets AI agents - Claude Code, Cursor, Codex, or any other client of the Model Context Protocol - query LogRaker directly: list your Streams, read their live output, search scrollback, check connection health, and read LogRaker's own diagnostic log.

The server is off by default. When enabled, it listens on this Mac only (the loopback address 127.0.0.1) - nothing is exposed to your network - and it answers only agents you have allowed.

Enabling the server

Turn on Enable MCP Server. The status line below shows Running on 127.0.0.1:<port> once the server is listening; it starts automatically with LogRaker from then on, and stops the moment you turn the switch off.

Port is where the server listens (1024-65535). If another program already uses the port, the status line says so - pick a different one and LogRaker restarts the server automatically.

Allowing agents

The first time an agent connects, it signs in: it opens a page in your web browser, and LogRaker comes forward asking Allow <agent> to read your logs? Click 'Allow' only if you are connecting that agent right now - the name is the one the agent gives itself. The browser page then returns to the agent on its own, and you can close its tab. 'Don't Allow', or no answer within five minutes, turns the agent away.

Allowed agents are listed under Agents with when you allowed them and when they last connected. Select one and click 'Revoke…' to cut it off at once; it has to ask again the next time it connects.

Connecting an agent

Click 'Connect an Agent…' and pick your agent - Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot, or Google Antigravity - to see a ready-made registration snippet with your current port filled in, and how that agent signs in.

Claude Code - Copy Command gives a claude mcp add command. Paste it into Terminal and run it once; it registers LogRaker for all your projects. Then run claude mcp login lograker to sign in.
Cursor - Copy Snippet gives a JSON fragment. Merge it into ~/.cursor/mcp.json (create the file if it doesn't exist), or into a project's .cursor/mcp.json to scope it to that project. Cursor's own Settings ▸ MCP screen edits the same file. Cursor signs in the first time it connects.
Codex - Copy Snippet gives a TOML fragment. Add it to ~/.codex/config.toml, then run codex mcp login lograker to sign in.
Gemini CLI - Copy Command gives a gemini mcp add command. Paste it into Terminal and run it once; it registers LogRaker for all your projects. It signs in the first time it connects; /mcp auth lograker signs in again.
GitHub Copilot - Copy Snippet gives a JSON fragment for VS Code. Merge it into your user-level MCP configuration (Command Palette ▸ MCP: Open User Configuration) or a project's .vscode/mcp.json. VS Code asks to sign in the first time it connects; choose 'Allow'. Copilot calls MCP tools in agent mode.
Google Antigravity - Copy Snippet gives a JSON fragment. Merge it into ~/.gemini/config/mcp_config.json, or a project's .agents/mcp_config.json. It signs in the first time it connects.

Agents read their configuration when a session starts, so LogRaker should be running before you start the agent - if it wasn't, launch LogRaker and reconnect (in Claude Code, type /mcp and choose reconnect) or restart the agent's session.

Other MCP-capable agents work too: any client that supports streamable HTTP and MCP's OAuth sign-in can use the same URL.

Tools

Once connected, an agent can call these tools:

list_streams - every configured Stream with its id, its Source and Source type, its groups, what it tails (a file, journal units, a cloud project and filter, a log group, a bucket and prefix), its live status, and buffered line count.
read_tail - the last lines of a Stream's buffer.
search_logs - search a Stream's scrollback by substring or regular expression.
wait_for_match - wait for a line matching a pattern to arrive in a Stream, and get it back as soon as it does: after a deploy, for example, wait for started or ERROR. It gives up after a timeout, a minute unless the agent asks for longer (five at most), and can first check the latest lines already in the buffer.
read_around - the lines before and after any line another tool returned, to see what led up to a match and what followed.
list_monitors - every Monitor with its patterns, what it watches, its new and total match counts, when it last matched, its color, and whether it is alarming.
read_monitor_matches - a Monitor's most recent matches, each with its time, Stream, the pattern that fired, and the line; optionally only those since the count was last reset.
get_stream_status - one Stream's connection state in detail: status, activity, lines and bytes received, start time, its Source and what it tails.
read_history - lines from before the buffer: the Source is asked again for a past window, instead of reading what is in memory. Every Source can answer, though a Stream on a Server or a cloud service has to be running, since the connection does the asking. For a file the lines' own timestamps decide, and rotated files are not searched. A Unified Log window may cover at most 24 hours, an Amazon S3 window at most 7 days.
read_diagnostic_log - the tail of LogRaker's own internal log, for troubleshooting LogRaker itself.

read_tail, search_logs, wait_for_match and read_monitor_matches take an optional min_severity - EMERG, ALERT, CRIT, ERROR, WARNING, NOTICE, INFO or DEBUG - so an agent can ask for the errors in a syslog or Google Cloud Stream rather than reading everything. As with the Minimum Severity filter in the app, a line that carries no severity of its own is left out once you set one. Every line comes back with an id that stays the same while the line is in the buffer, which is what read_around takes.

read_tail and search_logs can also narrow to a time window with since and until, each an ISO 8601 time such as 2026-09-15T14:00:00Z or a span back from now such as 15m or 2h. Those two and wait_for_match also take a Google Cloud execution_id or trace_id; a trace_id across several Streams follows one request through each service. As with the severity floor, a line without the field a filter asks about is left out.

read_tail, search_logs, wait_for_match and read_around take format: text, the default, or json, which gives each line's time, severity, host, process and message as separate fields, where the Stream has them.

read_tail, search_logs and wait_for_match also work across Streams: give stream_ids, a list, instead of stream_id, or leave both out for every Stream with a buffer. Lines from several Streams come back in one time order, each labelled with its Stream, and lines without a time are left out, as in a merged Layout.

Lines come back as plain text: the color codes a Source such as Google Cloud writes into its output are removed, in the result and before a search pattern is matched, so an agent sees what you see.

Several agents can be connected at the same time, each with its own session.

Following along

Besides the tools, an agent can browse your Streams and Monitors as a list and open any of them by name: a Stream gives its recent lines, a Monitor its recent matches. Agents that show attachments list them that way.

An agent can also follow one. LogRaker tells it when new lines or matches arrive, at most once every couple of seconds per Stream or Monitor, so an agent watching a busy log is not buried. It is also told when you add, delete or rename a Stream or a Monitor, so an agent started this morning knows about the Stream you made at noon.

All of this needs Read Streams, like the reading tools.

Agent Actions

Agents may read your Streams and nothing else until you allow more. Click 'Edit…' next to Agent Actions and check each action agents may take:

Read Streams - read lines, search them, and read Monitors and the diagnostic log. On until you turn it off; with it off, every tool above refuses.
Start Streams (start_stream) - start a stopped or idle Stream.
Stop Streams (stop_stream) - stop a Stream. Its lines stay until it starts again.
Restart Streams (restart_stream) - reconnect a Stream with its saved settings.
Clear Streams (clear_stream) - remove a Stream's lines and its Monitor matches.
Reset Monitors (reset_monitor) - mark a Monitor's matches seen: its count drops to zero and its alarm clears.
Create Monitors (create_monitor) - make a Monitor that watches the Streams the agent names for the patterns it gives. It lands in a group called 'MCP', and Undo removes it, as it removes one you made yourself.

The Stream actions take a stream_id or a list of stream_ids. Reset Monitors takes a monitor_id, a list of monitor_ids, or neither, which resets every Monitor that has new matches. Create Monitors takes a name, the patterns to watch for, and the stream_ids to watch; the new Monitor takes the same settings as one created in the app and left unchanged. list_streams and list_monitors tell an agent which actions you allow, and an action you haven't allowed returns an error saying where to allow it. A change takes effect at once, for every connected agent.

Privacy

Log lines can contain sensitive information, which is why the server is off by default, answers only on this Mac, and serves only agents you allowed. Allowed agents and the port stay on this Mac - they are not included in saved configurations and do not sync via iCloud.