Integrations

Connect your agents to the tools your team already uses, and let them do real work there: open the pull request, post the summary, file the ticket. An admin installs the integration’s package from the Marketplace once. Then each person, team or the org adds a connection that holds the sign-in or the secret. The agent uses the connection and never sees the secret.

What you can do with it

Ship a fix end to end. With GitHub connected, an agent clones the repo, pushes a branch and opens a pull request with gh, using a token that reaches only the repositories you can reach.
Report where your team reads. With the Slack MCP package connected, an agent posts its summary to #eng as you, or searches past threads before it answers.
Turn a failing test into a ticket. With Atlassian or Linear connected, an agent files the Jira or Linear issue with the stack trace and the commit that broke it.

See it end to end: Review every pull request and Triage alerts from your tools.

How it works

An admin installs the package. A person, a team or the org adds a connection. An agent in a space or a run then uses it.

A package describes the service: how to sign in, what access it asks for and which tools the agent gets. See Marketplace packages.
A connection is your sign-in or your secret for that service. See Credentials and connections.
A sign-in connection acts as you. It stays yours. Teammates connect with their own sign-in.
A pasted secret can be owned by you, a team you lead, or the org, and shared with teams or people. Sharing with the whole org needs an admin. People you share it with can use it but cannot see, change, rotate or share it.

Who does what

Task	Who
Browse the Marketplace	Any member
Install or remove a package	Admins and owners
Add a connection for yourself	Any member
Add a connection for a team	A lead of that team
Add a connection for the whole org	Admins and owners
Choose a connect mode, or register the org’s own OAuth app	Admins and owners
Connect the org’s Slack workspace	Admins and owners

Connect a service

Open Connections

Select Connections in the sidebar. Each installed package has a card.

Select Connect

Select Connect on the card. If you already have a connection and want a second one, for example for another account, select Add another.

Choose a method

Some packages offer more than one method, as tabs. GitHub, for example, offers Sign in with GitHub, Personal access token and SSH key.

Finish the method

For a sign-in, the dialog shows where your browser goes and the Requested access. Select the connect button, approve on the service’s page, and you return to Marshal.
For a pasted secret, fill in the fields. Choose an Owner if the dialog offers one: you, a team you lead, or the org.

What you should see: a message that the service is connected, and the connection listed on the Connections page.

A connection that needs a fresh sign-in shows Needs reconnect. Select Reconnect. If you delete a connection, spaces that use it lose access to the service.

Your own MCP server can sign in with OAuth too. An admin adds it under Settings > MCP Servers, and each member connects from this page. See Set up OAuth on a custom MCP server.

GitHub

Sign in with GitHub uses the Marshal GitHub App.

An admin installs the Marshal GitHub App on your GitHub organization and picks the repositories it can reach. This happens on GitHub and gives nobody a token by itself.
Each person selects Connect, then Sign in with GitHub, and approves.

Your token is limited to what the app was granted and what you can already reach on GitHub, so an agent never reaches a repository you could not reach yourself. The token is short-lived, and Marshal renews it for you.

Personal access token. Paste a classic or fine-grained token. The package suggests the scopes repo, read:org and workflow. Keep workflow if agents change files under .github/workflows/.

SSH key. Paste an Ed25519 or RSA private key in PEM format, and register the public key at github.com/settings/keys. This method authenticates git over SSH, so use addresses such as git@github.com:org/repo.git.

GitHub can also start work in Marshal: a pull request or an issue can fire a deputy mission. See Schedules and triggers.

Slack

Slack has two separate connections. One lets Marshal reach people. The other lets an agent work in Slack as you.

The org workspace: questions and notices in Slack

An admin connects one Slack workspace for the org. Marshal then sends questions and notices from runs as direct messages, and people answer approval questions with a button in Slack. Available when your administrator enables Slack.

Open Settings > Slack.
Select Connect Slack. A Slack admin or owner approves the install in Slack.
You return to Marshal. The card shows Connected.

Under Who gets Slack messages, Marshal matches people to Slack accounts by email, using only emails that Slack has confirmed. Select Re-sync to match again. An admin can pick an account by hand for someone who was not matched, or select Unlink to remove a link. People who are not matched see everything in the web app.

Bot permissions the install asks for

chat:write, im:write, users:read, users:read.email

Slack MCP: an agent in Slack as you

