Give Claude Code, Cursor or Zed your Lambda logs — not your AWS account.

What the MCP server is

A local server that turns your stitched Lambda logs into something an AI assistant can actually query.

LogStitch already does the hard part: it pulls CloudWatch log events for your Lambda functions, reads the request ID stamped on every line, and stitches those lines back into the invocation they belong to — then stores the result in a SQLite database on your Mac. The MCP server exposes that database to AI assistants running on the same machine.

The important part is what doesn't happen. The AI never receives your AWS credentials, and it never talks to AWS. It talks to LogStitch over 127.0.0.1, and LogStitch answers from log data it has already downloaded and organized. Your credentials stay in the macOS Keychain, used only by LogStitch itself. That means you can point an assistant at production log data without ever handing it a key, a role, or a console session.

MCP — the Model Context Protocol — is an open standard for connecting AI assistants to external tools and data sources. A program exposes a set of tools; an MCP-capable assistant discovers those tools and calls them when a question needs them. LogStitch exposes 21 such tools, covering invocations, errors, patterns, performance, cost, and full-text log search.

Security model

Loopback-only, same-machine-only, no egress. The boundary is enforced by where the socket is bound, not by a setting you have to trust.

The MCP server listens on the loopback interface only — it binds to 127.0.0.1, never to 0.0.0.0 or a LAN address. There is no configuration that exposes it to the network, because the bind address is not configurable. A machine on the same Wi-Fi, a device on your VPN, or anything on the public internet cannot reach it. Only processes already running on your Mac can connect.

Because a loopback-bound HTTP server can still be attacked from a browser page via DNS rebinding, the server also validates the Origin header on every request, as the MCP Streamable HTTP transport requires. Requests carrying no Origin — which is what native clients such as Claude Code send — are allowed. Requests carrying an Origin that does not resolve to loopback are rejected with 403 Forbidden before any tool runs, so a malicious web page cannot use your browser as a proxy into your log database.

Every tool reads from the local SQLite database. The server makes no outbound network requests of its own and transmits nothing off your device. The single exception is deliberate, opt-in, and off by default: the sync_function tool, which lets an assistant ask LogStitch to fetch fresh CloudWatch logs. That one makes AWS API calls — using your credentials, from LogStitch, not from the AI — and it only works if you have explicitly enabled Allow MCP-triggered syncs. You can revoke it at any time.

Enabling the server

The server is off by default. Turning it on takes one toggle.

1. Open LogStitch → Settings (⌘,).
2. Select the MCP Server tab.
3. Turn on Enable MCP Server. The status line below the toggle changes to Running on localhost:47821, and an MCP indicator with a green dot appears in the main window's toolbar.
4. In Connection Setup, pick your client from the AI Tool menu and follow the numbered steps it shows.

That's it — the server is live and ready for a client to connect. If the port is already taken by something else, the toggle reverts and the status line shows the error rather than silently failing.

Connection Setup

The AI Tool picker lists the ten clients LogStitch ships instructions for, grouped by family — command line, editors, desktop apps, and an "anything else" entry for the manual route. Select one and the panel shows numbered setup steps for that client specifically: the config file it uses, the exact snippet in that client's own format, a copy button on each step, a Reveal in Finder link that opens the folder containing that client's config file, and a closing step describing how to confirm the connection in that client's own UI.

This matters more than it sounds like it should. Every client wants the same URL, but each one wants it under a different key — and four of the ten fail silently if you use the wrong one. See supported AI clients for the full breakdown.

Test Connection, next to the toggle, probes the local endpoint and reports the tool count on success. On failure it distinguishes between connection refused, a request that timed out, and a response that wasn't what an MCP server should return — which tells you whether the problem is the server, the port, or something else holding the address.

Settings on this tab

Transport

The server implements the MCP Streamable HTTP transport (protocol revision 2025-03-26 and later) at POST /mcp. It is stateless: there is no session to establish and no server-initiated stream to open, so GET /mcp and DELETE /mcp return 405 Method Not Allowed by design. Fast calls such as initialize and tools/list come back as a single JSON response; tools/call streams its result back over server-sent events on the same connection, with keep-alive comments so a multi-minute CloudWatch fetch does not get torn down as idle.

