Runs the full BearQ regression suite — every regression-ready test case in the workspace. Use for CI/CD or pre-release smoke.

Toolset: Tasks

Parameters: None

Runs specific BearQ regression test cases by ID. Targets only regression-ready cases — drafts will be rejected.

Toolset: Tasks

Parameters:

• testCaseIds (array) required: IDs of BearQ regression test cases to run.

Runs every regression test case tagged with one or more functional areas. Functional areas can be given by ID or name.

Toolset: Tasks

Parameters:

• functionalAreas (array) required: Functional areas to target, by ID or name.

Refines specific BearQ draft test cases — improves their steps so they can eventually be promoted to regression tests. Use when a draft is incomplete or has drifted from its intent.

Toolset: Tasks

Parameters:

• testCaseIds (array) required: IDs of BearQ draft test cases to refine.

Refines every draft test case tagged with one or more functional areas. Functional areas can be given by ID or name. May take multiple passes before drafts are ready to be promoted to regression tests.

Toolset: Tasks

Parameters:

• functionalAreas (array) required: Functional areas to target, by ID or name.

Refines every draft test case in the workspace. Use to push an entire draft backlog forward; may take multiple passes before all drafts are ready to be promoted to regression tests.

Toolset: Tasks

Parameters: None

Explores the live application to discover or update its pages and elements in BearQ's application model. Optionally scope to a single functional area.

Toolset: Tasks

Parameters:

• functionalArea (union): Functional area to scope the exploration to, by ID or name. Omit to explore the entire application.

Sends an open-ended instruction to BearQ's QA lead agent. Use this when no other BearQ tool fits — the QA lead can list, create, and update test cases, manage functional areas, and read the application model, and acts as a general-purpose escape hatch.

Toolset: Tasks

Parameters:

• instruction (string) required: Natural language instruction to send to the BearQ QA lead agent.

Retrieves a task's current state, metadata, and activity log. Returns immediately with whatever's available — does not block on the task completing.

Toolset: Tasks

Parameters:

• taskId (number) required: BearQ task ID.

Retrieves the status of a task (running / complete / error / cancelled). Cheaper than fetching full task details.

Toolset: Tasks

Parameters:

• taskId (number) required: BearQ task ID.

Cancels a running task.

Toolset: Tasks

Parameters:

• taskId (number) required: BearQ task ID to cancel.

Blocks until a BearQ task reaches a terminal state (completed / failed / cancelled) or the stream times out, then returns the full ordered sequence of SSE events from the public API (metadata, activityLogEntries, and a terminal done or timeout event) verbatim. Blocks for the lifetime of the task — for a quick check use bearq_get_task_status instead.

Toolset: Tasks

Parameters:

• taskId (number) required: BearQ task ID.

Retrieve available reusable test segments for the given platform type. Segments are reusable test steps with an optional set of parameters that can used across multiple tests.

Toolset: Tests

Parameters:

• platform (enum) required: The platform type to retrieve segments for

• offset (number): Offset for pagination

• limit (number): Maximum number of segments to return

Connect to an active Reflect recording session via WebSocket to enable interactive control. When creating or editing a Reflect test using a connected recording session, follow these guidelines:

1. After connecting to a session, get the list of segments for the session's platform type so you know what actions could be added via segments vs needing to create new steps. Do not list tests, only list segments.

2. Before performing an action, take a screenshot to understand the current state of the application.

3. Each add_prompt_step request should perform a single action or assertion. Do not combine multiple actions or assertions into a single step.

4. Only perform one action at a time unless you're sure the action won't move the application to a different screen. For example, you can send multiple add_prompt_step requests to fill out individual form fields if those fields are visible on the current screen.

5. Check the list of existing Segments to see if a Segment exists that achieves a similar goal to what you're trying to do next. If so, add the segment instead of creating new steps.

6. If a step fails, use delete_previous_step to remove it and try a different approach.

7. After completing a task, if the task required multiple prompt steps, add a final prompt step that validates the current state of the page based on what you see on the screen. In your validation, do not reference information that can change from run to run.

Toolset: Recording

Parameters:

• sessionId (string) required: The ID of the Reflect recording session to connect to