The Slack MCP package lets an agent search and post in Slack as you. Each person connects their own account.

An admin installs Slack MCP.
Open Connections, find Slack MCP, and select Connect with Slack (personal).
Approve in Slack.

The agent can read and post where you can, and its posts show as yours. If your Slack workspace rotates tokens, Marshal renews yours, so you do not reconnect.

Run spaces as you. Your connection belongs to you, so a space uses it when you launch it from a manifest you own. Your admin publishes a stack that includes Slack MCP, and you make your own manifest from it:

In the left rail, open Manifests and click New manifest.
Enter a Name, choose the stack that includes Slack MCP under Stack, and click Create.
Open the manifest, select Slack MCP under Integrations, and in Bound to pick your Slack MCP credential. Click Save.
Click Launch. The agent in the space posts and searches as you.

Manifests the organization owns use the organization’s shared credentials. Each person’s own connection goes with the manifests they own. See Create a manifest.

User permissions Marshal asks Slack for

chat:write, channels:history, groups:history, im:history, mpim:history, users:read, users:read.email, search:read.public, search:read.private, search:read.im, search:read.mpim, search:read.files, search:read.users, canvases:read, canvases:write

Atlassian

The Atlassian MCP package gives agents Jira and Confluence through Atlassian’s hosted MCP server. Agents can read and update Jira issues and Confluence pages. The package keeps agents away from Atlassian tools that delete, archive, remove, purge, trash or destroy things.

Sign in with Atlassian. Your Atlassian admin allows Marshal once:

In Atlassian, open Administration > Rovo > Rovo MCP server > Domains > Your domains.
Select Add domain and add https://*.marshal.codes/**.

After that, each person signs in. No Atlassian app or API token is needed, and Marshal renews the token.

Hosted MCP token (email + API token). Enter your Atlassian email, an API token and your site URL, for example https://acme.atlassian.net.

An Atlassian admin turns on Allow API token authentication once per Atlassian org, under Administration, your site, Rovo, Rovo MCP server, Authentication.
Create the token at id.atlassian.com/manage-profile/security/api-tokens with Create API token with scopes, and select the Rovo (MCP) app.
Grant at least read:jira-work and read:jira-user. Add Confluence scopes, such as read:confluence-content.all, and write scopes, such as write:jira-work, if agents read Confluence or change things.
Paste the token. Atlassian shows it only once.

These packages offer a browser sign-in. Some also accept a pasted key.

Service	What an agent can do
Asana	Read, update and comment on tasks, projects, portfolios and goals.
Canva	Find designs, brand templates and folders, and create or update designs.
Datadog	Pull up logs, metrics, traces, dashboards, monitors and incidents. Write tools are blocked by default.
Fathom	Read meeting recordings, transcripts, summaries and action items.
Fellow	Read meeting notes and action items, and update a meeting’s agenda.
Figma	Read a frame’s layout, styles, variables and components before writing UI code.
GitLab	Work with merge requests, work items, pipelines and code search.
Globalping	Run ping, traceroute, DNS and HTTP checks from probes around the world.
Intercom	Search conversations, contacts and help center articles.
Linear	Read and update issues, projects, teams, cycles and roadmaps.
monday.com	Read and update boards, items, columns and updates.
Neon	Work with projects, schemas, SQL and database branches.
Netlify	Read sites, deploys and build logs.
Notion	Search and read pages and databases, and create and update pages.
PayPal	Look up orders, invoices, subscriptions, transactions and disputes.
Port	Query the software catalog and scorecards, and run self-service actions.
PostHog	Query logs, error tracking, session replays, insights and HogQL.
Sentry	Read issues, stack traces, breadcrumbs and the release that introduced a crash.
Square	Read catalog, orders, customers, inventory and payments.
Stripe	Read customers, subscriptions, invoices, payments and disputes.
Vercel	Read projects, deployments, and build and runtime logs.
Webflow	Read and update sites, pages and CMS collections.
Wix	Work with sites, stores, bookings and CMS collections.

Each package decides what access it asks for. The connect dialog lists it under Requested access before you leave Marshal. The package catalog lists every package.

Configure it

Every package that signs in with OAuth gets a connect mode. The mode decides whose app the sign-in uses and who registers it. Admins and owners pick the mode per package under Settings > OAuth apps. By default every package is on Automatic, which picks the best path for you, so most orgs never change it.

