Give Claude your Lambda logs — not your AWS account.

LogStitch ships a built-in MCP server that lets AI assistants on your Mac query your already-stitched Lambda logs. The assistant never receives your AWS credentials and never talks to AWS — it queries a local database, over loopback, on your machine.

On this page

  1. What the MCP server is
  2. Security model
  3. Enabling the server
  4. Connecting Claude Code
  5. Claude Desktop
  6. Other MCP clients
  7. Tool reference
  8. Example workflows
  9. Troubleshooting
  10. FAQ

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.

In short
Your assistant gets a read-only window onto logs that are already on your Mac. AWS sees nothing new, and neither does anyone else.

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.

Also documented in the privacy policy
Section 04 of the LogStitch privacy policy covers the local MCP server: loopback binding, same-machine connections only, and no data transmitted off your device.

Enabling the server

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

  1. Open LogStitch → Settings (⌘,).
  2. Select the Claude Integration 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.

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.

Settings on this tab

Server Port
Defaults to 47821. Any port from 1024 to 65535 is accepted; ports below 1024 need root. LogStitch tests the port before saving and tells you if it is already in use. Changing the port while the server is running restarts it on the new one.
Response Size
A ceiling on how much any single tool may return: Conservative (100 results, 50 KB of log content), Standard (500 results, 100 KB — the default), Large (2,000 results, 500 KB), or Unlimited. A tool's own limit parameter is clamped to this ceiling, so it protects your assistant's context window from a runaway query.
Allow MCP-triggered syncs
Off by default. Enables the sync_function tool, which lets an assistant fetch fresh CloudWatch logs on demand. This makes AWS API calls and may incur cost, which is why it is opt-in.
Available Tools
Expands to the full list of tools the server exposes, with descriptions — the same catalog documented in the tool reference below.

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.

Not stdio
LogStitch does not run as a stdio subprocess of your client. It is a long-lived HTTP server inside the app, so configure your client with an HTTP transport and a URL — not a command and args. The app must be running for the server to answer.

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.

Copy it from the app instead
The Claude Integration settings tab shows both of these snippets with your actual port already filled in, each with a copy button. If you have changed the port, that is the quickest way to get a correct command.

Claude Desktop

Claude Desktop cannot connect to the LogStitch MCP server. This is a structural limitation, not a missing feature.

Claude Desktop's custom connectors are routed through Anthropic's servers rather than run on your machine. That means the connector fetches your MCP endpoint from Anthropic's infrastructure — which has no route to 127.0.0.1 on your Mac, because 127.0.0.1 means "this machine" wherever it is evaluated. From Anthropic's side, that address is their own server, not yours.

No configuration fixes this. Exposing LogStitch to the public internet so a remote connector could reach it would defeat the entire security model described above, so LogStitch deliberately does not offer it.

Use Claude Code instead. It runs locally on your Mac, so it connects straight to the loopback address with no intermediary — see connecting Claude Code above. Any other MCP client that runs locally works too.

Other MCP clients

Anything that runs on the same Mac and speaks Streamable HTTP can connect.

The server is not Claude-specific. Any MCP-capable client running locally — an editor extension, a CLI agent, your own script built on an MCP SDK — can connect using the same parameters. There is no API key or token to configure: the loopback binding and Origin validation are the security boundary, so anything already running on your Mac is already trusted.

URL
http://127.0.0.1:47821/mcp (or your configured port)
Transport
Streamable HTTP — usually written as http or streamable-http in client configs
Method
POST. GET and DELETE return 405; the transport is stateless
Authentication
None
Origin header
Omit it, or send one that resolves to loopback. Anything else is rejected with 403

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.

Functions