Add a natural language prompt step to an active Reflect recording session

Toolset: Recording

Parameters:

• sessionId (string) required: The ID of the Reflect recording session

• prompt (string) required: The natural language prompt describing the test step. The prompt should describe a single action, assertion, or query. The prompt can only contain literal text; it cannot contain template variables, secrets, or other dynamic syntax. If we are in a Web recording, the prompt can perform browser navigation (e.g. 'Click on the back button', 'Navigate to https://www.example.com') and use the tab and enter keys to navigate (e.g. 'Press the tab key', 'Press the enter key').

Capture a screenshot from the current state of an active Reflect recording session

Toolset: Recording

Parameters:

• sessionId (string) required: The ID of the Reflect recording session

• format (enum): The image format for the screenshot (png or jpeg)

Delete the last step added to an active Reflect recording session

Toolset: Recording

Parameters:

• sessionId (string) required: The ID of the Reflect recording session

Insert a reusable test segment into an active Reflect recording session

Toolset: Recording

Parameters:

• sessionId (string) required: The ID of the Reflect recording session

• segmentId (number) required: The ID of the segment to add

Retrieve a list of all reflect suites available

Toolset: Suites

Parameters: None

List all executions for a given suite

Toolset: Suites

Parameters:

• suiteId (string) required: ID of the reflect suite to list executions for

Get the status of a reflect suite execution

Toolset: Suites

Parameters:

• suiteId (string) required: ID of the reflect suite to get execution status for

• executionId (string) required: ID of the reflect suite execution to get status for

Execute a reflect suite

Toolset: Suites

Parameters:

• suiteId (string) required: ID of the reflect suite to execute

Cancel a reflect suite execution

Toolset: Suites

Parameters:

• suiteId (string) required: ID of the reflect suite to cancel execution for

• executionId (string) required: ID of the reflect suite execution to cancel

List all reflect tests

Toolset: Tests

Parameters: None

Get the full detail of a reflect test, including its name, description, and all recorded steps

Toolset: Tests

Parameters:

• testId (string) required: ID of the reflect test to retrieve details for

Run a reflect test

Toolset: Tests

Parameters:

• testId (string) required: ID of the reflect test to run

Get the status of a reflect test execution

Toolset: Tests

Parameters:

• executionId (string) required: ID of the reflect test execution to get status for

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

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

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

{}

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

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

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

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

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

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

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

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

2. 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

3. 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

4. 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

5. 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

6. 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

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

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

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

{
  "projectId": "1234567890abcdef12345678",
  "errorId": "6863e2af012caf1d5c320000"
}

Expected Output: A list of events, ordered by timestamp, with complete details including stack trace, breadcrumbs, metadata, and context

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

{}

Expected Output: JSON array of release objects in the production stage

2. List staging releases for a project

{
  "releaseStage": "staging"
}

Expected Output: JSON array of release objects in the staging stage

3. Get the next page of results

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

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

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

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

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

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

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

{
  "spanGroupId": "[HttpClient]GET-api.example.com"
}

Expected Output: Statistics, category, and performance target info

2. Get span group details with device filtering

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

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

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

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

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

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

{}

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

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

{}

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)

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

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

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

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

Search for available portals within Swagger. Only portals where you have at least a designer role, either at the product level or organization level, are returned.

Toolset: Portals

Create a new portal within Swagger.

Toolset: Portals

Parameters:

• name (string): The display name for the portal - shown to users and in branding (3-40 characters)

• subdomain (string) required: The portal subdomain - used in the portal URL (e.g., 'myportal' for myportal.example.com). Must be unique, lowercase, 3-20 characters, alphanumeric with hyphens

• offline (boolean): If true, the portal will not be visible to customers - useful for development/staging environments. Defaults to false

• routing (string): Routing strategy for the portal - either 'browser' (client-side routing) or 'proxy' (server-side routing). Defaults to 'browser'

• credentialsEnabled (boolean): Whether authentication credentials are enabled for accessing the portal. When true, users can authenticate to access private content. Defaults to true

• swaggerHubOrganizationId (string) required: The corresponding Swagger organization UUID - required for portal creation. This links the portal to your Swagger organization. Only one Portal per Swagger organization is allowed.

