Blog

How to Set Up an MCP Server in Cursor for Error Logs

Cursor launches MCP servers over stdio. A server that writes logs to stdout breaks the protocol. This is the setup that keeps error history on a side channel.

2026-10-23 · 3 min read · AethelLayer

What you see

Cursor shows the MCP server as failed, or the tool call never returns. The editor was talking JSON-RPC on stdin and stdout. A console.log in the server, or a probe that prints a banner, is treated as a broken message.

Root cause

The Model Context Protocol stdio transport uses stdout for protocol frames only. Diagnostic logs belong on stderr, or in a file the tools read later. If the server prompts on stdin, it also steals the frame stream. That is why an interactive "what were you trying to do?" question cannot run on the pipe.

What the server should expose

AethelLayer's MCP process reads the local error log. It does not phone home when the editor opens. Two tools are registered:

  • get_recent_errors returns the latest local failures, including exit 137 and API dropouts.
  • draft_github_ticket builds a GitHub issue URL from one of those failures. It does not call the GitHub API to create the issue.

Wire it in Cursor

Print the config from the CLI:

bashnpx --yes @aethellayer/sdk init

Put this in .cursor/mcp.json. No arguments: a non-TTY launch starts the MCP server.

json{  "mcpServers": {    "aethellayer": {      "command": "npx",      "args": ["-y", "@aethellayer/sdk"]    }  }}

Claude Desktop uses the same block. Ask the model for recent errors, then open the draft URL yourself.

Capture the failure before they leave

Install the probe. It drafts the GitHub issue. You still send it.

npx --yes @aethellayer/sdk init