The connect dialog tells each person which path they are on:

Shown in the dialog	Meaning
Using Marshal’s app	Marshal runs a shared OAuth app for this service. Nothing to set up.
Using your org’s own app	An admin registered the org’s own app.
Registering dynamically with the provider	The service lets Marshal register itself. No app is set up ahead of time.

The five connect modes

Each package has a row on Settings > OAuth apps with a toggle of five modes. The active mode is highlighted. A mode the service does not support is faded, and hovering it shows “Not supported for” and the package name. A mode that is switched off for your org or deployment is struck through. Every mode has an info icon that tells you why it is or is not available. Each mode also shows how many people are connected through it.

Mode	What it does	Pick it when
Automatic	Uses your org’s own app if you enabled one. Otherwise uses Marshal’s Auth Broker when it is on and can serve the service. Otherwise registers a client from this cell (DCR from this cell).	You want it to just work. This is the default.
Own app	Signs in with an OAuth app your org registered at the service.	Your security team wants every sign-in under your own app, or the service scopes apps per tenant.
Marshal app	Signs in with the app Marshal runs for the service, through the Marshal Auth Broker.	You want nothing to register or maintain. Available when the broker is on for your org.
DCR via broker	The Marshal Auth Broker registers a client with the service for you.	The service supports dynamic client registration and you want the broker to handle it.
DCR from this cell	Your cell registers a client with the service itself, signs people in and renews tokens, with no broker involved.	Your cell is private or self-hosted, or you prefer that no hosted service sits in the middle.

The mode you pick is the mode that runs. If an admin chooses a mode and it cannot connect, people see a message that names the mode, so you always know which path to fix. Marshal never quietly switches to another one. Pick Automatic to hand the choice back.

Changing the mode never disconnects anyone. Existing connections keep working and renew the way they were made. New connections use the new mode.

Use your org’s own OAuth app

Admins and owners can make Marshal sign in with the org’s own app for a service. Own app is offered for packages that support it.

Open Settings > OAuth apps and find the service.
Select Own app in the row’s toggle. Until your org’s own app is ready, the mode reads Own app Set up, or Own app Manage once an app is saved and waits to be verified and enabled. Selecting it opens the own-app form.
Enter the inputs the form asks for. The package decides what they are. Most ask for a Client ID and a Client secret. Others ask for different values, such as an app ID and a private key, or the address of your own instance. Secret values are stored encrypted and are not shown again.
Select Test connection. This sends you to the service’s consent screen. When the test passes, the app is verified.
Enable the app. Then choose Own app in the toggle if you want every new sign-in to use it.

Some services issue public apps that have a client ID and no secret. When a service supports that, leave the secret out and Marshal signs in and renews tokens with the client ID alone.

Existing connections keep working. People move to the new app when they reconnect, and the page shows how many people still use each mode.

Allow the redirect address at the service

After someone approves a sign-in, the service sends their browser back to Marshal. Most services only do that for addresses you allowed ahead of time, so they need the exact address in their list of allowed redirect URLs.

Configure on each row shows the Redirect URI for the mode you picked, with a Copy button. Copy it and paste it into the allowed redirect URLs of your app at the service. Own app and DCR from this cell share one address on your cell. The broker modes use the broker’s address. Change the mode and the address changes with it. The one you copy is exactly the one Marshal sends to the service.

Test connection for any mode

Test connection in Configure runs a real sign-in through the active mode, for any mode, and then throws the token away. You get a clear pass or the service’s own error before anyone on your team hits it, and nothing is stored under your name. For DCR from this cell, the first test also registers the client, so real sign-ins reuse it.

Edge cases

A sign-in connection is always personal. To give a team one shared login, use a pasted secret owned by the team.
GitHub and Slack show on Settings > OAuth apps with a System badge. They use Marshal’s app by default. Choose Own app on either row to bring your own app: Use your own Slack app and Use your own GitHub App.
The mode toggle is per package, so one org can run one service on Own app and another on DCR from this cell.
A service can only use DCR from this cell when it lets apps register themselves and its hosts are in the package’s egress hosts. The info icon on the mode says which one is missing.

Try it

Open Connections, select Connect on GitHub, and choose Sign in with GitHub. Then launch a space and run gh repo list in it.