• openapiRenderer (string): OpenAPI renderer type: 'SWAGGER_UI' (Swagger UI), 'ELEMENTS' (Stoplight Elements), or 'TOGGLE' (allows switching between both with Elements as default). Defaults to 'TOGGLE'

• pageContentFormat (string): Format for page content rendering - determines how documentation pages are processed: 'HTML', 'MARKDOWN', or 'BOTH'. Defaults to 'HTML'

Retrieve information about a specific portal.

Toolset: Portals

Parameters:

• portalId (string) required: Portal UUID or subdomain - unique identifier for the portal instance

Update a specific portal's configuration.

Toolset: Portals

Parameters:

• portalId (string) required: Portal UUID or subdomain - unique identifier for the portal instance

• name (string): Update the portal display name - shown to users and in branding (3-40 characters)

• subdomain (string): Update the portal subdomain - changes the portal URL. Must remain unique across all portals (3-20 characters, lowercase, alphanumeric with hyphens)

• customDomain (boolean): Enable/disable custom domain for the portal - allows using your own domain instead of the default subdomain

• gtmKey (string): Google Tag Manager key for analytics tracking - format: GTM-XXXXXX (max 25 characters)

• offline (boolean): Set portal visibility - true hides portal from customers (useful for maintenance or development)

• routing (string): Update routing strategy - 'browser' for client-side routing or 'proxy' for server-side routing

• credentialsEnabled (boolean): Enable/disable authentication credentials for portal access - controls whether users can authenticate to view private content

• openapiRenderer (string): Change OpenAPI renderer: 'SWAGGER_UI' (Swagger UI), 'ELEMENTS' (Stoplight Elements), or 'TOGGLE' (switch between both)

• pageContentFormat (string): Update page content format for documentation rendering: 'HTML', 'MARKDOWN', or 'BOTH'

Resolve portal details for a Swagger organization in a single step. Given an organization UUID, returns the portal ID, subdomain, customDomain (when configured), and the list of products (with productId, productSlug, and productName) for the organization's portal. If the organization has no portal yet, a new portal is created automatically. Use this tool to obtain all portal context needed for subsequent portal and product operations.

Toolset: Portals

Parameters:

• organizationId (string) required: Swagger organization UUID - the organization to resolve portal details for

Get products for a specific portal that match your criteria.

Toolset: Products

Parameters:

• portalId (string) required: Portal UUID or subdomain - unique identifier for the portal instance

Create a new product for a specific portal.

Toolset: Products

Parameters:

• portalId (string) required: Portal UUID or subdomain - unique identifier for the portal instance

• type (string) required: Product creation type - 'new' to create from scratch or 'copy' to duplicate an existing product

• productId (string): Source product UUID to copy from - required when type is 'copy', specifies which existing product to duplicate. Omit when type is 'new'

• name (string) required: Product display name - will be shown to users in the portal navigation and product listings (3-40 characters)

• slug (string) required: URL-friendly identifier for the product - must be unique within the portal, used in URLs (e.g., 'my-api' becomes /my-api). 3-22 characters, lowercase, alphanumeric with hyphens, underscores, or dots

• description (string): Product description - explains what the API/product does, shown in product listings and cards (max 110 characters)

• public (boolean): Whether the product is publicly visible to all portal visitors - false means only authenticated users with appropriate roles can access it

• hidden (boolean): Whether the product is hidden from the portal landing page navigation menus - useful for internal or draft products

Retrieve information about a specific product resource.

Toolset: Products

Parameters:

• productId (string) required: Product UUID or identifier in the format 'portal-subdomain:product-slug' - unique identifier for the product

Delete a product from a specific portal

Toolset: Products

Parameters:

• productId (string) required: Product UUID or identifier in the format 'portal-subdomain:product-slug' - unique identifier for the product

Update a product's settings within a specific portal.

Toolset: Products

Parameters:

• productId (string) required: Product UUID or identifier in the format 'portal-subdomain:product-slug' - unique identifier for the product

• name (string): Update product display name - changes how it appears to users in navigation and listings (3-40 characters)

• slug (string): Update URL-friendly identifier - must remain unique within the portal, affects product URLs (3-22 characters, lowercase, alphanumeric with hyphens/underscores/dots)

• description (string): Update product description - explains the API/product functionality, shown in listings (max 110 characters)

• public (boolean): Change product visibility - true makes it publicly accessible to all visitors, false restricts to authenticated users with roles

• hidden (boolean): Change navigation visibility - true hides from portal landing page menus while keeping the product accessible via direct links

Publish a product's content to make it live or as preview. This endpoint publishes the current content of a product, making it visible to portal visitors. Use preview mode to test before going live. Optionally provide tableOfContentsId to get a page-specific URL. Returns publication status, a live or preview URL (null if URL building fails), product and portal metadata, and an optional warning when metadata/URL building failed — a warning does NOT mean the publish failed.

Toolset: Products

Parameters:

• productId (string) required: Product UUID or identifier in the format 'portal-subdomain:product-slug' - unique identifier for the product

• tableOfContentsId (string): Optional table of contents UUID, or identifier in the format 'portal-subdomain:product-slug:section-slug:table-of-contents-slug'. When provided, publishPortalProduct uses it to resolve the published URL path for the returned preview/live link.

• preview (boolean): Whether to publish as preview (true) or live (false). Preview allows testing before going live. Defaults to false (live publication) (default: false)

Get sections for a specific product within a portal.

Toolset: Sections

Parameters:

• productId (string) required: Product UUID or identifier in the format 'portal-subdomain:product-slug' - unique identifier for the product

• embed (array): List of related entities to embed in the response - e.g., ['tableOfContents', 'tableOfContents.swaggerhubApi'] to include table of contents and SwaggerHub API details

• page (number): Page number for paginated results - specifies which page of results to retrieve (default is 1)

• size (number): Number of items per page for pagination - controls how many results are returned per page (default is 10)

Create a new table of contents item in a portal product section. Supports API references, HTML content, and Markdown content types.

Toolset: Table Of Contents

Parameters:

• sectionId (string) required: Section ID - unique identifier for the section within the product

• type (enum) required: Type of table of contents creation - 'new' to create from scratch or 'copy' to duplicate an existing one

• title (string) required: Title of the table of contents item - will be displayed in navigation (3-40 characters)

• slug (string) required: URL-friendly identifier for the table of contents item - must be unique within the section (3-22 characters, lowercase, alphanumeric with hyphens/underscores/dots)

• order (number) required: Order position of the table of contents item within its parent section or item

• parentId (string): Parent table of contents item ID - null for top-level items, or ID of parent item for nested structure

• content (object): Content configuration for the table of contents item

Get table of contents for a section of a product within a portal.

Toolset: Table Of Contents

Parameters:

• sectionId (string) required: Section ID - unique identifier for the section within the product

• embed (array): List of related entities to embed in the response - e.g., ['swaggerhubApi'] to include SwaggerHub API details

• page (number): Page number for paginated results - specifies which page of results to retrieve (default is 1)

• size (number): Number of items per page for pagination - controls how many results are returned per page (default is 20)

Delete table of contents entry. Performs a soft-delete of an entry from the table of contents. Supports recursive deletion of nested items.

Toolset: Table Of Contents

Parameters:

• tableOfContentsId (string) required: The table of contents UUID, or identifier in the format 'portal-subdomain:product-slug:section-slug:table-of-contents-slug'

• recursive (boolean): Flag to include all the nested tables of contents (default: false)

Create a documentation page in a portal product in a single tool call. Supports markdown and html content types. Returns the page location details (productId, sectionId, slug) and a draftUrl to edit it in the portal.

Toolset: Documents

Parameters:

• portalId (string) required: Portal UUID or subdomain - unique identifier for the portal

• productId (string) required: Product UUID - unique identifier for the product

• pageTitle (string) required: Title of the documentation page - will be displayed in navigation (3-255 characters)

• pageSlug (string): URL slug for the documentation page. 3-255 characters, lowercase, alphanumeric with hyphens, underscores, or dots (e.g. 'my-page'). If not provided, the slug is generated from the page title.

• pageContent (string): Content of the documentation page. Provide HTML when contentType is 'html', Markdown when contentType is 'markdown'.

