|
| 1 | +--- |
| 2 | +title: Errors |
| 3 | +--- |
| 4 | + |
| 5 | +MCP Server error instrumentation ensures that all errors occurring within the Model Context Protocol (MCP) server are captured and reported to Sentry, **without ever interfering with the operation of the MCP service itself**. |
| 6 | + |
| 7 | +## Goals and Philosophy |
| 8 | + |
| 9 | +- **Comprehensive context:** Errors are always associated with the active Sentry span, so you get full context (method, tool, arguments, etc.) in Sentry. |
| 10 | +- **Categorized errors:** Errors are tagged by type (e.g., `validation`, `timeout`, `tool_execution`, `resource_operation`, `prompt_execution`, `transport`, etc.) for easy filtering and analysis in Sentry. |
| 11 | +- **Handler wrapping:** All MCP server handlers (`tool`, `resource`, `prompt`) are wrapped to ensure errors are captured and correlated with the correct request span. |
| 12 | + |
| 13 | + |
| 14 | +## Safe Error Capture |
| 15 | + |
| 16 | +The core utility is an error capture function: |
| 17 | + |
| 18 | +```ts |
| 19 | +import { getClient } from '../../currentScopes'; |
| 20 | +import { captureException } from '../../exports'; |
| 21 | + |
| 22 | +export function captureError(error: Error, errorType?: string): void { |
| 23 | + try { |
| 24 | + const client = getClient(); |
| 25 | + if (!client) return; |
| 26 | + captureException(error, { |
| 27 | + tags: { |
| 28 | + mcp_error_type: errorType || 'handler_execution', |
| 29 | + }, |
| 30 | + }); |
| 31 | + } catch { |
| 32 | + // Silently ignore capture errors - never affect MCP operation |
| 33 | + } |
| 34 | +} |
| 35 | +``` |
| 36 | + |
| 37 | +- **Never throws:** All error capture is wrapped in a try/catch and will never throw. |
| 38 | +- **Tags errors:** Errors are tagged with `mcp_error_type` for later filtering. |
| 39 | + |
| 40 | +## Handler Wrapping for Error Capture |
| 41 | + |
| 42 | +All MCP server method handlers (`tool`, `resource`, `prompt`) are wrapped to: |
| 43 | +- Correlate handler execution with the correct Sentry span (using request/session data) |
| 44 | +- Capture both synchronous and asynchronous errors |
| 45 | +- Categorize errors by handler type and error nature |
| 46 | + |
| 47 | +### Error Categorization |
| 48 | + |
| 49 | +Errors are categorized and tagged based on the handler and error type: |
| 50 | + |
| 51 | +- **Tool handler errors:** |
| 52 | + - `validation` (e.g., protocol/validation errors) |
| 53 | + - `timeout` (e.g., server timeouts) |
| 54 | + - `tool_execution` (all other tool errors) |
| 55 | +- **Resource handler errors:** |
| 56 | + - `resource_operation` |
| 57 | +- **Prompt handler errors:** |
| 58 | + - `prompt_execution` |
| 59 | +- **Transport errors:** |
| 60 | + - `transport` |
| 61 | +- **Protocol errors:** |
| 62 | + - `protocol` |
| 63 | + |
| 64 | +## Span Correlation |
| 65 | + |
| 66 | +All errors are captured within the context of the active Sentry span, so you can: |
| 67 | +- See which MCP method, tool, or resource caused the error |
| 68 | +- View all arguments and context for the failed request |
| 69 | +- Correlate errors with traces and performance data |
| 70 | + |
| 71 | +## Transport Layer Error Instrumentation |
| 72 | + |
| 73 | +The MCP transport layer is also instrumented to: |
| 74 | +- Create spans for incoming/outgoing messages |
| 75 | +- Capture errors in transport event handlers (e.g., `onerror`) |
| 76 | +- Correlate protocol errors with the correct request/response |
0 commit comments