list_functions
Lists every Lambda function in the local LogStitch database, with runtime, memory, and invocation counts. Usually the first call an assistant makes, to discover what it can ask about.
profile_name skip_live
skip_live (default false) skips the CloudWatch live-metrics fetch and returns local-only counts.
get_invocations
Returns recent invocations for a function with status, duration, and memory usage.
function_name status since limit profile_name
status filters to success, error, timeout, or throttled. since is an ISO 8601 datetime. limit defaults to 50, max 500.
get_invocation_logs
Returns every log line for one invocation, looked up by request ID — the stitched view, as a single coherent block.
request_id function_name
function_name disambiguates if the same request ID appears under more than one function.
get_function_stats
Aggregated performance and cost statistics for a function — p50/p95/p99 duration and error rate over a rolling window.
function_name days profile_name
days defaults to 7, max 90.

Errors & Anomalies

get_errors
Returns error and timeout invocations for a function, including stack traces, for root cause analysis.
function_name error_type since limit profile_name
error_type filters by classification, e.g. TypeError or TimeoutError. limit defaults to 50, max 500.
get_anomalies
Surfaces statistical performance anomalies — duration spikes, memory surges, and error bursts — detected by z-score analysis.
profile_name function_name include_auto_resolved
Scopes to one function or across a whole profile. include_auto_resolved (default false) also returns anomalies that have since settled below 1.5σ.

Performance

get_cold_start_analysis
Cold start frequency and impact for a function: init durations, and the runtime and memory combinations driving them.
function_name window profile_name
window accepts 1h, 6h, 24h, 7d (default), or 30d.
get_memory_analysis
Memory allocated versus peak memory actually used, with right-sizing recommendations.
function_name window profile_name
Same window values as above.

Cost

get_cost_summary
Estimated Lambda cost distributed across every function in a profile, over a time window.
profile_name window
get_cost_optimization
Scans every function in a profile for cost reduction opportunities based on memory allocation and duration.
profile_name window include_dismissed
include_dismissed (default false) also returns opportunities you have already dismissed in the app.
get_cost_projection
Projects the next 30 days of Lambda cost using linear regression over recent daily spend.
profile_name

Patterns

list_patterns
Lists detected error, timeout, and throttle patterns for a function, with filtering, sorting, and pagination.
function_name pattern_type has_linked_issues include_suppressed sort_by since limit offset profile_name
pattern_type is error, timeout, or throttled. sort_by accepts occurrence_count (default), invocation_count, last_seen_at, or first_seen_at, always descending. include_suppressed defaults to true.
search_patterns
Searches patterns across all functions by substring against the pattern's canonical template, case-insensitive.
query limit profile_name
limit defaults to 50, max 500.
get_patterns_summary
A pattern health overview: total counts, breakdown by type and severity, and the highest-impact patterns.
function_name profile_name
Both optional — omit function_name to summarize across every function.
get_pattern_detail
Full detail for one pattern: metadata, representative log examples, and any linked issue tracker tickets.
pattern_id
pattern_id comes from list_patterns or search_patterns.
get_pattern_affected_invocations
A paginated list of every invocation containing instances of a given pattern.
pattern_id limit offset
limit defaults to 50, max 500.
get_pattern_trend
Time-bucketed occurrence counts for a pattern, for spotting regressions or confirming a fix landed.
pattern_id window
window accepts 1h, 6h, 24h (default), 7d, or 30d.
run_pattern_detection
Runs pattern clustering for a function when new error log lines have arrived, and returns the resulting pattern count.
function_name force dry_run deadline_seconds profile_name
force re-clusters even when the cache is fresh. dry_run reports freshness without running anything. deadline_seconds defaults to 60, clamped to 5–300. Runs entirely locally — no AWS calls.

Search & Correlation

search_logs
Full-text search across every cached log line, using SQLite FTS5 syntax — AND, OR, NOT, "exact phrase", and prefix*.
query function_name since limit profile_name
limit defaults to 20, max 100. Results carry the function, request ID, timestamp, and status of the invocation each line belongs to.
get_correlated_invocations
Finds every invocation sharing a correlation ID or an AWS X-Ray trace ID — the cross-function view of one request.
correlation_id xray_trace_id
At least one of the two is required. If both are supplied, correlation_id wins.

