How to connect Bugsnag MCP with Codex

Get more details for a specific build by its ID **Toolset:** Releases **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - buildId (string) *required*: Unique identifier of the app build **Output Description:** JSON object containing build details along with stability metrics such as user and session stability, and whether it meets project targets **Use Cases:** 1. View build metadata such as version, source control info, and error counts 2. Analyze a specific build to correlate with error spikes or deployments 3. See the stability targets for a project and if the build meets them **Examples:** 1. Get details for a specific build ```json { "buildId": "5f8d0d55c9e77c0017a1b2c3" } ``` Expected Output: JSON object with build details including version, source control info, error counts and stability data. **Hints:** 1. Build IDs can be found using the List builds tool

Retrieve the 'current' project on which tools should operate by default. This allows BugSnag tools to be called with no projectId parameter. **Toolset:** Projects **Parameters:** None **Use Cases:** 1. Understand if a current project has been set **Hints:** 1. If a project is returned, it can be assumed that the user expects interactions with BugSnag tools to refer to this project 2. If this tool returns no current project then other BugSnag tools will require an explicit project ID parameter 3. Call the List Projects tool to see all projects that the user has access to. Get the project ID from this list either by asking the user for the project name or slug 4. You might find a BugSnag API key in the user's code where they configure the BugSnag SDK that can be matched to a project 'apiKey' field from the project list

Get full details on an error, including aggregated and summarized data across all events (occurrences) and details of the latest event (occurrence), such as breadcrumbs, metadata and the stacktrace. Use the filters parameter to narrow down the summaries further. **Toolset:** Errors **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - errorId (string) *required*: Unique identifier of the error to retrieve - filters (record<string, array>): Apply filters to narrow down the error list. Use the List Project Event Filters tool to discover available filter fields. Time filters support extended ISO 8601 format (e.g. 2018-05-20T00:00:00Z) or relative format (e.g. 7d, 24h). (default: {"event.since":[{"type":"eq","value":"30d"}],"error.status":[{"type":"eq","value":"open"}]}) **Output Description:** JSON object containing: - error_details: Aggregated data about the error, including first and last seen occurrence - latest_event: Detailed information about the most recent occurrence of the error, including stacktrace, breadcrumbs, user and context - pivots: List of pivots (summaries) for the error, which can be used to analyze patterns in occurrences - url: A link to the error in the dashboard - this should be shown to the user for them to perform further analysis **Use Cases:** 1. Investigate a specific error found through the List Project Errors tool 2. Understand which types of user are affected by the error using summarized event data 3. Get error details for debugging and root cause analysis 4. Retrieve error metadata for incident reports and documentation **Examples:** 1. Get details for a specific error ```json { "errorId": "6863e2af8c857c0a5023b411" } ``` Expected Output: JSON object with error details including message, stack trace, occurrence count, and metadata **Hints:** 1. Error IDs can be found using the List Project Errors tool 2. Use this after filtering errors to get detailed information about specific errors 3. Use Get Event Details tool if you need detailed information about a specific event (occurrence) rather than the aggregated error 4. If you used a filter to get this error, you can pass the same filters here to restrict the results or apply further filters 5. The URL provided in the response points should be shown to the user in all cases as it allows them to view the error in the dashboard and perform further analysis

Get detailed information about a specific event **Toolset:** Events **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - eventId (string) *required*: Unique identifier of the event **Use Cases:** 1. Get the full details of an event, including any thread stack traces **Examples:** 1. Get event details of an event ```json { "eventId": "6863e2af012caf1d5c320000" } ``` Expected Output: JSON object with complete event details including stack trace (error trace and other threads, if present), metadata, and context

