Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

BugSnag: Update Error

bugsnag_update_error

Change an error's status in BugSnag using operations like fix, ignore, snooze, or link 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'

Tool Definition Quality

A4.1/5.0
Behavior3/5

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

Annotations provide readOnlyHint=false and destructiveHint=false, indicating mutation but not destruction. The description adds operational details (e.g., required parameters for snooze/link_issue) but does not disclose side effects like authorization needs, rate limits, or state changes beyond the operation. This is adequate but not rich.

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?

The description is well-structured with clear sections (toolset, parameters, use cases, examples, hints). While lengthy, each part adds value. No fluff, but examples could be more concise. However, the organization aids agent understanding.

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

Completeness4/5

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

Given 5 parameters (2 required, 1 nested object) and no output schema, the description covers operation modes, required conditions, and example outputs. It lacks explicit return value documentation but implies success responses. This is mostly complete for a mutation tool with moderate complexity.

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

Parameters4/5

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

Schema coverage is 100%. The description enriches parameter understanding through examples and hints, showing how parameters like 'reopenRules' and 'issue_url' are used in different operations. This goes beyond the schema's property descriptions by providing concrete usage context.

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?

The description clearly states 'Update the status of an error' and provides distinct use cases, examples, and operations. It differentiates from sibling tools like bugsnag_get_error (read-only) and bugsnag_list_project_errors (listing). The verb and resource are specific, and the tool's purpose is unambiguous.

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?

The 'Use Cases' section enumerates scenarios (mark as open/fixed/ignored, discard/undiscard, update severity, snooze). While it doesn't explicitly state when not to use or compare with alternatives, the context implies that for reading, other tools should be used. This provides clear, though not exhaustive, guidance.

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

Install Server

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