Supported AI clients

Any MCP client that speaks Streamable HTTP can connect. Ten of them have setup built into the app.

The server is not tied to any one vendor. It exposes POST /mcp over the standard MCP Streamable HTTP transport, so any client implementing that transport can talk to it — nothing is negotiated, licensed, or registered on either side. LogStitch works with these clients by reading their published config formats; there is no partnership or integration agreement behind any entry in this table.

What LogStitch adds is the tedious part: as of v1.4 the MCP Server settings tab ships ready-made, per-client setup for the ten clients below, with the snippet already in that client's format and your actual port already filled in.

Windsurf is also distributed as Devin Desktop; the config path is the same. Config formats verified against each vendor's own documentation on 12 August 2026.

Four ways to get it wrong and see no error

Every client above wants the same URL. Each one wants it under a different key. In four cases, using the key you would reasonably expect produces no error message at all — the client simply never connects, and the LogStitch tools never appear:

• Cline · Roo Code — omit type and it falls back to the deprecated SSE transport, which LogStitch does not serve. You need "type": "streamableHttp" explicitly.
• Gemini CLI — url means SSE there. Streamable HTTP is httpUrl, and the difference is one letter of config away from silence.
• VS Code — nests servers under servers, not the mcpServers that almost everything else uses.
• Zed — calls them context servers, so the root key is context_servers.

This is the reason the in-app picker is worth using rather than hand-writing config from memory: it emits the right shape for the client you selected, so a silent no-op isn't one of the outcomes.

Connecting Claude Code

One command, run once. Claude Code discovers the server on every session after that.

Recommended: the CLI

With the server running, run this in your terminal:

claude mcp add --transport http -s user logstitch http://127.0.0.1:47821/mcp

The -s user flag registers the server at user scope, so it is available in every project rather than just the current directory. If you changed the port in settings, substitute it here.

Alternative: edit the config directly

Merge this into the mcpServers object in ~/.claude.json for user scope, or .mcp.json in a project directory for project scope:

{
  "mcpServers": {
    "logstitch": {
      "type": "http",
      "url": "http://127.0.0.1:47821/mcp"
    }
  }
}

Restart any Claude Code sessions that were already open — the config is read at session start. Ask Claude to list its tools and you should see the LogStitch tools appear.

Claude Desktop, via a bridge

Claude Desktop connects — but not the way you would first try. The remote connector route genuinely cannot reach a local server; a stdio bridge can.

Why the obvious route fails

Claude Desktop's remote connector feature is routed through Anthropic's servers rather than run on your machine. A connector pointed at http://127.0.0.1:47821/mcp is evaluated from Anthropic's infrastructure, and 127.0.0.1 means "this machine" wherever it is evaluated — so from there it resolves to Anthropic's own server, not to your Mac. No configuration fixes that, and exposing LogStitch to the public internet so a remote connector could reach it would defeat the entire security model, so LogStitch deliberately does not offer it.

The route that does work

Claude Desktop also launches MCP servers as local subprocesses over stdio, and that half runs on your machine. So you put a relay in the middle: mcp-remote is launched as the subprocess, speaks stdio to Claude Desktop on one side, and speaks Streamable HTTP to LogStitch on the other. Both hops stay on your Mac; nothing is routed through Anthropic.

Merge this into ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "logstitch": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://127.0.0.1:47821/mcp"]
    }
  }
}

Quit and reopen Claude Desktop afterwards — it reads this file at launch. The LogStitch tools then appear under the tools menu in a new conversation.

If you have the choice, Claude Code is still the simpler path: it speaks Streamable HTTP natively, so it connects straight to the loopback address with no bridge, no subprocess, and no runtime dependency.

Anything else: manual setup

Not on the list? Anything that runs on the same Mac and speaks Streamable HTTP can still connect.

The ten clients in the table above are the ones LogStitch ships instructions for — not the ones it is limited to. Any MCP-capable client running locally, including an editor extension, a CLI agent, or your own script built on an MCP SDK, can connect using the parameters below. Selecting Anything else in the AI Tool picker shows the same details with your configured port filled in. There is no API key or token: the loopback binding and Origin validation are the security boundary, so anything already running on your Mac is already trusted.

