Skip to content

Sentry

Configure Sentry with xmcp middleware and runnable examples.

For the complete documentation index, see llms.txt. Markdown variants of every page are available by appending .md to the URL.

Trace tool calls, prompt retrieval, and resource reads through one MCP middleware. @xmcp-dev/sentry uses your initialized Sentry Node SDK and isolates tags between concurrent operations.

src/middleware.ts

This is manual instrumentation and works in xmcp's bundled HTTP and STDIO servers. If your application already initializes Sentry, pass that same SDK instance and retain its configuration. For automatic instrumentation of other libraries, follow Sentry's initialization guidance before starting the server; do not also instrument these MCP operations with Sentry's MCP wrapper, which would produce duplicate spans.

Each execution round produces a mcp.server span with the MCP method and xmcp.outcome: success, error, cancellation, or input required. Returned isError results create a generic error event; thrown exceptions are captured with their original stack. Cancellation and intermediate input-required results do not create error events. Discovery bypasses instrumentation. Register Sentry first in the mcp array to include application middleware denials.

The middleware adds no arguments, results, request headers, user identity, or resource URIs. Original exceptions can contain sensitive messages or stack data: configure Sentry's beforeSend and application error handling to scrub those where needed. Other Sentry integrations and settings can collect additional data independently.

Telemetry failures preserve the original operation result or exception and never execute the handler again. Delivery uses the application's Sentry SDK buffer. On serverless hosts, arrange for Sentry.flush() through the platform's request-lifetime hook; on shutdown flush before exiting. The middleware does not flush the shared buffer per tool call.

See the runnable Sentry example.

One framework to rule them all