# Set up Run A Runbook

This is a read-only composite, but it needs a model credential and every listed data source configured before it can run. Set up isolated test accounts or workspaces first, grant only the smallest read scope that exposes the test data, and store every credential only in Dome's secret inputs. Never put a key or secret in this repository, an agent prompt, or a chat message.

## Create the model credential

- Create an API key in the [Anthropic Console](https://console.anthropic.com/settings/keys).
- Enter the raw key as `anthropic_api_key` during import. Do not prepend `Bearer `.
- The template uses that key only for its managed `claude-sonnet-5` model connection.

## Create the provider credentials

- `slack_oauth_client_id`: A Slack app client ID.
- `slack_oauth_client_secret`: The Slack app client secret.
- `github_oauth_client_id`: The Client ID of a GitHub OAuth app registered with Dome's callback URL.
- `github_oauth_client_secret`: The client secret for the GitHub OAuth app.

For a provider that asks you to register a manual OAuth app, use this callback URL exactly:

`https://api.domesystems.ai/oauth/callback`

## Set up each connected provider

### incident.io

This provider uses Dynamic Client Registration (DCR). Do **not** create or paste an OAuth client ID or client secret: after import, Dome registers the client and opens the provider's consent page.

incident.io's remote MCP server uses OAuth with Dynamic Client Registration.
It is available only on incident.io Team, Pro, and Enterprise plans.

Before importing this composite:

- An incident.io administrator must search **Settings** for **MCP**. If there is
  no MCP setting, the remote server is not provisioned for the organization;
  do not start OAuth. Ask the organization owner or incident.io Support to
  confirm plan eligibility and enable the feature.
- In **Settings → MCP**, enable the remote MCP server and add
  `api.domesystems.ai` to **Allowed redirect domains**.

- Use a dedicated incident.io test user rather than an organization owner.
- When OAuth opens, select the intended incident.io organization and choose
  **Read only**. The template can then inspect the same incident, alert,
  escalation, on-call, and catalog data that user can see, without making
  changes.
- Dome registers its OAuth client automatically; do not create an incident.io
  client ID or client secret.

After saving, complete OAuth as the dedicated user. Confirm that
`identity_show` reports `access_level: read_only`, then test a known incident
and an out-of-boundary team or private incident.

If consent says **“The MCP server isn't available for [organization]”**, the
remote MCP server is disabled or has not been provisioned. Return to
**Settings → MCP**; if that setting is absent, ask the organization owner or
incident.io Support to enable it before retrying.

For a non-interactive connection, incident.io also supports API keys. Create
one under **Settings → API keys**, grant only the required account- or
team-scoped read permissions, store the value immediately (it is shown once),
and use it only with an MCP client configured for API-key authentication.

### Datadog

This provider uses Dynamic Client Registration (DCR). Do **not** create or paste an OAuth client ID or client secret: after import, Dome registers the client and opens the provider's consent page.

Before starting OAuth, a Datadog organization administrator must open
**Organization Settings → MCP OAuth Redirect URLs** and add this exact URL:

`https://api.domesystems.ai/oauth/callback`

Datadog rejects the consent flow with **Mismatching redirect URI** until that
allowlist entry exists. Dome uses Dynamic Client Registration, so no separate
Datadog OAuth client or client secret is needed. Dome requests Datadog's
published `mcp_all` scope during consent.

Before connecting, an organization administrator must also enable **MCP Access**
in Datadog. The authorizing test user needs **MCP Read** and the underlying
resource permissions (for example, Monitors Read); custom roles need those
permissions added explicitly. This composite starts with Datadog's generally
available `core` toolset. Add the Preview `apm` toolset only after obtaining
Datadog's APM Preview access.


After saving, complete OAuth with a test user that has read access only to the selected services, logs, and dashboards. This composite targets US1 and uses the `core` toolset.

### Sentry

This provider uses Dynamic Client Registration (DCR). Do **not** create or paste an OAuth client ID or client secret: after import, Dome registers the client and opens the provider's consent page.

After saving, complete OAuth with a test user that can view only the target organization and projects. Use project-scoped Sentry access wherever available.

### Slack

Before import, create a Slack app at [api.slack.com/apps](https://api.slack.com/apps). Choose **From scratch**, make it internal to the intended workspace, then copy the client ID and client secret from **Basic Information**. In **OAuth & Permissions**, add `https://api.domesystems.ai/oauth/callback` as a redirect URL. In **Agents**, enable **Slack Model Context Protocol (MCP) Server**. Add only the read/search/history/channel/user scopes requested by this template; do not add any write scope. Install or reinstall the app to the dedicated test workspace after changing scopes.

- `slack_oauth_client_id` and `slack_oauth_client_secret`: enter values from an approved internal Slack app.

In the Slack app's **Agents** section, enable the **Slack Model Context Protocol (MCP) Server** feature. Register Dome's redirect URI and grant only the template's search, history, channel, user, canvas-read, and list-read scopes. Do not add `chat:write`, file-write, canvas-write, or other write scopes.

### GitHub

GitHub's hosted MCP server supports OAuth, but does not expose Dynamic Client
Registration. Before import, create a GitHub OAuth app in the
[GitHub developer settings](https://github.com/settings/developers): select
**OAuth Apps**, then **New OAuth App**. Use a recognizable name, your
organization's homepage URL, and this callback URL:

```text
https://api.domesystems.ai/oauth/callback
```

After creating the app, copy its client ID and generate its client secret.
GitHub's [OAuth-app creation guide](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app)
has the current field-by-field instructions.

- `github_oauth_client_id` and `github_oauth_client_secret`: enter the GitHub
  OAuth app credentials. Configure the app's callback URL as
  `https://api.domesystems.ai/oauth/callback`.
- After import, start the shared GitHub OAuth connection and approve it as a
  dedicated test user. The template requests `public_repo` and `read:org`, and
  connects to GitHub's read-only MCP endpoint. This permits public-repository
  investigation while preventing the MCP server from exposing write tools.
- Before relying on the connection, verify the consent scopes and organization
  OAuth-app policy, then test one allowed public repository. GitHub OAuth does
  not have a read-only private-repository scope: do not grant `repo` merely to
  make this composite work. Keep repository administration, workflow, package,
  and organization-write access out of the authorization.

For a headless connection, use the separate fine-grained-PAT configuration and
limit it to the intended repositories with read-only permissions.

### GitLab

This provider uses Dynamic Client Registration (DCR). Do **not** create or paste an OAuth client ID or client secret: after import, Dome registers the client and opens the provider's consent page.

GitLab.com supports OAuth 2.0 Dynamic Client Registration for its hosted MCP
server, so this composite does not require a manually registered application or
an access token.

- After import, complete shared OAuth as a dedicated test member. The template
  requests GitLab's `mcp` scope; verify a known test project is
  visible and that an unshared private project is unavailable.

This composite targets GitLab.com. For a headless connection, use a separate
project, group, or personal access-token configuration with the same read-only
scopes. Use a separately reviewed template for a self-managed instance or a
write-capable workflow.

## Import and verify

1. Import the template and provide the values above.
2. Complete every browser OAuth flow with the intended dedicated test user. Token-based sources do not open a browser.
3. Open **Tools**, refresh discovery, and confirm every connection is attached to the template gateway.
4. Run the managed agent against known test data. Treat the template as verified only when the run succeeds **and calls at least one expected read-only tool**.

If a connection is unreachable, check the provider section above for its callback, API/MCP enablement, token prefix, consent scopes, and user/workspace access before retrying.