Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

BugSnag: Update Error

bugsnag_update_error

Update a BugSnag error's status: mark it as fixed, open, ignored, discarded, snoozed, or link/unlink an issue.

Instructions

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

{
  "errorId": "6863e2af8c857c0a5023b411",
  "operation": "fix"
}

Expected Output: Success response indicating the error was marked as fixed

  1. Snooze an error for 1 hour

{
  "errorId": "6863e2af8c857c0a5023b411",
  "operation": "snooze",
  "reopenRules": {
    "reopenIf": "occurs_after",
    "seconds": 3600
  }
}

Expected Output: Success response indicating the error was snoozed for 1 hour

  1. Snooze an error until 5 additional users are affected

{
  "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

  1. Snooze an error until 10 occurrences in 24 hours

{
  "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

  1. Link a Jira issue to an error

{
  "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

  1. Unlink a Jira issue from an error

{
  "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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorIdYesUnique identifier of the error
issue_urlNoThe URL of the issue to link to the error - required when operation is 'link_issue'
operationYesThe operation to apply to the error
projectIdNoUnique identifier of the project. This is optional if a current project is set and is used to set the current project for BugSnag tools.
reopenRulesNoReopen rules for snooze operation - required when operation is 'snooze'
Install Server

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already signal readOnlyHint=false; the description adds meaningful behavior such as 'Snoozing temporarily silences an error until the specified reopen condition is met' and warns that invalid operations may be rejected. It doesn't cover auth/rate limits, but the mutation semantics are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with a one-line summary, Use Cases, Examples, and Hints, and front-loaded purpose. The Parameters section largely duplicates the schema, adding some redundancy, but the examples and hints justify the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nested-parameter, nine-operation mutation tool with no output schema, the description is thorough: every operation is covered by an example, conditional requirements are spelled out, and expected outputs are stated. An agent has enough to construct valid calls.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3; the description pulls ahead with examples showing exact JSON payloads for every operation class and Hints that map each reopenIf variant to its required fields (seconds, additionalUsers, occurrences+hours, additionalOccurrences). This adds compositional knowledge beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Update the status of an error') and immediately enumerates exact operations in Use Cases (open/fixed/ignored, discard, severity, snooze, link issue). The tool name and BugSnag sibling set make it the clear mutation counterpart to read-only tools like bugsnag_get_error and bugsnag_list_project_errors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'Use Cases' list gives concrete scenarios (mark fixed, snooze, discard) that tell an agent when to invoke it. It does not name alternatives or state when not to use it, which would be the next step up.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SmartBear/smartbear-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server