There is a moment every developer knows. You’re deep in a debugging session. You have a hypothesis. You need to check the logs. So you open a new tab, navigate to your monitoring dashboard, type a query, wait for results, copy an error message, switch back to your editor, and try to pick up where you left off.

That context switch — multiplied across every debugging session, every incident, every “let me just check the logs” — is quietly expensive.

Today we’re shipping something that removes it entirely.

ScryWatch as an MCP Server

ScryWatch now includes a built-in Model Context Protocol (MCP) server. MCP is the open standard that lets AI assistants call external tools — and ScryWatch is now one of those tools.

If you use Claude Code, Claude Desktop, Cursor, Windsurf, or any MCP-compatible client, you can connect it to your ScryWatch project and query your production logs with natural language.

No dashboard. No tab switching. No query syntax to remember.

What this looks like in practice

You’re debugging a payment failure in your editor. You ask Claude:

“Search for error logs from the payment service in the last hour”

Claude calls ScryWatch’s search_logs tool behind the scenes and returns:

Found 23 errors. The most common is “Connection refused to db-primary:5432” (first seen 45 minutes ago). There’s an active alert rule for error spikes — it fired 40 minutes ago.

You follow up:

“What are the top patterns right now?”

Claude calls get_log_patterns and gives you a ranked list of recurring log signatures with counts and first-seen times.

All of this happens inline, in your editor, in the same conversation where you’re writing the fix.

Eight Read-Only Tools

The MCP server exposes eight tools that cover the core debugging workflow:

search_logs — Full-text search with level, service, environment, and time range filters
get_log — Fetch a single event by ID with complete metadata
get_log_stats — Aggregate counts by level, type, and hour
get_log_facets — Distribution of values across log fields
get_log_patterns — Recurring log patterns ranked by frequency
list_alerts — Alert rules configured for the project
get_alert_history — Recent alert firings with timestamps
list_sessions — User sessions with event counts and severity breakdowns

All tools are read-only. The MCP server cannot modify your data, create events, or change configuration.

Setup in 60 Seconds

Grab a project API key from Settings > API Keys in your ScryWatch dashboard.
Add this to your MCP client’s configuration:

{
  "mcpServers": {
    "scrywatch": {
      "type": "http",
      "url": "https://api.scrywatch.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

Restart your client. Done.

Works with Claude Code (.mcp.json in your project root), Claude Desktop (Settings > Developer > MCP Servers), Cursor (Settings > MCP), and any client that supports the MCP 2024-11-05 HTTP transport.

Why MCP and Not a ChatGPT Plugin or Custom Integration?

MCP is an open protocol. It’s not locked to one vendor or one AI model. The same ScryWatch MCP configuration works across Claude, Cursor, Windsurf, and any future tool that adopts the standard. You configure it once and it works everywhere.

It’s also stateless and simple. Each request is a JSON-RPC 2.0 call authenticated with your existing API key. No OAuth flows, no webhook registration, no separate app to install.

Security Model

A fair question: should AI assistants have access to production logs?

Our answer is: yes, with the right constraints.

Read-only. The MCP server exposes only SELECT queries. No writes, deletes, or mutations of any kind.
Project-scoped. Your API key is tied to one project. The server cannot access other projects or organizations, even if the AI asks.
Standard auth. Same requireApiKey middleware as the ingest endpoint. Keys are hashed, lookups are timing-safe.
Revocable. Create a dedicated key for MCP. Revoke it anytime without touching your ingest pipeline.
No data stored. Queries run on Cloudflare Workers. Log data goes from your D1 database to the MCP client and nowhere else.

If you wouldn’t give a developer read access to your logs, don’t give them an MCP key. If you would — this is just a faster way to use that access.

What This Enables

The immediate value is faster debugging. But the more interesting use case is AI-assisted incident response.

When an alert fires, your AI assistant can immediately pull context: recent errors, pattern frequency changes, affected services. It can correlate what it sees in your code with what’s happening in production. It can suggest a fix based on the actual error, not a guess.

This is the beginning of a workflow where the gap between “something broke” and “here’s the fix” gets meaningfully shorter.

Try It

If you already have a ScryWatch project, you can set this up right now. The MCP server is live at https://api.scrywatch.com/mcp.

If you’re new to ScryWatch, start free — it takes about five minutes to go from zero to logs in your AI assistant.

Full setup instructions: MCP Server Guide

Query Your Production Logs from Claude, Cursor, and Windsurf