Get detailed information about a specific event using its dashboard URL **Toolset:** Events **Parameters:** - link (string) *required*: Full URL to the event details page in the BugSnag dashboard (web interface), containing project slug and event_id parameter. **Use Cases:** 1. Get event details when given a dashboard URL from a user or notification 2. Extract event information from shared links or browser URLs 3. Quick lookup of event details without needing separate project and event IDs **Examples:** 1. Get event details from a dashboard URL ```json { "link": "https://app.bugsnag.com/my-org/my-project/errors/6863e2af8c857c0a5023b411?event_id=6863e2af012caf1d5c320000" } ``` Expected Output: JSON object with complete event details including stack trace, metadata, and context **Hints:** 1. The URL must contain both project slug in the path and event_id in query parameters 2. This is useful when users share BugSnag dashboard URLs and you need to extract the event data

Gets a list of events that have grouped into the specified error **Toolset:** Events **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - errorId (string) *required*: Unique identifier of the error - filters (record<string, array>): Apply filters to narrow down the event list. Use the List Project Event Filters tool to discover available filter fields. Time filters support extended ISO 8601 format (e.g. 2018-05-20T00:00:00Z) or relative format (e.g. 7d, 24h). (default: {"event.since":[{"type":"eq","value":"30d"}],"error.status":[{"type":"eq","value":"open"}]}) - direction (enum): Sort direction for ordering results (default: "desc") - perPage (number): How many results to return per page. (default: 30) - nextUrl (string): URL for retrieving the next page of results. Use the value in the previous response to get the next page when more results are available. Only values provided in the output from this tool can be used. Do not attempt to construct it manually. **Use Cases:** 1. Retrieving all the events for comparison to find commonalities or differences in stack traces, breadcrumbs and metadata **Examples:** 1. Get events of an error ```json { "projectId": "1234567890abcdef12345678", "errorId": "6863e2af012caf1d5c320000" } ``` Expected Output: A list of events, ordered by timestamp, with complete details including stack trace, breadcrumbs, metadata, and context