Sync

sync_function
Triggers a fresh CloudWatch Logs fetch for a function, so an assistant can pull data newer than what is cached.
function_name timeout_seconds profile_name
The only tool that reaches AWS. Requires Allow MCP-triggered syncs to be enabled in settings; otherwise it refuses. timeout_seconds defaults to 300, range 10–900.

Example workflows

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

Why did request 7f3a9c2e-4b81-4f6a-9d3e-1c8f5a2b7e40 fail?
Claude pulls the complete stitched log for that one invocation — every line from START to REPORT, in order, including the stack trace — and reads it as a single narrative rather than a scattered stream.
get_invocation_logs
Summarize the error patterns in checkout-service over the last 24 hours.
Rather than reading thousands of lines, Claude asks for the clustered view: which distinct failure modes exist, how often each fired, and which ones are already linked to a ticket. It can then drill into any one of them.
get_patterns_summarylist_patternsget_pattern_detail
Which invocations exceeded 5 seconds yesterday, and where did the time go?
Claude pulls yesterday's invocations with their durations, establishes what normal looks like from the percentile stats, then checks whether cold starts explain the slow tail.
get_invocationsget_function_statsget_cold_start_analysis
Compare this failed invocation to a successful one.
Claude fetches a recent success alongside the failure and diffs the two stitched logs — which is usually how you find the input that broke, or the downstream call that never returned.
get_invocationsget_invocation_logs
Trace this request across every function it touched.
Given a correlation ID or X-Ray trace ID, Claude assembles the whole distributed path — every Lambda the request passed through — then reads the logs for whichever hop looks wrong.
get_correlated_invocationsget_invocation_logs
Where is my Lambda spend going, and what should I resize?
Claude breaks spend down by function, pulls the concrete optimization opportunities, and checks memory headroom before recommending a change — so the advice is grounded in your actual allocation-versus-usage numbers.
get_cost_summaryget_cost_optimizationget_memory_analysis
Tip
Name the function in your prompt when you know it. Most tools take function_name as a required parameter, so naming it saves your assistant a list_functions round trip.

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 Claude Integration 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. 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.

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

Does my log data leave my Mac?

No. The MCP server binds only to the loopback interface (127.0.0.1) and accepts connections only from processes already running on your Mac. Every tool reads from the local SQLite database LogStitch has already populated. The server makes no outbound network requests and transmits no data off your device.

Does the AI get my AWS credentials?

No. Your AWS credentials stay in the macOS Keychain and are used only by LogStitch itself when it fetches logs from CloudWatch. The AI assistant never sees them, never receives them, and never talks to AWS. It talks only to LogStitch over localhost, and LogStitch answers from data it has already downloaded.

Does this work with Claude Desktop?

No. Claude Desktop's custom connectors are routed through Anthropic's servers rather than run on your machine, so they cannot reach a server bound to your Mac's loopback interface. Use Claude Code, which runs locally and connects directly.

Does it work with MCP clients other than Claude?

Yes. Any MCP client running on the same Mac that speaks the Streamable HTTP transport can connect. Point it at http://127.0.0.1:47821/mcp with transport type http. There is no API key or token to configure — the loopback binding and Origin validation are the security boundary.

Is the MCP server available during the free trial?

Yes. The 14-day trial grants full access to every feature, including the MCP server. There is no separate license check on the MCP server or on any of its tools.

Does the MCP server cost extra?

No. The MCP server is part of LogStitch and is covered by the same one-time purchase as the rest of the app. There is no subscription, no per-seat AI add-on, and no usage metering — the server runs on your Mac against your own database.

Related

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

All documentation → Getting Started → LogStitch vs Datadog → vs CloudWatch Logs Insights → Support → Privacy policy — MCP →