Skip to main content

CI/CD, Service Catalog, and Source Control Integrations

The following CI/CD, Service Catalog, and Source Control integrations are available:

Azure DevOps

Use the Azure DevOps integration to read Azure DevOps work items linked from your changes.

To configure the integration:

  1. In Azure, create a service account and a personal access token with only the Work Items (Read) scope.

  2. Grant project access so Biggy can see what the service account can see. 

  3. In the web app, populate the following fields:

    Field

    Description

    Instance Name

    Display name of the Azure DevOps instance.

    Organization URL

    Azure organization URL. (Example, https://dev.azure.com/your-organization.)

    Personal Access Token

    Personal access token generated in step 1.

  4. Click Verify Connection to confirm that the connection to Azure DevOps is established.

  5. Click Create Instance.

Backstage

Use the Biggy Backstage integration to add service ownership, systems, and dependencies from your Backstage software catalog to Biggy investigations.

Biggy connects to the MCP Actions Backend plugin in your Backstage backend over streamable HTTP, then loads the tools that the server exposes. Read-only tools are pre-selected, and write and execute tools are gated behind approval.

Required permissions

The Backstage integration relies on a static token that you configure in backend.auth.externalAccess in your Backstage app configuration. Restrict the token to the mcp-actions and catalog plugins so Biggy can reach only the MCP server and the software catalog.

When you load the server tools, Biggy pre-selects the read-only tools. Allow write and execute tools only if Biggy should be able to run them. Biggy gates every write and execute call behind approval.

Prepare your Backstage backend

Biggy connects to the MCP server that the @backstage/plugin-mcp-actions-backend plugin adds to your Backstage backend. Before you configure the integration in BigPanda, prepare your backend:

  1. Add the MCP Actions Backend plugin: Add @backstage/plugin-mcp-actions-backend to your Backstage backend, then list catalog in backend.actions.pluginSources so the catalog actions are exposed as MCP tools.

  2. Add a named MCP server for Biggy (recommended): Under mcpActions.servers, add a named server that includes the action ID catalog:* and excludes catalog:register-entity, catalog:unregister-entity, and catalog:refresh-catalog-entity. The URL of a named server is /api/mcp-actions/v1/<name>.

  3. Create a static token: Create a static token in backend.auth.externalAccess and restrict it to the mcp-actions and catalog plugins. Keep namespaced tool names on. Do not set mcpActions.namespacedToolNames to false.

  4. Note the MCP server URL and token: The URL Biggy connects to is your Backstage backend URL plus the MCP path. For example, https://backstage.example.com/api/mcp-actions/v1/<name> for a named server, or https://backstage.example.com/api/mcp-actions/v1 for the default server. Note the token value, which you enter as the Bearer Token in BigPanda.

Use a named server for Biggy

The default server at /api/mcp-actions/v1 exposes every registered action. A named server limits Biggy to the catalog actions you include, and the exclude rules keep Biggy from registering, unregistering, or refreshing catalog entities.

Local launches are not supported

Biggy connects to the Backstage MCP server over Streamable HTTP, so the server must be reachable by Biggy or by a relay client. stdio and npx launch methods will not connect.

For more information about the plugin, see the MCP Actions Backend documentation from Backstage.

Configure the Backstage integration

To configure the integration, go to the web app Backstage integration page and populate the following fields:

Field

Description

Instance Name

A name that identifies this Backstage instance across Biggy. For example, Production Backstage.

Routing Instructions (Optional)

Describe what this instance covers so Biggy can route queries to it, for example, EU production accounts. Recommended, and required for multiple instances.

Agent notes (Optional)

List any organization-specific knowledge that helps Biggy interact with Backstage more effectively. We highly recommend configuring this field. For example, you can enter which Backstage projects and environments matter, naming conventions, and any investigation playbooks Biggy should follow.

Backstage MCP Server URL

The Streamable HTTP endpoint of the Backstage MCP server: your backend URL plus the MCP path. For example, https://backstage.example.com/api/mcp-actions/v1. If you added a named server for Biggy, include the server name, for example, https://backstage.example.com/api/mcp-actions/v1/<name>. Local stdio and npx launches are not supported.

Bearer Token

The static token you created in backend.auth.externalAccess. Biggy sends it to the MCP server as Authorization: Bearer <token>.

Custom Headers (Optional)

Add custom HTTP headers to include with requests to the MCP server. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.

On-premises instance

Enable this toggle when the Backstage instance is reachable only from within your network. Requests then route through a relay client, assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to test the credentials before you save.

Allowed tools and approvals

After configuring the integration fields, save the connection. Biggy loads the tools the server exposes, pre-selects the read-only ones, and gates writes and executions behind approval.

At least one tool is required

Biggy doesn't call any tools on the Backstage server until at least one tool is allowed. You cannot enable the Backstage instance until at least one tool is allowed.

Every action except a catalog read waits for approval. Switch the approval policy to Destructive only if your custom actions are read-only.

When you finish configuring the fields and allowing tools, click Create Instance to save the integration.

Bitbucket

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested. Core connectivity is stable, but the integration may receive updates based on user feedback.

Use the Bitbucket integration to investigate recent code changes, pull requests, commits, diffs, and CI. Biggy connects to the Bitbucket Cloud or Bitbucket Data Center REST API, and the agent behaves the same on both products.

Configure the Bitbucket integration

Multi-integration configuration

You can configure multiple instances of Bitbucket.

To add an additional integration, click + New instance on the integration configuration page.

To configure the integration:

  1. In Bitbucket, create a read-only access token. Instructions differ depending on whether your organization has a Bitbucket Cloud or Bitbucket Data Center deployment:

    1. Bitbucket Cloud:  Go to Workspace settings > Access tokens. Create a token with repository and pullrequest read scopes; add pipeline read if you want pipeline results. Optionally enter the workspace slug so Biggy can resolve bare repository names and search code without asking which workspace.

    2. Bitbucket Data Center: Go to Manage account > HTTP access tokens. Create a token with Read permission and enter the server base URL including any context path. (For example, https://bitbucket.company.com.)

  2. In the web app Bitbucket integration page, configure the following fields:

    Field

    Description

    Instance Name

    A name that identifies this Bitbucket instance across Biggy. For example, Production Bitbucket.

    Routing Instructions (Optional)

    Describe what this instance covers so Biggy can route queries to it, for example, EU production accounts. Recommended, and becomes required once a second instance exists.

    Workspace/Project Nuances (Optional)

    List any Bitbucket nuances that help investigations. 

    We highly recommend configuring this field, as it lets you enter organization-specific information that helps Biggy provide more accurate and consistent results. 

    For example, you can enter key workspaces, projects, and repositories to prioritize, repository naming conventions, default branches, CI setup (Pipelines, Bamboo, Jenkins), monorepo layout notes, where deployments happen, and any investigation playbooks Biggy should follow.

    Deployment Type

    Select where the Bitbucket instance is hosted: 

    Bitbucket Cloud: Atlassian-hosted at bitbucket.org. Uses a workspace, project, or repository access token. 

    Bitbucket Data Center: Self-hosted Data Center or Server on your own URL. Uses an HTTP access token.

    Default Workspace (Optional)

    Available when Deployment Type is Bitbucket Cloud. 

    The workspace slug Biggy uses to resolve bare repository names and to run code search. Questions can still name any workspace explicitly.

    Bitbucket Data Center URL

    Available when Deployment Type is Bitbucket Data Center. 

    The server base URL, including any context path. For example, https://bitbucket.company.com.

    Access Token

    Enter your Bitbucket access token.

     For Bitbucket Cloud, use a workspace, project, or repository access token with repository and pullrequest read scopes.

     For Bitbucket Data Center, use an HTTP access token (personal, project, or repository) with Read permission.

    Custom Headers (Optional)

    Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign. 

    These are commonly needed for Data Center behind a reverse proxy or single sign-on (SSO) gateway.

    On-premises instance

    Enable this toggle when the Bitbucket instance is reachable only from within your network. Requests then route through a relay client, assigned on the Relay Clients page. Bitbucket Cloud needs no relay.

  3. In the Connectivity section, click Verify Connection to test the credentials before you save.

  4. Click Create Instance.

GitHub

Use the Biggy GitHub integration to add code context or investigate recent code changes, pull requests, commits, and diffs.

Required Permissions

In GitHub, ensure the following personal access token (PAT) repository permissions are enabled:

  • Metadata 

  • Commit statuses 

  • Contents 

  • Issues 

  • Pull requests 

  • Checks 

Configure the GitHub Integration

To configure the integration, populate the following fields:

Field

Description

Authentication Method

Choose how you'd like to authenticate with this integration. The following methods are available:

  • Token (PAT) - Authenticate using a GitHub token (classic PAT or fine-grained PAT)

  • OAuth Access Token - Authenticate using a secure OAuth access token

  • GitHub App (Installation token) - Server-to-server auth via GitHub App JWT + installation access tokens

GitHub API Base URL

Enter the base URL of your GitHub instance. (for example, https://api.github.com)

Credentials

If you selected Token (PAT) as your authentication method, enter your Access Token.

If you selected OAuth Access Token as your authentication method, enter your OAuth Access Token.

If you selected GitHub App (Installation token) as your authentication method, enter your GitHub App ID, GitHub App Installation ID, and GitHub App Private Key (PEM).

Custom Headers (Optional)

Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.

Deployment Type

Select whether your GitHub integration is Cloud or On-Prem.

Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

GitHub System/Schema Nuances

List any special repo nuances, naming conventions, or other knowledge that helps Biggy more effectively interact with your tool.

We highly recommend configuring this field, as it lets you enter organization-specific information that helps Biggy provide more accurate and consistent results.

For example, you can enter key repos to prioritize, repo naming conventions, default branches, CI nuances, monorepo layout notes, deployment information, and any investigation playbooks that Biggy should follow.

GitLab

Beta integration

This integration is currently in beta release status.

Beta integrations are still being tested. Core connectivity is stable, but the integration may receive updates based on user feedback.

Use the GitLab integration to investigate recent code changes, merge requests, commits, diffs, and CI/CD pipelines.

Required permissions

Ensure the following GitLab scopes/permissions have been enabled for Biggy to have the required system access to perform its functions:

Access Token Scopes

read_api read_repository

OAuth Application Scopes

read_api read_repository

Multi-integration configuration

You can configure multiple instances of GitLab.

To add an additional integration, click + Add Instance on the integration configuration page.

To configure the integration, populate the following fields:

Field

Description

Authentication Method

Choose how you'd like to authenticate with this integration. The following methods are available:

  • PAT / GAT: Authenticate using a GitLab Personal, Project, or Group access token.

  • OAuth Token (Static): Authenticate using a single OAuth access token. Note: GitLab OAuth access tokens expire after 2 hours; use OAuth (refresh) for long-lived sessions.

  • OAuth (refresh-capable): Authenticate via a GitLab OAuth application using clientId + clientSecret + refreshToken. Access tokens auto-refresh. Rotated refresh tokens are persisted automatically.

GitHub Base URL

Enter the GitLab Base URL (For example, GitLab.com: https://gitlab.com; Self-Managed: https://gitlab.yourcompany.com)

Credentials

If you selected PAT / GAT as your authentication method, enter your Access Token.

If you selected OAuth Token (Static) as your authentication method, enter your OAuth Access Token.

If you selected OAuth (refresh-capable) as your authentication method, enter your OAuth Application ID, OAuth Application Secret, and Initial Refresh Token.

Custom Headers (Optional)

Add custom HTTP headers to include with all API requests. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.

Configuration Options

Select whether your GitLab integration is Cloud or On-Prem.

Certain integrations have endpoints that work only with one deployment type. Selecting the correct option automatically applies the right guardrails to the Biggy agents.

Note: On-prem integrations can connect via the Relay Client, enabling secure communication with infrastructure behind your firewall.

Routing Instructions

Routing Instructions are only required if you are configuring multiple instances of GitLab.

Enter instructions for when this specific GitLab instance should be used.

GitLab System/Schema Nuances

List any special repo nuances, naming conventions, or other knowledge that helps Biggy more effectively interact with your tool.

We highly recommend configuring this field, as it lets you enter organization-specific information that helps Biggy provide more accurate and consistent results.

For example, you can enter key repos to prioritize, repo naming conventions, default branches, CI nuances, monorepo layout notes, deployment information, and any investigation playbooks that Biggy should follow.

Harness

Use the Biggy Harness integration to add delivery context or investigate pipelines, deployments, GitOps configurations, feature flags, and delivery governance. 

Biggy connects to a running Harness Model Context Protocol (MCP) server over Streamable HTTP, then loads the tools that the server exposes. Read-only tools are pre-selected, and write and execute tools are gated behind approval.

Required permissions

The Harness integration relies on a Harness token that you provide to the MCP server. Create a personal or service account token with read access to the pipelines, services, environments, and other resources you want Biggy to see.

When you load the server tools, Biggy pre-selects the read-only tools. Allow write and execute tools only if Biggy should be able to run them. Biggy gates every write and execute call behind approval.

Run the Harness MCP server

Biggy connects to a Harness MCP server that you host. Before you configure the integration in BigPanda, prepare the server:

  1.  Run the Harness MCP server in HTTP mode: Start the server with harness-mcp-v2 http, or run the equivalent container image, somewhere Biggy or a relay client can reach it. Local stdio and npx launches are not supported.

  2.  Note the Streamable HTTP URL: This is the URL Biggy connects to. It usually ends in /mcp, for example, https://harness-mcp.company.com/mcp.

  3.  Note the server-side transport token: If the server requires a transport token, note its value. If the server sets HARNESS_MCP_AUTH_TOKEN, you enter that value as the MCP transport token.

Local launches are not supported

Biggy connects to the Harness MCP server over streamable HTTP, so the server must be reachable by Biggy or by a relay client. stdio and npx launch methods will not connect.

Configure the Harness integration

To configure the integration, go to the web app Harness integration page and populate the following fields:

Field

Description

Instance Name

A name that identifies this Harness instance across Biggy. For example, Production Harness.

Routing Instructions (Optional)

Describe what this instance covers so Biggy can route queries to it, for example, EU production accounts. Recommended, and required for multiple instances.

Agent notes (Optional)

List any organization-specific knowledge that helps Biggy interact with Harness more effectively. We highly recommend configuring this field. For example, you can enter which organizations and projects matter, naming conventions for pipelines and services, which environments count as production, and any investigation playbooks Biggy should follow.

Harness MCP Server URL

The Streamable HTTP URL of your running Harness MCP server. It usually ends in /mcp. For example, https://harness-mcp.company.com/mcp.

MCP Transport Token (Optional)

The token Biggy uses to authenticate to the MCP server itself, if the server requires one. It is sent as Authorization: Bearer to the MCP server and is independent of the Harness token. If the server sets HARNESS_MCP_AUTH_TOKEN, enter that value here.

Harness token

A personal or service account token with read access to the pipelines, services, environments, and other resources Biggy should see.

Custom Headers (Optional)

Add custom HTTP headers to include with requests to the MCP server. For each header, include the Header Name and Header Value. To add additional headers, click the + sign. 

On-premises instance

Enable this toggle when the Harness instance is reachable only from within your network. Requests then route through a relay client, assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to test the credentials before you save.

Allowed tools and approvals

After configuring the integration fields, save the connection. Biggy loads the tools the server exposes, pre-selects the read-only ones, and gates writes and executions behind approval.

At least one tool is required

You cannot enable the Harness instance until at least one tool is allowed.

When you finish configuring the fields and allowing tools, click Create Instance to save the integration.

Jenkins

Use the Biggy Jenkins integration to investigate Jenkins jobs, builds, logs, test results, and the commits each build used.

Biggy connects to the Jenkins MCP server plugin over streamable HTTP, then loads the tools that the server exposes. Read-only tools are pre-selected, and write and execute tools are gated behind approval.

Required permissions

The Jenkins integration relies on a dedicated Jenkins user and API token that you create for Biggy. Grant the Biggy user the following permissions:

  • Overall/Read

  • Job/Read

Leave out Job/Build, Job/Configure, and Job/Create unless you want Biggy to be able to request builds.

When you load the server tools, Biggy pre-selects the read-only tools. Allow write and execute tools only if Biggy should be able to run them. Biggy gates every write and execute call behind approval.

Prepare Jenkins

Before you configure the integration in BigPanda, prepare your Jenkins instance:

  1.  Install the MCP Server plugin: In Jenkins, go to Manage Jenkins > Plugins. Install the MCP Server plugin.

  2.  Create a read-only Jenkins user: Create a Jenkins user for Biggy with the permissions listed in Required permissions.

  3.  Create an API token: Sign in to Jenkins as the Biggy user. Open the user menu, then go to Security > API Token and create an API token. Copy the token value. 

  4.  Copy the MCP Server URL: This is the URL Biggy connects to. It uses the format https://<your-jenkins>/mcp-server/mcp. For example, https://jenkins.example.com/mcp-server/mcp.

Local launches are not supported

Biggy connects to the Jenkins MCP server over Streamable HTTP, so the server must be reachable by Biggy or by a relay client. stdio and npx launch methods will not connect.

Configure the Jenkins integration

To configure the integration, go to the web app Jenkins integration page and populate the following fields:

Field

Description

Instance Name

A name that identifies this Jenkins instance across Biggy. For example, Production Jenkins.

Routing Instructions (Optional)

Describe what this instance covers so Biggy can route queries to it, for example, EU production accounts. Recommended, and required for multiple instances.

Agent notes (Optional)

List any organization-specific knowledge that helps Biggy interact with Jenkins more effectively. We highly recommend configuring this field. For example, you can enter which Jenkins projects and environments matter, naming conventions, and any investigation playbooks Biggy should follow.

Jenkins MCP Server URL

The Streamable HTTP endpoint of the Jenkins MCP Server plugin, in the format https://<your-jenkins>/mcp-server/mcp. For example, https://jenkins.example.com/mcp-server/mcp. Local stdio and npx launches are not supported.

Username

The user name of the Jenkins user you created for Biggy.

Password

The API token you created for the Biggy user.

Custom Headers (Optional)

Add custom HTTP headers to include with requests to the MCP server. For each header, include the Header Name and Header Value. To add additional headers, click the + sign.

On-premises instance

Enable this toggle when the Jenkins instance is reachable only from within your network. Requests then route through a relay client, assigned on the Relay Clients page.

In the Connectivity section, click Verify Connection to test the credentials before you save.

After configuring the integration fields, save the connection. Biggy loads the tools the server exposes, pre-selects the read-only ones, and gates writes and executions behind approval.

Read tools run immediately. Approval is required for starting, replaying, or changing a build, and any tool Biggy doesn't recognize.

At least one tool is required

Biggy doesn't call any tools on the Jenkins server until at least one tool is allowed.

When you finish configuring the fields and allowing tools, click Create Instance to save the integration.

NetBox

Use the Biggy NetBox integration to add infrastructure context or investigate devices, sites, racks, interfaces, IP addresses, prefixes, and circuits from NetBox.

Biggy connects to the NetBox Model Context Protocol (MCP) server over Streamable HTTP, then loads the tools that the server exposes. Read-only tools are pre-selected, and other tools are gated behind approval.

Required permissions

The NetBox integration relies on a read-only NetBox API token. The user that owns the token needs view permission on the NetBox objects you want Biggy to read.

Writes are blocked

Biggy always adds read_only=true to the NetBox MCP Server URL, so NetBox refuses every write request from Biggy.

Create a read-only API token

Before you configure the integration in BigPanda, create an API token in NetBox:

  1. In NetBox, open the user menu and select API Tokens.

  2. Add a v2 token. The token starts with nbt_.

  3. Clear the Write enabled checkbox.

  4. Copy the full token. You enter it in the Bearer Token field when you configure the integration.

Configure the NetBox integration

To configure the integration, go to the web app NetBox integration page and populate the following fields:

Field

Description

Instance Name

A name that identifies this NetBox instance across Biggy. For example, Production NetBox.

Routing Instructions (Optional)

Describe what this instance covers so Biggy can route queries to it, for example, EU production accounts. Recommended, and becomes required once a second instance exists.

Agent notes (Optional)

List any organization-specific knowledge that helps Biggy interact with NetBox more effectively. We highly recommend configuring this field. For example, you can enter which NetBox projects and environments matter, naming conventions, and any investigation playbooks Biggy should follow.

NetBox MCP Server URL

The Streamable HTTP endpoint of the NetBox MCP server. For example, https://<instance>.cloud.netboxapp.com/mcp.

Bearer Token

The full NetBox API token you created, starting with nbt_.

Custom Headers (Optional)

Add custom HTTP headers to include with requests to the MCP server. For each header, include the Header Name and Header Value. To add additional headers, click the + sign. 

On-premises instance

Enable this toggle when the NetBox instance is reachable only from within your network. Requests then route through a relay client, assigned on the Relay Clients page.

Caution

Local launches are not supported

Biggy connects to the NetBox MCP server over Streamable HTTP, so the server must be reachable by Biggy or by a relay client. stdio and npx launch methods will not connect.

In the Connectivity section, click Verify Connection to test the credentials before you save. Biggy verifies the connection by reading one site from NetBox.

Allowed tools and approvals

After configuring the integration fields, save the connection. Biggy loads the tools the server exposes, pre-selects the read-only ones, and gates writes and executions behind approval. Read tools run immediately, and other tools wait for approval. Biggy calls no tool on the NetBox server until at least one tool is allowed.

When you finish configuring the fields and allowing tools, click Create Instance to save the integration.

In this section: