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_errorsreturns the latest local failures, including exit 137 and API dropouts.draft_github_ticketbuilds 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 initPut 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.
Keep reading
Capture the failure before they leave
Install the probe. It drafts the GitHub issue. You still send it.
npx --yes @aethellayer/sdk init