• contentType (enum): Content type of the documentation page. 'markdown' works with both 'internal' and 'external' source. 'html' only works with 'external' source — html + internal is not supported by the API and will return an error. (default: "markdown")

• source (enum): Where the document content is managed. 'internal': editable in both the portal UI and via API. 'external': editable via API only, not in the portal UI. Constraint: 'html' content type only supports 'external' source. (default: "internal")

• order (number): Order position of the documentation page within its parent section or item (default: 0)

• parentId (string): Parent table of contents item ID - null for top-level pages, or ID of parent item for nested structure

Get document content and metadata by document ID. Useful for retrieving HTML or Markdown content from table of contents items.

Toolset: Documents

Parameters:

• documentId (string) required: Document UUID - unique identifier for the document

Update the content or source of an existing document. Supports both HTML and Markdown content types.

Toolset: Documents

Parameters:

• documentId (string) required: Document UUID - unique identifier for the document

• content (string): The document content to update (HTML or Markdown based on document type)

• type (enum): Content type of the document. Note: documents with type 'html' and source 'internal' cannot be edited via API — only 'html' + 'external' and all 'markdown' combinations are supported.

• source (enum): Where the document content is managed. 'internal': editable in both portal UI and API. 'external': editable via API only. Note: 'html' + 'internal' documents cannot be updated via API.

Search for APIs and Domains in SwaggerHub Registry using the comprehensive /specs endpoint and retrieve metadata including owner, name, description, summary, version, and specification.

Toolset: Registry API

Parameters:

• query (string): Search query to filter APIs by name, description, or content

• state (enum): Filter APIs by publication state - ALL (default), PUBLISHED, or UNPUBLISHED

• tag (string): Filter APIs by tag

• offset (number): Offset for pagination (0-based, default 0)

• limit (number): Number of results per page (1-100, default 20)

• sort (enum): Sort field - NAME, UPDATED, or CREATED (default NAME)

• order (enum): Sort order - ASC or DESC (default ASC)

• owner (string): Filter APIs by owner (organization or user)

• specType (enum): Filter by specification type - API or DOMAIN (default all types)

Fetch resolved API definition from SwaggerHub Registry based on owner, API name, and version.

Toolset: Registry API

Parameters:

• owner (string) required: API owner (organization or user, case-sensitive)

• api (string) required: API name (case-sensitive)

• version (string) required: Version identifier

• resolved (boolean): Set to true to get the resolved version with all external $refs included (default false)

• flatten (boolean): Set to true to create models from inline schemas in OpenAPI definition (default false)

Create a new API or update an existing API in SwaggerHub Registry for Swagger Studio. The API specification type (OpenAPI, AsyncAPI) is automatically detected from the definition content. APIs are always created with fixed values: version 1.0.0, private visibility, and automock disabled (these values cannot be changed). Returns HTTP 201 for creation, HTTP 200 for update. Response includes 'operation' field indicating whether it was a 'create' or 'update' operation along with API details and SwaggerHub URL.

Toolset: Registry API

Parameters:

• owner (string) required: Organization name (owner of the API)

• apiName (string) required: API name

• definition (string) required: API definition content (OpenAPI/AsyncAPI specification in JSON or YAML format). Format is automatically detected. API is created with fixed values: version 1.0.0, private visibility, automock disabled, and no project assignment.

Get organizations for a user. Returns a list of organizations that the authenticating user is a member of. On-Premise admin gets a list of all organizations in the system.

Toolset: Registry API

Parameters:

• q (string): Search organizations by partial or full name (case-insensitive)

• sortBy (enum): The property to sort the results by

• order (enum): Sort order

• page (number): 0-based index of the page to return

• pageSize (number): Number of results per page to return

Run a standardization scan against an API definition using the organization's governance and standardization rules. Accepts a raw YAML or JSON OpenAPI/AsyncAPI definition and returns a list of validation errors, the total issue count, and counts grouped by severity. Use this tool when the user provides the API definition content directly (as raw YAML or JSON) and asks to validate, scan, or check the governance or standardization of the API.

Toolset: Registry API

Parameters:

• orgName (string) required: The organization name to use for standardization rules

• definition (string) required: API definition content (OpenAPI/AsyncAPI specification in JSON or YAML format) to scan for standardization errors