Smoke-test it first

Before wiring up a client, confirm the server is answering. This asks it to list its tools:

curl -sS http://127.0.0.1:47821/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

A healthy server returns a JSON-RPC result listing 21 tools. Connection refused means LogStitch isn't running or the port is wrong; 405 means you sent a GET; 403 means an Origin header that doesn't resolve to loopback came along for the ride. The Test Connection button on the MCP Server settings tab runs the equivalent check and reports the tool count without you leaving the app.

Browser-based MCP clients work as long as the page is served from a loopback origin; the server sends the CORS headers such a client needs. A page on any other origin is refused.

Tool reference

All 21 tools the server exposes, grouped as they appear in the app. Parameters in blue are required; the rest are optional.

Example workflows

Real questions, and the tools your assistant reaches for to answer them.

Troubleshooting

The failure modes you are most likely to hit, and what each one actually means.

The server doesn't appear in my client

Check the MCP Server settings tab: the status line should read Running on localhost:47821 with a green dot, and the toolbar should show the MCP indicator. If it says Stopped, the toggle is off. Hit Test Connection to confirm the endpoint answers — if it reports 21 tools, the server is fine and the problem is on the client side. If you registered the server while a Claude Code session was already open, restart that session; the MCP config is read at session start, not re-read mid-session.

No error, but the tools never show up

Almost always the wrong config key. Four clients accept a config that looks right, log nothing, and quietly never connect: Cline · Roo Code falls back to deprecated SSE unless you set "type": "streamableHttp"; Gemini CLI treats url as SSE and needs httpUrl for Streamable HTTP; VS Code nests under servers rather than mcpServers; and Zed uses context_servers. Check yours against the client table, or re-copy the snippet from the AI Tool picker, which emits the right shape for the client you select. If Test Connection succeeds while your client still sees nothing, this is the cause.

Claude Desktop shows nothing after adding the bridge

Two usual causes. Either Claude Desktop wasn't fully quit and reopened — it reads claude_desktop_config.json at launch, so a window reload isn't enough — or Node is missing. mcp-remote runs under npx and needs Node 18 or later; the MCP Server settings tab reports what it found. Also confirm you used the command/args form from the bridge section rather than a url: a remote connector pointed at 127.0.0.1 cannot reach your Mac and never will.

Connection refused

Something is listening at nothing on that port. In order of likelihood: LogStitch is not running (the server lives inside the app, so quitting the app stops it); the client is configured with a different port than the app; or the app failed to bind at startup because another process holds the port. The settings tab reports "Port N is already in use" when that happens — pick another port there and update your client config to match.

404 on /sse

You are using an older config that points at the legacy SSE endpoint. LogStitch now implements the Streamable HTTP transport, and the old /sse and /message paths were removed — they return 404. Update the URL to http://127.0.0.1:47821/mcp and set the transport type to http.

405 on GET

Expected, not a fault. The transport is stateless, so there is no server-initiated stream to open with GET and no session to tear down with DELETE; both return 405. MCP clients POST. If your client insists on opening a GET stream first, it is speaking the older HTTP+SSE transport rather than Streamable HTTP.

403 Forbidden

The request carried an Origin header that does not resolve to loopback, and was rejected by the DNS-rebinding defense before any tool ran. Native clients send no Origin at all and are unaffected. If you are building a browser-based client, serve it from localhost or 127.0.0.1.

The data looks stale

The MCP server reads the local database — it does not fetch from CloudWatch on every question. If your assistant is reasoning about logs that end an hour ago, that is simply where the cache ends. Sync the function in the app, or enable Allow MCP-triggered syncs so the assistant can call sync_function itself. Bear in mind that syncing makes AWS API calls and may incur cost.

Results look truncated

The Response Size setting caps how much any tool returns, and a tool's own limit parameter is clamped to that ceiling — so asking for 1,000 results on the Standard preset yields 500. Raise the preset if you need more, but remember that everything returned lands in your assistant's context window.

Frequently asked questions

Related

The local-AI angle is where LogStitch differs most sharply from the hosted platforms.