Get the network endpoint grouping rules for a project **Toolset:** Performance **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. **Use Cases:** 1. View current network endpoint grouping configuration 2. Understand how network requests are being grouped in performance monitoring 3. Check grouping patterns before making updates **Examples:** 1. Get network grouping rules for a project ```json {} ``` Expected Output: Array of endpoint URL patterns **Hints:** 1. Network grouping patterns help consolidate similar requests into single span groups 2. Patterns use OpenAPI path templating syntax with curly braces for path parameters (e.g., /users/{userId}) 3. Wildcards (*) can be used in domains to match multiple subdomains (e.g., https://*.example.com)

Get more details for a specific release by its ID, including source control information and associated builds **Toolset:** Releases **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - releaseId (string) *required*: Unique identifier of the app release **Output Description:** JSON object containing release details along with stability metrics such as user and session stability, and whether it meets project targets **Use Cases:** 1. View release metadata such as version, source control info, and error counts 2. Analyze the stability data and targets for a release 3. See the builds that make up the release **Examples:** 1. Get details for a specific release ```json { "releaseId": "5f8d0d55c9e77c0017a1b2c3" } ``` Expected Output: JSON object with release details including version, source control info, error counts and stability data. **Hints:** 1. Release IDs can be found using the List releases tool

Get detailed performance metrics for a specific span group **Toolset:** Performance **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - spanGroupId (string) *required*: ID of the span group - filters (record<string, array>): Apply filters to narrow down the span group list. Use the List Trace Fields tool to discover available filter fields. Time filters support extended ISO 8601 format (e.g. 2018-05-20T00:00:00Z) or relative format (e.g. 7d, 24h). (default: {"span.since":[{"type":"eq","value":"7d"}]}) **Use Cases:** 1. View detailed statistics (p50, p75, p90, p95, p99) for an operation 2. Check if performance targets are configured 3. Monitor span count to understand operation volume **Examples:** 1. Get details for an API endpoint span group ```json { "spanGroupId": "[HttpClient]GET-api.example.com" } ``` Expected Output: Statistics, category, and performance target info 2. Get span group details with device filtering ```json { "spanGroupId": "[HttpClient]GET-api.example.com", "filters": { "device.browser_name": [ { "type": "eq", "value": "Chrome" } ] } } ``` Expected Output: Statistics filtered for Chrome browser only **Hints:** 1. Use List Span Groups first to discover available span group IDs 2. IDs are automatically URL-encoded - provide the raw ID 3. Statistics include p50, p75, p90, p95, p99 percentiles

Get all spans within a specific trace **Toolset:** Performance **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - traceId (string) *required*: Trace ID - from (string) *required*: Start time (ISO 8601 format) - to (string) *required*: End time (ISO 8601 format) - targetSpanId (string): Optional target span ID to focus on - perPage (number): How many results to return per page. (default: 30) - nextUrl (string): URL for retrieving the next page of results. Use the value in the previous response to get the next page when more results are available. Only values provided in the output from this tool can be used. Do not attempt to construct it manually. **Use Cases:** 1. Debug slow requests by viewing all operations in the trace 2. Understand the flow of a request through the system 3. Identify bottlenecks in distributed systems **Examples:** 1. Get all spans for a trace ```json { "traceId": "abc123", "from": "2024-01-01T00:00:00Z", "to": "2024-01-01T23:59:59Z" } ``` Expected Output: Array of all spans in the trace with timing and hierarchy 2. Get spans for a trace with pagination and target span ```json { "traceId": "def456", "from": "2024-01-01T00:00:00Z", "to": "2024-01-01T23:59:59Z", "targetSpanId": "span-789", "perPage": 50 } ``` Expected Output: Array of up to 50 spans focused around the target span **Hints:** 1. Traces show the complete execution path of a request 2. Use from/to parameters to narrow the time window 3. targetSpanId can be used to focus on a specific span in the trace

List and search errors in a project using customizable filters and pagination **Toolset:** Errors **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - filters (record<string, array>): Apply filters to narrow down the error list. Use the List Project Event Filters tool to discover available filter fields. Time filters support extended ISO 8601 format (e.g. 2018-05-20T00:00:00Z) or relative format (e.g. 7d, 24h). (default: {"event.since":[{"type":"eq","value":"30d"}],"error.status":[{"type":"eq","value":"open"}]}) - sort (enum): Field to sort the errors by (default: "last_seen") - direction (enum): Sort direction for ordering results (default: "desc") - perPage (number): How many results to return per page. (default: 30) - nextUrl (string): URL for retrieving the next page of results. Use the value in the previous response to get the next page when more results are available. Only values provided in the output from this tool can be used. Do not attempt to construct it manually. **Use Cases:** 1. Debug recent application errors by filtering for open errors in the last 7 days 2. Generate error reports for stakeholders by filtering specific error types or severity levels 3. Monitor error trends over time using date range filters 4. Find errors affecting specific users or environments using metadata filters **Examples:** 1. Find errors affecting a specific user in the last 24 hours ```json { "filters": { "user.email": [ { "type": "eq", "value": "user@example.com" } ], "event.since": [ { "type": "eq", "value": "24h" } ] } } ``` Expected Output: JSON object with a list of errors in the 'data' field, a count of the current page of results in the 'count' field, and a total count of all results in the 'total' field 2. Get the 10 open errors with the most users affected in the last 30 days ```json { "filters": { "event.since": [ { "type": "eq", "value": "30d" } ], "error.status": [ { "type": "eq", "value": "open" } ] }, "sort": "users", "direction": "desc", "perPage": 10 } ``` Expected Output: JSON object with a list of errors in the 'data' field, a count of the current page of results in the 'count' field, and a total count of all results in the 'total' field 3. Get the next 50 results ```json { "nextUrl": "https://api.bugsnag.com/projects/515fb9337c1074f6fd000003/errors?base=2025-08-29T13%3A11%3A37Z&direction=desc&filters%5Berror.status%5D%5B%5D%5Btype%5D=eq&filters%5Berror.status%5D%5B%5D%5Bvalue%5D=open&offset=10&per_page=10&sort=users", "perPage": 50 } ``` Expected Output: JSON object with a list of errors, with a URL to the next page if more results are available and a total count of all errors matched **Hints:** 1. Use List Project Event Filters tool first to discover valid filter field names for your project 2. Combine multiple filters to narrow results - filters are applied with AND logic 3. For time filters: use relative format (7d, 24h) for recent periods or ISO 8601 UTC format (2018-05-20T00:00:00Z) for specific dates 4. Common time filters: event.since (from this time), event.before (until this time) 5. The 'event.since' filter and 'error.status' filters are always applied and if not specified are set to '30d' and 'open' respectively 6. There may not be any errors matching the filters - this is not a problem with the tool, in fact it might be a good thing that the user's application had no errors 7. This tool returns paged results. The 'page_error_count' field indicates the number of results returned in the current page, and the 'total_error_count' field indicates the total number of results across all pages. 8. If the output contains a 'next_url' value, there are more results available - call this tool again supplying the next URL as a parameter to retrieve the next page. 9. Do not modify the next URL as this can cause incorrect results. The only other parameter that can be used with 'next' is 'per_page' to control the page size.

Get available event filter fields for a project **Toolset:** Projects **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. **Use Cases:** 1. Discover what filter fields are available before searching for errors 2. Find the correct field names for filtering by user, environment, or custom metadata 3. Understand filter options and data types for building complex queries **Examples:** 1. Get all available filter fields ```json {} ``` Expected Output: JSON array of EventField objects containing display_id, custom flag, and filter/pivot options **Hints:** 1. Use this tool before the List Errors or Get Error tools to understand available filters 2. Look for display_id field in the response - these are the field names to use in filters

List all projects in the organization that the current user has access to, or find a project matching an API key. **Toolset:** Projects **Parameters:** - apiKey (string): The API key of the BugSnag project, if known. **Use Cases:** 1. Get an overview of all projects in the organization 2. Locate a project by its API key if known from the user's code **Hints:** 1. Project IDs from this list can be used with other tools when no project API key is configured

List releases for a project **Toolset:** Releases **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - releaseStage (string): Filter releases by this stage (e.g. production, staging), defaults to 'production' (default: "production") - visibleOnly (boolean): Whether to only include releases that are marked as visible in the dashboard (default: false) - perPage (number): How many results to return per page. (default: 30) - nextUrl (string): URL for retrieving the next page of results. Use the value in the previous response to get the next page when more results are available. Only values provided in the output from this tool can be used. Do not attempt to construct it manually. **Output Description:** JSON array of release summary objects with metadata, with a URL to the next page if more results are available **Use Cases:** 1. View recent releases to correlate with error spikes 2. Filter releases by stage (e.g. production, staging) for targeted analysis **Examples:** 1. List production releases for a project ```json {} ``` Expected Output: JSON array of release objects in the production stage 2. List staging releases for a project ```json { "releaseStage": "staging" } ``` Expected Output: JSON array of release objects in the staging stage 3. Get the next page of results ```json { "nextUrl": "/projects/515fb9337c1074f6fd000003/releases?offset=30&per_page=30" } ``` Expected Output: JSON array of release objects with metadata from the next page **Hints:** 1. Use the Get Release tool to get more details on a specific release, including the builds it contains 2. The release stage defaults to 'production' if not specified 3. Use visibleOnly to filter out releases that have been marked as hidden in the dashboard

List span groups (operations) tracked for performance monitoring **Toolset:** Performance **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - sort (enum): Field to sort by - direction (enum): Sort direction for ordering results (default: "desc") - perPage (number): How many results to return per page. (default: 30) - starredOnly (boolean): Show only starred span groups - nextUrl (string): URL for retrieving the next page of results. Use the value in the previous response to get the next page when more results are available. Only values provided in the output from this tool can be used. Do not attempt to construct it manually. - filters (record<string, array>): Apply filters to narrow down the span group list. Use the List Trace Fields tool to discover available filter fields. Time filters support extended ISO 8601 format (e.g. 2018-05-20T00:00:00Z) or relative format (e.g. 7d, 24h). (default: {"span.since":[{"type":"eq","value":"7d"}]}) **Use Cases:** 1. View all operations being tracked for performance 2. Find slow operations by sorting by duration metrics 3. Filter to starred/important span groups **Examples:** 1. List slowest operations ```json { "sort": "duration_p95", "direction": "desc", "perPage": 10 } ``` Expected Output: Array of span groups sorted by 95th percentile duration 2. List starred span groups with filtering ```json { "starredOnly": true, "filters": { "span_group.category": [ { "type": "eq", "value": "full_page_load" } ] } } ``` Expected Output: Array of starred span groups filtered by category **Hints:** 1. Span groups represent different operation types (page loads, API calls, etc.) 2. Use sort by duration_p95 or duration_p99 to find the slowest operations 3. Star important span groups for quick access 4. Use nextUrl for pagination

Get individual spans belonging to a span group **Toolset:** Performance **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - spanGroupId (string) *required*: ID of the span group - sort (enum): Field to sort by - direction (enum): Sort direction for ordering results (default: "desc") - perPage (number): How many results to return per page. (default: 30) - nextUrl (string): URL for retrieving the next page of results. Use the value in the previous response to get the next page when more results are available. Only values provided in the output from this tool can be used. Do not attempt to construct it manually. - filters (record<string, array>): Apply filters to narrow down the span group list. Use the List Trace Fields tool to discover available filter fields. Time filters support extended ISO 8601 format (e.g. 2018-05-20T00:00:00Z) or relative format (e.g. 7d, 24h). (default: {"span.since":[{"type":"eq","value":"7d"}]}) **Use Cases:** 1. Analyze individual slow operations 2. Debug performance issues by examining specific traces 3. Find patterns in operation attributes **Examples:** 1. Get slowest spans for an operation ```json { "spanGroupId": "[HttpClient]GET-api.example.com", "sort": "duration", "direction": "desc", "perPage": 10 } ``` Expected Output: Array of the 10 slowest span instances 2. Get spans filtered by OS with pagination ```json { "spanGroupId": "[HttpClient]GET-api.example.com", "sort": "timestamp", "filters": { "os.name": [ { "type": "eq", "value": "iOS" } ] }, "nextUrl": "/projects/123/spans?offset=30&per_page=30" } ``` Expected Output: Array of spans from iOS devices with next page navigation **Hints:** 1. Sort by duration descending to find the slowest instances 2. Each span includes trace ID for further investigation

Get available trace fields/attributes for filtering **Toolset:** Performance **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. **Use Cases:** 1. Find available custom attributes for performance filtering 2. Understand what metadata is attached to traces 3. Build dynamic filters based on available fields **Examples:** 1. Get all trace fields ```json {} ``` Expected Output: Array of field names and types available for filtering **Hints:** 1. Trace fields are custom attributes added to spans 2. Use these fields for filtering other performance queries

Set the network endpoint grouping rules for a project **Toolset:** Performance **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - endpoints (array) *required*: Array of URL patterns by which network spans are grouped. Endpoints follow OpenAPI path templating syntax (https://swagger.io/specification/#path-templating) where path parameters use curly braces (e.g., /users/{id}). If you encounter colon-prefixed parameters (e.g., :userId from Express/React Router), convert them to curly braces (e.g., {userId}). Wildcards (*) can be used in domains (e.g., https://*.example.com) to match multiple subdomains. **Use Cases:** 1. Consolidate similar API endpoints into single span groups 2. Group dynamic URLs using path parameters (e.g., /api/users/{userId} groups /api/users/123, /api/users/456) 3. Match multiple subdomains using wildcards (e.g., https://*.example.com groups api.example.com, cdn.example.com) 4. Simplify performance monitoring by reducing span group clutter **Examples:** 1. Group API endpoints with path parameters ```json { "endpoints": [ "/api/users/{userId}", "/api/products/{productId}", "/api/orders/{orderId}/items/{itemId}" ] } ``` Expected Output: Success response confirming the update 2. Group endpoints with domain wildcards and path parameters ```json { "endpoints": [ "https://*.example.com/api/v1/{resourceId}", "https://api.example.com/v2/users/{userId}", "/graphql" ] } ``` Expected Output: Success response confirming the update 3. Convert colon-prefixed parameters to curly braces (e.g., from Express/React Router) ```json { "endpoints": [ "/{organizationSlug}/{projectSlug}/performance/view-load", "/api/{version}/items/{itemId}" ] } ``` Expected Output: Success response confirming the update **Hints:** 1. Use Get Network Grouping first to see current patterns 2. Use OpenAPI path templating with curly braces for path parameters: /users/{userId}, /orders/{orderId}/items/{itemId} 3. Convert colon-prefixed parameters to curly braces: :organizationSlug becomes {organizationSlug}, :projectSlug becomes {projectSlug} 4. Wildcards (*) can be used in domains to match subdomains: https://*.example.com/api 5. This replaces all existing patterns - include all patterns you want to keep 6. Well-designed patterns reduce noise in performance monitoring

Update the status of an error **Toolset:** Errors **Parameters:** - projectId (string): Unique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools. - errorId (string) *required*: Unique identifier of the error - operation (enum) *required*: The operation to apply to the error - issue_url (string): The URL of the issue to link to the error - required when operation is 'link_issue' - reopenRules (object): Reopen rules for snooze operation - required when operation is 'snooze' **Use Cases:** 1. Mark an error as open, fixed or ignored 2. Discard or un-discard an error 3. Update the severity of an error 4. Snooze an error with defined conditions for when it should be reopened **Examples:** 1. Mark an error as fixed ```json { "errorId": "6863e2af8c857c0a5023b411", "operation": "fix" } ``` Expected Output: Success response indicating the error was marked as fixed 2. Snooze an error for 1 hour ```json { "errorId": "6863e2af8c857c0a5023b411", "operation": "snooze", "reopenRules": { "reopenIf": "occurs_after", "seconds": 3600 } } ``` Expected Output: Success response indicating the error was snoozed for 1 hour 3. Snooze an error until 5 additional users are affected ```json { "errorId": "6863e2af8c857c0a5023b411", "operation": "snooze", "reopenRules": { "reopenIf": "n_additional_users", "additionalUsers": 5 } } ``` Expected Output: Success response indicating the error was snoozed until 5 additional users are affected 4. Snooze an error until 10 occurrences in 24 hours ```json { "errorId": "6863e2af8c857c0a5023b411", "operation": "snooze", "reopenRules": { "reopenIf": "n_occurrences_in_m_hours", "occurrences": 10, "hours": 24 } } ``` Expected Output: Success response indicating the error was snoozed until 10 occurrences in 24 hours 5. Link a Jira issue to an error ```json { "errorId": "6863e2af8c857c0a5023b411", "operation": "link_issue", "issue_url": "https://smartbear.atlassian.net/browse/PIPE-9547" } ``` Expected Output: Success response indicating the Jira issue was linked to the error 6. Unlink a Jira issue from an error ```json { "errorId": "6863e2af8c857c0a5023b411", "operation": "unlink_issue" } ``` Expected Output: Success response indicating the Jira issue was unlinked from the error **Hints:** 1. Only use valid operations - BugSnag may reject invalid values 2. When using 'snooze' operation, reopenRules parameter is required 3. When using 'link_issue' operation, issue_url parameter is required 4. Use 'unlink_issue' to remove the link between an error and its issue 5. For 'occurs_after' reopen rules, specify 'seconds' parameter 6. For 'n_additional_users' reopen rules, specify 'additionalUsers' parameter (max 100,000) 7. For 'n_occurrences_in_m_hours' reopen rules, specify both 'occurrences' and 'hours' parameters 8. For 'n_additional_occurrences' reopen rules, specify 'additionalOccurrences' parameter 9. Snoozing temporarily silences an error until the specified reopen condition is met