Run a standardization scan on an API that already exists in SwaggerHub Registry, identified by organization name, API name, and version. Fetches the API definition from the registry internally and scans it against the organization's governance and standardization rules. Returns a list of validation errors, total issue count, counts grouped by severity, and a SwaggerHub UI URL for the scanned API. Use this tool when the user identifies the API by org name, API name, and version and asks to validate, scan, or check the governance or standardization of an existing API.

Toolset: Registry API

Parameters:

• orgName (string) required: The organization name that owns the API and provides the standardization rules (case-sensitive)

• apiName (string) required: API name (case-sensitive)

• version (string) required: Version identifier

Generate and save an API definition based on a prompt using SmartBear AI. This tool automatically applies organization governance and standardization rules during API generation. The specType parameter determines the format of the generated definition. Use: 'openapi20' for OpenAPI 2.0, 'openapi30x' for OpenAPI 3.0.x, 'openapi31x' for OpenAPI 3.1.x, 'asyncapi2xx' for AsyncAPI 2.x, 'asyncapi30x' for AsyncAPI 3.0.x. Use this tool when creating APIs that comply with governance policies or when generating APIs from natural language descriptions. Use this tool when users ask to create, generate, or design APIs with governance or standardization requirements. Returns HTTP 201 for creation, HTTP 200 for update. Response includes 'operation' field indicating whether it was a 'create' or 'update' operation along with API details and SwaggerHub URL.

Toolset: Registry API

Parameters:

• owner (string) required: API owner (organization or user, case-sensitive)

• apiName (string) required: API name

• prompt (string) required: The prompt describing the desired API functionality (e.g., 'Create a RESTful API for managing a pet store with endpoints for pets, orders, and inventory')

• specType (enum): Specification type for the generated API definition. Use: 'openapi20' for OpenAPI 2.0, 'openapi30x' for OpenAPI 3.0.x (default), 'openapi31x' for OpenAPI 3.1.x, 'asyncapi2xx' for AsyncAPI 2.x, 'asyncapi30x' for AsyncAPI 3.0.x (default: "openapi30x")

Standardize and fix an API definition using AI to ensure compliance with governance policies. Scans the API definition for standardization errors and automatically fixes them using SmartBear AI. Optionally provide 'newVersion' (e.g. patch bump '1.0.0' → '1.0.1') to save the fixed definition as a new version — omitting it will overwrite the current version. Returns the number of errors found and the fixed definition if successful. Use this tool when users ask to standardize, fix, govern, or ensure governance compliance of APIs.

Toolset: Registry API

Parameters:

• owner (string) required: API owner (organization or user, case-sensitive)

• api (string) required: API name (case-sensitive)

• version (string) required: Version identifier

• newVersion (string): The version to save the fixed definition as (e.g. '1.0.1'). Omitting this will overwrite the current version — prefer providing a patch bump (e.g. '1.0.0' → '1.0.1') unless the user specifies otherwise.

Generate Pact tests using PactFlow AI. You can provide one or more of the following input types: (1) request/response pairs for specific interactions, (2) code files to analyze and extract interactions from, and/or (3) OpenAPI document to generate tests for specific endpoints. When providing an OpenAPI document, a matcher is required to specify which endpoints to generate tests for.

Toolset: Generate Pact Tests

Parameters:

• language (enum): Target language for the generated Pact tests. If not provided, will be inferred from other inputs.

• requestResponse (object): Direct request/response pair for a specific interaction. Use this when you have concrete examples of API requests and responses

• code (array): Collection of source code files to analyze and extract API interactions from. Include client code, data models, existing tests, or any code that makes API calls

• openapi (any)

• additionalInstructions (string): Optional free-form instructions to guide the generation process (e.g., 'Focus on error scenarios', 'Include authentication headers', 'Use specific test framework patterns')

• testTemplate (object): Optional test template to use as a basis for generation. Helps ensure generated tests follow your specific patterns, frameworks, and coding standards

Review Pact tests using PactFlow AI. You can provide the following inputs: (1) Pact tests to be reviewed along with metadata

Toolset: Review Pact Tests

Parameters:

• pactTests (object) required: Primary pact tests that needs to be refined.

