The Cursor and Claude MCP Wave

Right now, developers are obsessed with extending Cursor and Claude. The extension point is MCP: a stdio process, a short mcp.json, and a couple of tools the model can call. The install looks like a config snippet. The failure looks like a spinner.

A server that writes a log line on stdout breaks the JSON-RPC session. A server that waits for a prompt never gets a person. The developer closes the editor panel and tries the next tool. Your API status page stays green.

The published package @aethellayer/sdk is an MCP server. Cursor can launch it with no arguments, because a pipe is not a terminal. Claude Desktop can use the same block, or the mcp subcommand. The tools are get_recent_errors and draft_github_ticket.

get_recent_errors reads the local probe log, the same file aethel run writes. draft_github_ticket returns a GitHub issue URL and a body. It does not file the issue. A person still hits send.

Paste this into Cursor mcp.json or Claude's claude_desktop_config.json. Do not point it at the unscoped npx aethel package. That name is a different project.

The block is command npx, args -y and @aethellayer/sdk. No API key is required for the two local tools. A start on the AethelLayer fleet still happens only when a process runs the SDK or the CLI with an ingest key. Opening the editor does not phone home.

If your own MCP server fails during their onboarding, print one line on stderr and exit non-zero. Do not ask a question on that pipe. Capture the error code. The editor log is not your inbox.

AethelLayer's server is the other half: once a CLI or SDK failure is on disk, Cursor and Claude can read it and draft the ticket in the place the developer already is.