# Set up Report Repo Inventory

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

- `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

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

### Buildkite

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.

Buildkite's hosted read-only MCP endpoint uses OAuth with Dynamic Client
Registration. This composite uses `https://mcp.buildkite.com/mcp/readonly`, so
the upstream server issues read-only MCP permissions after consent.

- After import, start the shared Buildkite OAuth connection, sign in as a
  dedicated test user, select the intended organization, and approve consent.
- Verify a known test build is visible and that a build in an unshared pipeline
  is unavailable. Build creation, retry, cancellation, and other write tools
  should not be present.

For a headless service that cannot complete OAuth, Buildkite supports API-token
pass-through at `https://mcp.buildkite.com/direct`. That is a separate,
token-based connection—not this OAuth template.

### Netlify

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, authorize a test user restricted to the intended team and non-production sites. Do not use an identity allowed to modify deploys, environment variables, domains, or site configuration.

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

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