• code (array): Collection of source code files to analyze and extract API interactions from. Include client code, data models, existing tests, or any code that makes API calls

• userInstructions (string): Optional free-form instructions that provide additional context or specify areas of focus during the refinement process of the Pact test.

• errorMessages (array): Optional error output from failed contract test runs. These can be used to better understand the context or failures observed and guide the recommendations toward resolving specific issues.

• openapi (any)

Retrieve the states of a specific provider

Toolset: Fetch Provider States

Parameters:

• provider (string) required: name of the provider to retrieve states for

Performs a comprehensive compatibility check to determine whether a specific version of a service (pacticipant) can be safely deployed into a given environment. It analyzes the complete contract matrix of consumer-provider relationships to confirm that all required integrations are verified and compatible.

Toolset: Can I Deploy

Parameters:

• pacticipant (string) required: The name of the pacticipant (application/service) being evaluated for deployment

• version (string) required: The version of the pacticipant that you want to check if it's safe to deploy

• environment (string) required: The target environment where the pacticipant version will be deployed (e.g., 'production', 'staging', 'test')

Retrieve the comprehensive contract verification matrix that shows the relationship between consumer and provider versions, their associated pact files, and verification results stored in the Pact Broker or Pactflow. The matrix provides detailed visibility into which consumer and provider versions have been successfully verified against each other, and highlights failures with detailed information about the cause.

Toolset: Matrix

Parameters:

• latestby (string): This property removes the rows for the overridden pacts/verifications from the results. The options are cvp (show only the latest row for each consumer version and provider) and cvpv (show only the latest row each consumer version and provider version). For a can-i-deploy query with one selector, it should be set to cvp. For a can-i-deploy query with two selectors, it should be set to cvpv.

• limit (number): The limit on the number of results to return (1-1000, default: 100) (default: 100)

• q (array) required

Use Cases: 1. Quickly identify which consumer and provider version combinations have passed or failed verification. 2. Diagnose and investigate why a particular consumer-provider verification failed. 3. Visualize the overall contract compatibility across two pacticipants / services. 4. Perform advanced queries using selectors to understand compatibility within specific branches, environments, or version ranges. 5. Support informed deployment decisions by answering 'can I deploy version X of this service to production?' 6. Expose contract verification details to non-frequent API users in a more accessible format.

Check your PactFlow AI entitlements and credit balance if you encounter 401 Unauthorized errors or permission/credit issues when using PactFlow AI features.

Toolset: PactFlow AI Status

Use Cases: 1. Diagnose 401 unauthorized errors when attempting to use PactFlow AI features 2. Check remaining AI credits when PactFlow AI operations are rejected due to insufficient credits 3. Verify account entitlements when users receive permission denied errors for PactFlow AI functionality 4. Troubleshoot PactFlow AI access issues by retrieving current entitlement status and credit balance 5. Provide detailed error context when PactFlow AI features are unavailable due to account limitations

Fetch metrics across the entire workspace

Toolset: Metrics

Parameters: None

Fetch metrics for all teams

Toolset: Metrics

Parameters: None

Retrieve all pacticipants (applications/services) registered in the Pact Broker or PactFlow workspace.

Toolset: Pacticipants

Parameters:

• pageNumber (number): Page number (default: 1)

• pageSize (number): Number of results per page

Retrieve details for a specific pacticipant by name.

Toolset: Pacticipants

Parameters:

• pacticipantName (string) required: Name of the pacticipant (application or service)

Retrieve all branches for a given pacticipant, with optional filtering and pagination.

Toolset: Branches and Versions

Parameters:

• pacticipantName (string) required: Name of the pacticipant

• q (string): Filter branches by name

• pageNumber (number): Page number (default: 1)

• pageSize (number): Results per page (default: 100)

Retrieve all versions for a given pacticipant.

Toolset: Branches and Versions

Parameters:

• pacticipantName (string) required: Name of the pacticipant

• pageNumber (number): Page number

• pageSize (number): Results per page

Retrieve details for a specific version of a pacticipant.

Toolset: Branches and Versions

Parameters:

• pacticipantName (string) required: Name of the pacticipant

• versionNumber (string) required: Version number to retrieve

Retrieve the latest version of a pacticipant, optionally filtered by tag.

Toolset: Branches and Versions

Parameters:

• pacticipantName (string) required: Name of the pacticipant

• tag (string): Tag to filter by. If omitted, returns the overall latest version.

Retrieve all environments configured in the Pact Broker or PactFlow workspace.

Toolset: Environments and Deployments

Parameters: None

Retrieve details for a specific environment by UUID.

Toolset: Environments and Deployments

Parameters:

• environmentId (string) required: UUID of the environment

Record that a version of a pacticipant has been deployed to an environment.

Toolset: Environments and Deployments

Parameters:

• pacticipantName (string) required: Name of the pacticipant that was deployed

• versionNumber (string) required: Version number that was deployed

• environmentId (string) required: UUID of the target environment

• applicationInstance (string): Identifies a specific instance when multiple instances of the same application are deployed to the same environment (e.g. 'blue', 'green')

Retrieve all versions currently deployed to a given environment.

Toolset: Environments and Deployments

Parameters:

• environmentId (string) required: UUID of the environment

Record that a version of a pacticipant has been released to an environment (for mobile/library release workflows).

Toolset: Environments and Deployments

Parameters:

• pacticipantName (string) required: Name of the pacticipant that was released

• versionNumber (string) required: Version number that was released

• environmentId (string) required: UUID of the target environment

Retrieve all versions currently released and supported in a given environment.

Toolset: Environments and Deployments

Parameters:

• environmentId (string) required: UUID of the environment

Publish one or more consumer Pact contracts to the Pact Broker or PactFlow, with branch and tag metadata.

Toolset: Contracts

Parameters:

• pacticipantName (string) required: Name of the consumer application

• pacticipantVersionNumber (string) required: Version number of the consumer

• contracts (array) required: Contracts to publish

• tags (array): Version tags (e.g. 'main', 'staging')

• branch (string): Branch name of the consumer

• buildUrl (string): URL of the CI build that produced these contracts

Publish a provider OpenAPI contract and self-verification results to PactFlow (Bi-Directional Contract Testing).

Toolset: Contracts

Parameters:

• providerName (string) required: Name of the provider application

• pacticipantVersionNumber (string) required: Version number of the provider

• contract (object) required: Provider contract (OpenAPI spec) and verification details

• tags (array): Version tags

• branch (string): Branch name of the provider

• buildUrl (string): URL of the CI build

Retrieve the pacts that a provider should verify, based on consumer version selectors and WIP/pending pact configuration.

Toolset: Contracts

Parameters:

• providerName (string) required: Name of the provider to get pacts for

• consumerVersionSelectors (array): Selectors specifying which consumer versions to include

• includePendingStatus (boolean): Include the pending status in the results

• includeWipPactsSince (string): Include WIP pacts published since this date (ISO 8601)

• providerVersionBranch (string): Branch of the provider version being verified

• providerVersionTags (array): Tags for the provider version being verified

Fetch the provider OpenAPI contract for a given provider version in Bi-Directional Contract Testing.

Toolset: Bi-Directional Contract Testing

Parameters:

• providerName (string) required: Name of the provider

• providerVersionNumber (string) required: Provider version number

Fetch the self-verification results for a provider contract version in Bi-Directional Contract Testing.

Toolset: Bi-Directional Contract Testing

Parameters:

• providerName (string) required: Name of the provider

• providerVersionNumber (string) required: Provider version number

Fetch all consumer Pact contracts relevant to a given provider version in Bi-Directional Contract Testing.

Toolset: Bi-Directional Contract Testing

Parameters:

• providerName (string) required: Name of the provider

• providerVersionNumber (string) required: Provider version number

Fetch the consumer contract verification results for a given provider version in Bi-Directional Contract Testing.

Toolset: Bi-Directional Contract Testing

Parameters:

• providerName (string) required: Name of the provider

• providerVersionNumber (string) required: Provider version number

Fetch the cross-contract verification results for a given provider version in Bi-Directional Contract Testing.

Toolset: Bi-Directional Contract Testing

Parameters:

• providerName (string) required: Name of the provider

• providerVersionNumber (string) required: Provider version number