diff --git a/docs.json b/docs.json index bca96ae2..931424e4 100644 --- a/docs.json +++ b/docs.json @@ -124,6 +124,7 @@ "product/admin/mcp-server/google-analytics-admin", "product/admin/mcp-server/google-analytics", "product/admin/mcp-server/google-drive", + "product/admin/mcp-server/granola", "product/admin/mcp-server/hubspot", "product/admin/mcp-server/jira", "product/admin/mcp-server/jira-service-management", @@ -133,11 +134,13 @@ "product/admin/mcp-server/lucid", "product/admin/mcp-server/metabase", "product/admin/mcp-server/metronome", + "product/admin/mcp-server/monday", "product/admin/mcp-server/n8n", "product/admin/mcp-server/notion", "product/admin/mcp-server/okta", "product/admin/mcp-server/opsgenie", "product/admin/mcp-server/pagerduty", + "product/admin/mcp-server/pylon", "product/admin/mcp-server/ramp", "product/admin/mcp-server/rapid7", "product/admin/mcp-server/salesforce", diff --git a/product/admin/mcp-server/github.mdx b/product/admin/mcp-server/github.mdx index f1bc4cce..62ada7dc 100644 --- a/product/admin/mcp-server/github.mdx +++ b/product/admin/mcp-server/github.mdx @@ -1,18 +1,148 @@ --- title: Set up the GitHub MCP server -description: Connect GitHub to C1 with per-user OAuth or a personal access token, then register the GitHub MCP server and govern its tools. +description: Connect GitHub to C1 through the GitHub API or GitHub's own hosted MCP server, then register the server and govern its tools. og:title: Set up the GitHub MCP server -og:description: Connect GitHub to C1 with per-user OAuth or a personal access token, then register the GitHub MCP server and govern its tools. +og:description: Connect GitHub to C1 through the GitHub API or GitHub's own hosted MCP server, then register the server and govern its tools. sidebarTitle: GitHub --- -{/* Editor Refresh: 2026-06-11 */} +{/* Editor Refresh: 2026-07-24 */} **Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough. -The GitHub MCP server lets you govern access to GitHub — repositories, pull requests, issues, Actions, and organization data — as tools your AI clients can call through C1. +C1 can govern GitHub access two ways. Both let your AI clients read from and act on GitHub through governed MCP tools, but they come from different places and appear as two separate entries in your MCP server catalog: + +- **GitHub MCP** — listed as plain **GitHub** in your catalog. C1 registers GitHub's own hosted MCP server (`api.githubcopilot.com`) as a downstream server C1 governs. GitHub doesn't support dynamic client registration (DCR), so authentication is per-user OAuth through a GitHub OAuth App you register once, or a shared personal access token. Tool calls run with the connected user's granted OAuth scopes (or the token's permissions), against GitHub's own broader tool set — including cross-item search, discussions, and security alerts. +- **GitHub API** — C1 hosts its own MCP server that translates GitHub's REST API into tools. You choose between per-user OAuth or a shared personal access token, and access follows the OAuth app's requested scopes or the token's repository permissions. + +| | GitHub MCP | GitHub API | +| :--- | :--- | :--- | +| **Who hosts the MCP server** | GitHub | C1 | +| **Authentication** | Per-user OAuth (no dynamic client registration — requires a GitHub OAuth App), or a personal access token | Per-user OAuth (requires a GitHub OAuth App), or a personal access token | +| **Access scoping** | The OAuth scopes granted at authorization, or the personal access token's permissions | The OAuth app's requested scopes, or the personal access token's repository permissions | +| **Tool surface** | GitHub's own tool set: repositories, issues, pull requests, Actions workflows, discussions, security alerts, and notifications | Repositories, pull requests, issues, Actions, and organization data, mapped to GitHub API endpoints | +| **Setup effort** | Register a GitHub OAuth App (or generate a token), then register in C1 | Register a GitHub OAuth App (or generate a token), then register in C1 | + +Use the native **GitHub MCP** option (listed as plain **GitHub** in your catalog) if you want GitHub's own broader, agentic tool set, including cross-item search, discussions, and security alerts. Use **GitHub API** if you want C1's own curated tool surface mapped directly to GitHub API endpoints. + + + + + +C1 registers as a client of GitHub's own hosted MCP server ([GitHub MCP Server](https://github.com/github/github-mcp-server)) rather than translating GitHub's REST API itself. Your users' AI clients still only ever see C1-governed MCP tools, but C1 proxies each tool call straight through to `api.githubcopilot.com` under the connected user's authorized session, then returns the result. The tools available are exactly the ones GitHub's hosted MCP server exposes — C1 doesn't reshape or add to them. + +## Before you begin + +- AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). +- GitHub doesn't support dynamic client registration (DCR) for this server, so — unlike some native MCP integrations — there's a one-time setup step in GitHub first: register a GitHub OAuth App and provide its client ID and secret. See **Set up per-user OAuth** below. +- If you'd rather not register an OAuth App, this option also accepts a GitHub personal access token as a shared bearer credential. See **Use a personal access token instead** below. + + +In your MCP server catalog, this option is listed as **GitHub** — distinct from the **GitHub API** entry, which connects through C1's own MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. + + +## Set up per-user OAuth + +Per-user OAuth is the recommended way to connect — each user authorizes individually, and every tool call runs under their own GitHub identity and permissions. Unlike C1's other native MCP integrations, GitHub doesn't support dynamic client registration for this server, so you need to register a GitHub OAuth App yourself before C1 can prompt users to connect. + +First, create a GitHub OAuth App that users will authorize through: + + + +In GitHub, go to **Settings** > **Developer settings** > **OAuth Apps** and select **New OAuth App** (or **Register a new application** if this is your first one). See GitHub's [guide to creating an OAuth app](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app). + + +Fill in the registration form: + +- **Application name** — a recognizable name such as `C1`. +- **Homepage URL** — your C1 tenant URL, or `https://www.c1.ai`. +- **Authorization callback URL** — set this exactly to `https://accounts.conductor.one/auth/callback`. GitHub OAuth Apps allow only one callback URL, unlike GitHub Apps. + + +Select **Register application**, then copy the **Client ID**. Select **Generate a new client secret** and copy the secret — GitHub shows it only once. Store it securely, and if it's ever exposed, generate a new one, update C1, then delete the old one ([best practices for creating an OAuth app](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/best-practices-for-creating-an-oauth-app)). + + + +With your OAuth app ready, register the server and provide its credentials: + + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **GitHub** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — per-user passthrough** and enter your OAuth app's **client ID** and **client secret**. + + +Save your changes. The first time a user calls a GitHub tool from their AI client, they're redirected to GitHub to sign in (if they aren't already) and approve the requested scopes, then returned to C1 ([authorizing OAuth apps](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps)). + + + +## What access is granted + +When a user authorizes, C1 requests these scopes on GitHub's consent screen ([scopes for OAuth apps](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps)): + +- `repo` — full read/write access to public and private repositories, including code, commit statuses, invitations, collaborators, deployment statuses, and webhooks. +- `read:org` — read-only access to organization membership, organization projects, and team membership. +- `read:user` and `user:email` — read access to the user's profile data and email addresses. +- `read:packages` and `write:packages` — download/install and upload/publish access to GitHub Packages. +- `read:project` and `project` — read-only and read/write access to user and organization projects. +- `gist` — write access to gists. +- `notifications` — read access to the user's notifications, plus mark-as-read and subscription management. +- `workflow` — the ability to add and update GitHub Actions workflow files. +- `codespace` — the ability to create and manage codespaces. + +Tool calls then run with the connected user's own GitHub permissions across whichever of these scopes they hold — for example, a user without `write:packages` can't publish a package through a GitHub tool even though C1 requested that scope. + +## Use a personal access token instead + +If you'd rather not register an OAuth App, GitHub's hosted MCP server also accepts a personal access token (PAT) — classic or fine-grained — as a shared bearer credential that authenticates every user as one identity. + + + +In GitHub, generate a token under **Settings** > **Developer settings** > **Personal access tokens**. GitHub recommends **fine-grained tokens**, which you can scope to specific repositories and permissions ([types of personal access tokens](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#types-of-personal-access-tokens)); a classic token works too, but it can reach every repository you can access. + + +Copy the token — GitHub shows it only once. + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **GitHub** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **Bearer token** and paste the token. C1 sends it as `Authorization: Bearer ` on every request. + + + +## How GitHub MCP credentials are shared + +- **Per-user OAuth.** Each user authorizes with their own GitHub account, so tool calls run under that user's GitHub identity and inherit only the scopes they granted. GitHub attributes each action to the individual user. +- **Personal access token.** Every user's tool calls use the one token you provided, so GitHub sees a single shared identity. C1 still attributes each call to the individual user in the [AI tool usage audit log](/product/admin/audit-ai-tool-usage). + +## Discover and govern tools + +After you register the server, C1 runs tool discovery against GitHub's hosted MCP server. Discovered tools appear on the server's **Tools** tab. + +Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification). + +Before anyone can call a GitHub tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up. + + +Tool discovery runs even if authentication isn't complete yet, so seeing discovered tools doesn't confirm a user has authorized. You confirm access when an approved user successfully calls a GitHub tool from their AI client. + + +## Manage access to GitHub MCP + +- **Rotate the OAuth client secret** on your OAuth app's settings page in GitHub (**Settings** > **Developer settings** > **OAuth Apps**), then update the secret on the server's authentication settings in C1. +- **Rotate a personal access token** by generating a new one in GitHub and updating it in C1. Set an expiration on the token so it rotates on a schedule. +- **An individual user can revoke their own authorization at any time.** In GitHub, go to **Settings** > **Applications** > **Authorized OAuth Apps**, then select **Revoke** next to C1 ([reviewing your authorized OAuth apps](https://docs.github.com/en/apps/oauth-apps/using-oauth-apps/reviewing-your-authorized-oauth-apps)). +- **An organization owner can restrict or revoke OAuth App access org-wide** if the organization has third-party application access restrictions enabled ([about OAuth App access restrictions](https://docs.github.com/en/organizations/managing-oauth-access-to-your-organizations-data/about-oauth-app-access-restrictions)). + + + + + +C1 hosts the GitHub MCP server, so your users' AI clients only ever see MCP tools — they never call GitHub directly. When an AI client calls one of these tools, C1 makes the matching request to the GitHub API using the credentials you configure here, then returns the result to the AI client. The credentials you set up below are what C1 uses to call GitHub on your users' behalf. GitHub supports two ways to authenticate, and you choose one when you register the server: @@ -21,12 +151,6 @@ GitHub supports two ways to authenticate, and you choose one when you register t For a deeper comparison of shared versus per-user credentials, see [Configure authentication](/product/admin/mcp-servers#configure-authentication). -## How C1 connects to GitHub - -C1 hosts the GitHub MCP server, so your users' AI clients only ever see MCP tools — they never call GitHub directly. When an AI client calls one of these tools, C1 makes the matching request to the GitHub API using the credentials you configure here, then returns the result to the AI client. - -The credentials you set up below are what C1 uses to call GitHub on your users' behalf. - ## Before you begin - AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). @@ -34,7 +158,7 @@ The credentials you set up below are what C1 uses to call GitHub on your users' - For a personal access token, you need the GitHub account whose access the token should carry. -If you don't see **GitHub** in your MCP server catalog, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. +In your MCP server catalog, this option is listed as **GitHub API** — distinct from the **GitHub** entry, which connects to GitHub's own hosted MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. ## Option 1: Set up per-user OAuth @@ -70,7 +194,7 @@ With your OAuth app ready, register the server and provide its credentials. -Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **GitHub** from the catalog. +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **GitHub API** from the catalog. When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose per-user OAuth and enter your OAuth app's **client ID** and **client secret**. @@ -86,7 +210,7 @@ A personal access token authenticates every user as one shared GitHub identity. ### Create a personal access token -Generate a fine-grained personal access token in GitHub for C1 to authenticate with. For the full walkthrough, see GitHub's [guide to managing personal access tokens](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens). +Generate a fine-grained personal access token in GitHub for C1 to authenticate with. For the full walkthrough, see GitHub's [guide to creating a fine-grained personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token). @@ -111,7 +235,7 @@ With your token ready, register the server and provide it as the credential. -Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **GitHub** from the catalog. +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **GitHub API** from the catalog. When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **Bearer token** and paste your personal access token. @@ -121,7 +245,7 @@ Save your changes. C1 starts a sync that discovers the tools the GitHub server e -## How GitHub credentials are shared +## How GitHub API credentials are shared How GitHub sees your users' activity depends on the method you chose: @@ -147,3 +271,7 @@ Tool discovery runs even if your credentials are incorrect, so seeing discovered - **Rotate the OAuth client secret** in your GitHub OAuth app under **Settings** > **Developer settings** > **OAuth Apps**, then update the secret on the server's authentication settings in C1. - **Rotate a personal access token** by generating a new one in GitHub and updating it in C1. Set an expiration on the token so it rotates on a schedule. - **Adjust access** by editing the OAuth app's scopes or the token's repository permissions in GitHub. + + + + diff --git a/product/admin/mcp-server/google-drive.mdx b/product/admin/mcp-server/google-drive.mdx index 2a101171..a0551860 100644 --- a/product/admin/mcp-server/google-drive.mdx +++ b/product/admin/mcp-server/google-drive.mdx @@ -1,18 +1,115 @@ --- title: Set up the Google Drive MCP server -description: Connect Google Drive to C1 with per-user OAuth or a service account, then register the Google Drive MCP server and govern its tools. +description: Connect Google Drive to C1 through the Google Drive API or Google's own hosted MCP server, then register the server and govern its tools. og:title: Set up the Google Drive MCP server -og:description: Connect Google Drive to C1 with per-user OAuth or a service account, then register the Google Drive MCP server and govern its tools. +og:description: Connect Google Drive to C1 through the Google Drive API or Google's own hosted MCP server, then register the server and govern its tools. sidebarTitle: Google Drive --- -{/* Editor Refresh: 2026-06-11 */} +{/* Editor Refresh: 2026-07-24 */} **Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough. -The Google Drive MCP server lets you govern access to Google Drive — files, folders, shared drives, permissions, comments, and revisions — as tools your AI clients can call through C1. +C1 can govern Google Drive access two ways. Both let your AI clients read from and act on Drive through governed MCP tools, but they come from different places and appear as two separate entries in your MCP server catalog: + +- **Google Drive MCP** — listed as plain **Google Drive** in your catalog. C1 registers Google's own hosted Drive MCP server (`drivemcp.googleapis.com`) as a downstream server C1 governs. Authentication is per-user OAuth using a Google Cloud OAuth client you create — Google doesn't support dynamic client registration (DCR) for this server, so there's no bearer token or API key fallback either. Tool calls run with the connected user's own Drive permissions, scoped to whichever OAuth scopes you grant. +- **Google Drive API** — C1 hosts its own MCP server that translates the Google Drive REST API into tools. You choose between per-user OAuth or a service account with domain-wide delegation (Workspace only), and you scope access with the OAuth or delegated scopes you configure. + +| | Google Drive MCP | Google Drive API | +| :--- | :--- | :--- | +| **Who hosts the MCP server** | Google | C1 | +| **Authentication** | Per-user OAuth with a Google Cloud OAuth client you create — no dynamic client registration, bearer token, or API key option | Per-user OAuth, or a service account with domain-wide delegation (Workspace only) | +| **Access scoping** | The connected user's Drive permissions, within the OAuth scopes you grant (`drive`, `drive.readonly`, or `drive.file`) | The OAuth scopes you configure, or the scopes you delegate to the service account | +| **Tool surface** | Google's own fixed tool set: search, read and download content, file metadata, permissions, recent files, plus file creation and copying | Files, folders, shared drives, permissions, comments, and revisions, mapped to Drive API endpoints | +| **Setup effort** | Create a Google Cloud OAuth client and enable the Drive MCP API, then register in C1 | Create an OAuth client or service account first, then register in C1 | + +Use the native **Google Drive MCP** option (listed as plain **Google Drive** in your catalog) if Google's own tool set covers what you need and per-user OAuth is acceptable for your tenant. Use **Google Drive API** if you need a shared service-account credential, or you want the broader tool surface — including permissions, comments, and revisions — that C1's own translation provides. + + + + + +C1 registers as a client of Google's own hosted Drive MCP server ([Configure the Drive MCP server](https://developers.google.com/workspace/drive/api/guides/configure-mcp-server)) rather than translating the Google Drive REST API itself. Your users' AI clients still only ever see C1-governed MCP tools, but C1 proxies each tool call straight through to `drivemcp.googleapis.com` under the connected user's authorized session, then returns the result. The tools available are exactly the ones Google's own MCP server exposes — C1 doesn't reshape or add to them. + +## Before you begin + +- AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). +- A Google Cloud project with an OAuth client — see [Set up a Google Cloud project for MCP servers](/product/admin/mcp-server/google-cloud-project-setup). This option additionally requires enabling the **Google Drive MCP API** in that project (covered below); the shared guide doesn't cover that API since it's specific to this option. +- Each user needs a Google account with access to the Drive content you want their AI client to reach. + + +In your MCP server catalog, this option is listed as **Google Drive** — distinct from the **Google Drive API** entry, which connects through C1's own MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. + + +## Set up per-user OAuth + +Per-user OAuth with a Google Cloud OAuth client is the only authentication method this option supports — Google doesn't offer dynamic client registration, a bearer token, or an API key for its hosted Drive MCP server. Each user authorizes individually with their own Google account. + +### Create a Google OAuth client + +If you already completed [Set up a Google Cloud project for MCP servers](/product/admin/mcp-server/google-cloud-project-setup) for another Google connector, you can reuse that project and OAuth client — you only need to enable one additional API and add the Drive MCP scopes. + + + +Follow [Set up a Google Cloud project for MCP servers](/product/admin/mcp-server/google-cloud-project-setup) to create or select a project, grant your users the **Service Usage Consumer** role, and create an OAuth client with the redirect URI set to `https://accounts.conductor.one/auth/callback`. + + +In the same project, also enable the **Google Drive MCP API** (`drivemcp.googleapis.com`): go to **APIs & Services** > **Library**, search for **Google Drive MCP API**, and select **Enable**. Google's hosted Drive MCP server requires this API alongside the Google Drive API. See Google's [Enable the MCP services](https://developers.google.com/workspace/drive/api/guides/configure-mcp-server#enable-mcp-services) documentation. + + +On the OAuth consent screen's **Data Access** page, add the scopes you want to grant: `https://www.googleapis.com/auth/drive` for full read/write access, `https://www.googleapis.com/auth/drive.readonly` for read-only access, or `https://www.googleapis.com/auth/drive.file` to limit access to files a user opens or creates through the connection. + + + +### Register the server with OAuth + +With your OAuth client ready, register the server and provide its credentials. + + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Google Drive** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — per-user passthrough** and enter your OAuth client's **client ID**, **client secret**, and the scopes you configured. There's no **Use dynamic client registration** toggle for this server — Google doesn't support it. + + +Save your changes. The first time a user calls a Google Drive tool from their AI client, they're prompted to connect their Google account. + + + +## What access is granted + +Once a user authorizes, tool calls run with that user's own Drive permissions, limited to whichever OAuth scope you configured — `drive` for full read/write access to their Drive, `drive.readonly` for read-only access, or `drive.file` for access limited to files the user opens or creates through the connection. Google's hosted server exposes its own fixed tool set for searching, reading, and managing files — `search_files`, `list_recent_files`, `get_file_metadata`, `get_file_permissions`, `download_file_content`, `read_file_content`, `create_file`, and `copy_file` (see Google's [MCP Reference: drivemcp.googleapis.com](https://developers.google.com/workspace/drive/api/reference/mcp)). + +## How Google Drive MCP credentials are shared + +This option only supports per-user OAuth — there's no shared, service-account, or bearer-token mode. Every tool call runs under the calling user's own Google identity, and Google attributes each action to that individual. C1 still attributes each call to the individual user in the [AI tool usage audit log](/product/admin/audit-ai-tool-usage). + +## Discover and govern tools + +After you register the server, C1 runs tool discovery against Google's Drive MCP server. Discovered tools appear on the server's **Tools** tab and include Google's own search, file content, metadata, permissions, and file creation and copying tools. + +Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification). + +Before anyone can call a Google Drive tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up. + + +Tool discovery runs even if authentication isn't complete yet, so seeing discovered tools doesn't confirm a user has authorized. You confirm access when an approved user successfully calls a Google Drive tool from their AI client. + + +## Manage access to Google Drive MCP + +- **Rotate the OAuth client secret** in your Google Cloud project under **APIs & Services** > **Credentials**, then update the secret on the server's authentication settings in C1. +- **Adjust scopes** by editing them on the OAuth consent screen's **Data Access** page; users must reconnect their Google account to grant any newly added scopes. +- **An individual user can revoke access at any time** from their Google Account's linked apps page. See Google's [Manage third-party apps & services with access to your account](https://support.google.com/accounts/answer/3466521) documentation. + + + + + +C1 hosts the Google Drive MCP server, so your users' AI clients only ever see MCP tools — they never call Google Drive directly. When an AI client calls one of these tools, C1 makes the matching request to the Google Drive API using the credentials you configure here, then returns the result to the AI client. The credentials you set up below are what C1 uses to call Google Drive on your users' behalf. Google Drive supports two ways to authenticate, and you choose one when you register the server: @@ -21,12 +118,6 @@ Google Drive supports two ways to authenticate, and you choose one when you regi For a deeper comparison of shared versus per-user credentials, see [Configure authentication](/product/admin/mcp-servers#configure-authentication). -## How C1 connects to Google Drive - -C1 hosts the Google Drive MCP server, so your users' AI clients only ever see MCP tools — they never call Google Drive directly. When an AI client calls one of these tools, C1 makes the matching request to the Google Drive API using the credentials you configure here, then returns the result to the AI client. - -The credentials you set up below are what C1 uses to call Google Drive on your users' behalf. - ## Before you begin - AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). @@ -34,7 +125,7 @@ The credentials you set up below are what C1 uses to call Google Drive on your u - For the service-account option, a Google Workspace administrator to set up [domain-wide delegation](https://knowledge.workspace.google.com/admin/apps/control-api-access-with-domain-wide-delegation). -If you don't see **Google Drive** in your MCP server catalog, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. +In your MCP server catalog, this option is listed as **Google Drive API** — distinct from the **Google Drive** entry, which connects to Google's own hosted MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. ## Option 1: Set up per-user OAuth @@ -74,10 +165,10 @@ With your OAuth client ready, register the server and provide its credentials. -Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Google Drive** from the catalog. +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Google Drive API** from the catalog. -When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose per-user OAuth and enter your OAuth client's **client ID** and **client secret**, plus the scopes you configured. Also enter the **Google Cloud Quota Project ID** — the ID of the project where you enabled the Google Drive API and granted users the Service Usage Consumer role. +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — per-user passthrough** and enter your OAuth client's **client ID** and **client secret**, plus the scopes you configured. Also enter the **Google Cloud Quota Project ID** — the ID of the project where you enabled the Google Drive API and granted users the Service Usage Consumer role. Save your changes. The first time a user calls a Google Drive tool from their AI client, they're prompted to connect their Google account. @@ -113,7 +204,7 @@ With your service account ready, register the server and provide its key. -Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Google Drive** from the catalog. +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Google Drive API** from the catalog. When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **JWT Bearer (RFC 7523)** and provide the service account's JSON key and the scopes you delegated. @@ -123,7 +214,7 @@ Save your changes. C1 starts a sync that discovers the tools the Google Drive se -## How Google Drive credentials are shared +## How Google Drive API credentials are shared How Google Drive sees your users' activity depends on the method you chose: @@ -144,8 +235,12 @@ Before anyone can call a Google Drive tool, it must be approved, added to a tool Tool discovery runs even if your credentials are incorrect, so seeing discovered tools doesn't confirm that authentication is working. You confirm your Google Drive credentials when an approved user successfully calls a Google Drive tool from their AI client. -## Manage your Google Drive credentials +## Manage your Google Drive API credentials - **Rotate the OAuth client secret** in your Google Cloud project under **APIs & Services** > **Credentials**, then update the secret on the server's authentication settings in C1. - **Rotate the service account key** by generating a new JSON key in the Cloud Console, updating it in C1, then deleting the old key. - **Adjust access** by editing the OAuth client's scopes, or the scopes granted to the service account in domain-wide delegation. + + + + diff --git a/product/admin/mcp-server/granola.mdx b/product/admin/mcp-server/granola.mdx new file mode 100644 index 00000000..19b983f2 --- /dev/null +++ b/product/admin/mcp-server/granola.mdx @@ -0,0 +1,158 @@ +--- +title: Set up the Granola MCP server +description: Connect Granola to C1 through Granola's own hosted MCP server or the Granola API, then register the server and govern its tools. +og:title: Set up the Granola MCP server +og:description: Connect Granola to C1 through Granola's own hosted MCP server or the Granola API, then register the server and govern its tools. +sidebarTitle: Granola +--- + +{/* Editor Refresh: 2026-07-24 */} + + +**Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough. + + +C1 can govern [Granola](https://www.granola.ai) — an AI meeting-notes app — access two ways. Both let your AI clients read from Granola through governed MCP tools, but they come from different places and appear as two separate entries in your MCP server catalog: + +- **Granola MCP** — listed as plain **Granola** in your catalog. C1 registers Granola's own hosted MCP server (`mcp.granola.ai`) as a downstream server C1 governs. Authentication is always per-user OAuth using dynamic client registration (DCR) — Granola's hosted MCP server doesn't support a bearer token or API key, so there's no integration to create in Granola first. Tool calls run with the connected user's own Granola access, scoped to their active workspace. +- **Granola API** — C1 hosts its own MCP server that translates Granola's REST API into tools. Authentication is a single shared bearer token (a Granola API key), so every tool call reaches Granola as one identity. + +| | Granola MCP | Granola API | +| :--- | :--- | :--- | +| **Who hosts the MCP server** | Granola | C1 | +| **Authentication** | Per-user OAuth with dynamic client registration (DCR) only — no bearer token or API key option | Bearer token (a Granola API key) only — no OAuth option | +| **Access scoping** | The connected user's own Granola access, for their active workspace | Whatever notes the API key's access scope (personal and/or public notes) covers | +| **Tool surface** | Granola's own meeting-notes tools: searching meeting history, browsing folders, listing meetings, and reading full notes | Granola's meeting-data REST endpoints, mapped to tools | +| **Setup effort** | Register in C1 and authorize — nothing to create in Granola first | Generate a Granola API key first, then register it in C1 | + +Use the native **Granola MCP** option (listed as plain **Granola** in your catalog) if per-user OAuth is acceptable for your tenant and you want each user's tool calls attributed to them individually. Use **Granola API** if you need a single shared credential instead. + + + + + +C1 registers as a client of Granola's own hosted MCP server ([Granola MCP](https://docs.granola.ai/help-center/sharing/integrations/mcp)) rather than translating Granola's REST API itself. Your users' AI clients still only ever see C1-governed MCP tools, but C1 proxies each tool call straight through to `mcp.granola.ai` under the connected user's authorized session, then returns the result. The tools available are exactly the ones Granola's own MCP server exposes — C1 doesn't reshape or add to them. + +## Before you begin + +- AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). +- Nothing to create in Granola ahead of time. This option only supports per-user OAuth with dynamic client registration — Granola's hosted MCP server doesn't offer a bearer token or API key mode, so there's no client ID, secret, or integration to register. Each user just needs a Granola account with access to the workspace whose notes they want tools to reach. + + +In your MCP server catalog, this option is listed as **Granola** — distinct from the **Granola API** entry, which connects through C1's own MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. + + +## Set up per-user OAuth + +Per-user OAuth with dynamic client registration (DCR) is the only authentication method this option supports — there's no bearer token or API key fallback. Each user authorizes individually through their browser, signing in with the Granola account tied to their workspace, and C1 registers itself with Granola's authorization server automatically, so there's no app to create in Granola first (see Granola's [Granola MCP](https://docs.granola.ai/help-center/sharing/integrations/mcp#do-i-need-a-client-id-or-client-secret) documentation). + + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Granola** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — per-user passthrough** and enable **Use dynamic client registration**. There's no client ID or secret to enter. + + +Save your changes. The first time a user calls a Granola tool from their AI client, they're redirected to sign in with their Granola account (if they aren't already) and approve the connection, then returned to C1. + + + +## What access is granted + +Unlike the Granola API option, there are no separate capability toggles to configure. Once a user authorizes, tool calls run with that user's own Granola access, scoped to their active workspace and the note categories (personal and shared/public) they can already reach in Granola ([Granola MCP](https://docs.granola.ai/help-center/sharing/integrations/mcp#what-mcp-can-access)). + +## How Granola MCP credentials are shared + +This option only supports per-user OAuth — there's no shared, service-account, or bearer-token mode. Every tool call runs under the calling user's own Granola identity. C1 still attributes each call to the individual user in the [AI tool usage audit log](/product/admin/audit-ai-tool-usage). + +## Discover and govern tools + +After you register the server, C1 runs tool discovery against Granola's MCP server. Discovered tools appear on the server's **Tools** tab and include Granola's meeting-notes search, folder browsing, meeting listing, and note-reading tools. + +Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification). + +Before anyone can call a Granola tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up. + + +Tool discovery runs even if authentication isn't complete yet, so seeing discovered tools doesn't confirm a user has authorized. You confirm access when an approved user successfully calls a Granola tool from their AI client. + + +## Manage access to Granola MCP + +Because this option uses per-user OAuth, there's no shared secret in C1 to rotate. Granola's own published documentation ([Granola MCP](https://docs.granola.ai/help-center/sharing/integrations/mcp#claude-shows-no-tools-available)) doesn't describe a centralized, self-service page in Granola for listing or revoking individual MCP connections — the documented way to disconnect is from the connected AI client itself (for example, in Claude, opening the Granola connector's settings and choosing to disconnect it, then reconnecting to re-authorize). If your tenant needs a connection revoked and you can't do it from the AI client side, contact Granola support to confirm the current process, since this is an area where Granola's own controls may change. + + + + + +C1 hosts the Granola MCP server, so your users' AI clients only ever see MCP tools — they never call Granola directly. When an AI client calls one of these tools, C1 makes the matching request to Granola's REST API using the credentials you configure here, then returns the result to the AI client. + +Granola supports one authentication method for its API: a bearer token (a Granola API key). Every tool call reaches Granola as the same identity, so there's no per-user attribution on the Granola side. + +## Before you begin + +- AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). +- You need access to generate a Granola API key. On Granola's Business plan, any workspace member can create a personal API key; on Granola's Enterprise plan, a workspace admin must first enable API key access for members before a key can be created. See Granola's [API documentation](https://docs.granola.ai/introduction#api-key-access-scopes). + + +In your MCP server catalog, this option is listed as **Granola API** — distinct from the **Granola** entry, which connects to Granola's own hosted MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. + + +## Generate a Granola API key + + + +In the Granola app, go to **Settings** > **Connectors** > **API keys**, then select **Create new key**. + + +Choose the note access scope for the key — **personal notes**, **public notes** (workspace-visible and Team space content), or both — depending on what C1 should be able to read. + + +Select **Generate API Key**, then copy the key. Treat it as a high-value credential; Granola API keys are bearer tokens and Granola won't show the full value again after you leave the page. + + + +For a shared production setup, generate the key from a dedicated service-account workspace member so activity is attributable to C1 rather than a person. + +With your API key ready, register the server and provide it to C1: + + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Granola API** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **Bearer token** and paste your Granola API key. + + +Save your changes. C1 starts a sync that discovers the tools the Granola API exposes. + + + +## How Granola API credentials are shared + +Every user's tool calls use the one API key you provided, so Granola sees a single shared identity for all activity. C1 still attributes each call to the individual user in the [AI tool usage audit log](/product/admin/audit-ai-tool-usage). + +For how shared and per-user credentials work across MCP servers, see [Configure authentication](/product/admin/mcp-servers#configure-authentication). + +## Discover and govern tools + +After you register the server, C1 runs tool discovery against Granola. Discovered tools appear on the server's **Tools** tab. + +Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification). + +Before anyone can call a Granola tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up. + + +Tool discovery runs even if your credentials are incorrect, so seeing discovered tools doesn't confirm that authentication is working. You confirm your Granola API key when an approved user successfully calls a Granola tool from their AI client. + + +## Manage your Granola API credentials + +- **Rotate the API key** by generating a new key in Granola (**Settings** > **Connectors** > **API keys**) and updating it on the server's authentication settings in C1. +- **Revoke a key** from the same page in Granola. Once revoked, a key is permanently disabled and cannot be restored — generate a new one and update it in C1 to keep the integration working. +- **Adjust access** by generating a new key with a different note access scope, since a key's scope is set when it's created. + + + + diff --git a/product/admin/mcp-server/linear.mdx b/product/admin/mcp-server/linear.mdx index 54ffa1d6..f3833234 100644 --- a/product/admin/mcp-server/linear.mdx +++ b/product/admin/mcp-server/linear.mdx @@ -1,17 +1,136 @@ --- title: Set up the Linear MCP server -description: Connect Linear to C1 with per-user OAuth or a personal API key, then register the Linear MCP server and govern its tools. +description: Connect Linear to C1 through Linear's own hosted MCP server or the Linear API, then register the server and govern its tools. og:title: Set up the Linear MCP server -og:description: Connect Linear to C1 with per-user OAuth or a personal API key, then register the Linear MCP server and govern its tools. +og:description: Connect Linear to C1 through Linear's own hosted MCP server or the Linear API, then register the server and govern its tools. sidebarTitle: Linear --- -{/* Editor Refresh: 2026-06-11 */} +{/* Editor Refresh: 2026-07-24 */} **Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough. +C1 can govern Linear access two ways. Both let your AI clients read from and act on Linear through governed MCP tools, but they come from different places and appear as two separate entries in your MCP server catalog: + +- **Linear MCP** — listed as plain **Linear** in your catalog. C1 registers Linear's own hosted MCP server (`mcp.linear.app`) as a downstream server C1 governs. The recommended authentication method is per-user OAuth with dynamic client registration (DCR) — nothing to register in Linear first. Linear's MCP server also accepts a personal API key sent as a bearer token, if you'd rather use a single shared credential. +- **Linear API** — C1 hosts its own MCP server that translates the Linear API into tools. You choose between per-user OAuth (which requires creating a Linear OAuth application) or a personal API key, and scope access with the OAuth scopes or API key permissions you grant. + +| | Linear MCP | Linear API | +| :--- | :--- | :--- | +| **Who hosts the MCP server** | Linear | C1 | +| **Authentication** | Per-user OAuth with dynamic client registration (DCR), or a personal API key (bearer token) | Per-user OAuth (requires a Linear OAuth application), or a personal API key (bearer token) | +| **Access scoping** | The connected user's full Linear permissions with OAuth; a personal API key can be restricted to Read, Write, Admin, Create issues, Create comments, and specific teams | The OAuth scopes or API key permissions you configure | +| **Tool surface** | Linear's own tool set: finding, creating, and updating issues, projects, and comments, with more functionality on the way | Issues, projects, cycles, teams, users, and comments, mapped to Linear API endpoints | +| **Setup effort** | Register in C1 and authorize — nothing to create in Linear first for OAuth | Create a Linear OAuth application first (for per-user OAuth), then register it in C1 | + +Use the native **Linear MCP** option (listed as plain **Linear** in your catalog) if you want Linear's own hosted tool set and dynamic client registration is acceptable for your tenant. Use **Linear API** if you need to create a dedicated OAuth application, or you want to scope access with the Linear API's own permission model. + + + + + +C1 registers as a client of Linear's own hosted MCP server ([MCP server](https://linear.app/docs/mcp)) rather than translating the Linear API itself. Your users' AI clients still only ever see C1-governed MCP tools, but C1 proxies each tool call straight through to `mcp.linear.app` under the connected user's authorized session (or a shared bearer credential, if you choose that method instead), then returns the result. The tools available are exactly the ones Linear's own MCP server exposes — C1 doesn't reshape or add to them. + +## Before you begin + +- AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). +- For per-user OAuth with dynamic client registration, nothing to create in Linear ahead of time — C1 registers itself with Linear's authorization server automatically. Each user just needs a Linear account with access to the workspace. +- For a personal API key, you need the Linear account whose access the key should carry. + + +In your MCP server catalog, this option is listed as **Linear** — distinct from the **Linear API** entry, which connects through C1's own MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. + + +Linear's MCP server (`https://mcp.linear.app/mcp`) supports two ways to authenticate: + +- **Per-user OAuth with dynamic client registration** (recommended). Each person authorizes with their own Linear account, and C1 registers itself with Linear's authorization server automatically — there's no OAuth application to create in Linear first ([MCP server](https://linear.app/docs/mcp)). +- **Personal API key**. A single key authenticates everyone, sent as a bearer token, so all tool calls reach Linear's MCP server as one shared identity. + +## Option 1: Set up per-user OAuth with dynamic client registration + +Linear's MCP server supports OAuth 2.1 with dynamic client registration ([MCP server](https://linear.app/docs/mcp#setup)), so there's no OAuth application to register in advance. + + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Linear** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — per-user passthrough** and enable **Use dynamic client registration**. There's no client ID or secret to enter. + + +Save your changes. The first time a user calls a Linear tool from their AI client, they're redirected to Linear to sign in (if they aren't already) and approve the connection, then returned to C1. + + + +## Option 2: Use a personal API key + +Linear's MCP server also accepts a personal API key sent as a bearer credential instead of the interactive OAuth flow ([MCP server](https://linear.app/docs/mcp#collapsible-28a2f832a8df)). Use this when per-user attribution isn't required. + +### Create a personal API key + + + +Sign in to Linear as the account C1 should run as, then open **Settings** > **Security & access**. + + +Under **Personal API keys**, select **Create key**. + + +Enter a label such as `C1`, then choose full access or restrict the key to specific permissions — **Read**, **Write**, **Admin**, **Create issues**, **Create comments** — and optionally limit it to specific teams ([API and webhooks](https://linear.app/docs/api-and-webhooks)). + + +Copy the generated key. + + + +For a read-only connection, restrict the key to the **Read** permission only. For a shared production setup, create the key from a dedicated service-account user so activity is attributable to C1 rather than a person. + +### Register the server with a key + + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Linear** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **Bearer token** and paste your personal API key. + + +Save your changes. C1 starts a sync that discovers the tools Linear's MCP server exposes. + + + +## What access is granted + +With per-user OAuth, tool calls run with the connected user's own Linear permissions — they can access everything the user can already access in Linear, including issues, projects, and comments ([MCP server](https://linear.app/docs/mcp)). With a personal API key, tool calls run with whatever permissions the key was scoped to, up to the full access of the account that created it ([API and webhooks](https://linear.app/docs/api-and-webhooks)). + +## How Linear MCP credentials are shared + +- **Per-user OAuth.** Every tool call runs under the calling user's own Linear identity, and Linear attributes each action to that individual. +- **Personal API key.** Every user's tool calls use the one key you provided, so Linear sees a single shared identity. C1 still attributes each call to the individual user in the [AI tool usage audit log](/product/admin/audit-ai-tool-usage). + +## Discover and govern tools + +After you register the server, C1 runs tool discovery against Linear's MCP server. Discovered tools appear on the server's **Tools** tab and include Linear's own tools for finding, creating, and updating issues, projects, and comments. + +Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification). + +Before anyone can call a Linear tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up. + + +Tool discovery runs even if authentication isn't complete yet, so seeing discovered tools doesn't confirm a user has authorized or that a key is valid. You confirm access when an approved user successfully calls a Linear tool from their AI client. + + +## Manage access to Linear MCP + +- **Rotate or revoke a personal API key** in Linear under **Settings** > **Security & access** > **Personal API keys** ([Security & access](https://linear.app/docs/security-and-access)). Adjust a key's scope by revoking it and creating a new one with different permissions — existing keys can't be re-scoped after creation. +- **An individual user can revoke their own OAuth authorization at any time.** In Linear, go to **Settings** > **Security & access**, find the C1 entry under **Authorized applications**, hover over it, and select **Revoke access** ([Security & access](https://linear.app/docs/security-and-access)). + + + + + The Linear MCP server lets you govern access to Linear — issues, projects, cycles, teams, users, and comments — as tools your AI clients can call through C1. Linear supports two ways to authenticate, and you choose one when you register the server: @@ -34,7 +153,7 @@ The credentials you set up below are what C1 uses to call Linear on your users' - For a personal API key, you need the Linear account whose access the key should carry. -If you don't see **Linear** in your MCP server catalog, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. +If you don't see **Linear API** in your MCP server catalog, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. ## Option 1: Set up per-user OAuth @@ -70,7 +189,7 @@ With your OAuth application ready, register the server and provide its credentia -Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Linear** from the catalog. +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Linear API** from the catalog. When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose per-user OAuth and enter your application's **client ID** and **client secret**. @@ -111,7 +230,7 @@ With your key ready, register the server and provide it as the credential. -Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Linear** from the catalog. +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Linear API** from the catalog. When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **Bearer token** and paste your personal API key. @@ -121,7 +240,7 @@ Save your changes. C1 starts a sync that discovers the tools the Linear server e -## How Linear credentials are shared +## How Linear API credentials are shared How Linear sees your users' activity depends on the method you chose: @@ -142,8 +261,12 @@ Before anyone can call a Linear tool, it must be approved, added to a toolset, a Tool discovery runs even if your credentials are incorrect, so seeing discovered tools doesn't confirm that authentication is working. You confirm your Linear credentials when an approved user successfully calls a Linear tool from their AI client. -## Manage your Linear credentials +## Manage your Linear API credentials - **Rotate the OAuth client secret** in your Linear OAuth application under **Settings** > **API** > **OAuth applications**, then update the secret on the server's authentication settings in C1. - **Rotate a personal API key** in **Settings** > **Security & access** by deleting the existing key, creating a new one, and updating it in C1. Linear personal API keys don't expire on their own, so rotate them on a schedule. - **Adjust access** by editing the OAuth application's scopes, or by changing the workspace memberships of the account that owns the personal API key. + + + + diff --git a/product/admin/mcp-server/lucid.mdx b/product/admin/mcp-server/lucid.mdx index af92bb1f..8c15674f 100644 --- a/product/admin/mcp-server/lucid.mdx +++ b/product/admin/mcp-server/lucid.mdx @@ -1,17 +1,98 @@ --- title: Set up the Lucid MCP server -description: Connect Lucid to C1 with per-user OAuth or an API token, then register the Lucid MCP server and govern its tools. +description: Connect Lucid to C1 through the Lucid API or Lucid's own hosted MCP server, then register the server and govern its tools. og:title: Set up the Lucid MCP server -og:description: Connect Lucid to C1 with per-user OAuth or an API token, then register the Lucid MCP server and govern its tools. +og:description: Connect Lucid to C1 through the Lucid API or Lucid's own hosted MCP server, then register the server and govern its tools. sidebarTitle: Lucid --- -{/* Editor Refresh: 2026-06-11 */} +{/* Editor Refresh: 2026-07-24 */} **Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough. +C1 can govern Lucid access two ways. Both let your AI clients read from and act on Lucid through governed MCP tools, but they come from different places and appear as two separate entries in your MCP server catalog: + +- **Lucid MCP** — listed as plain **Lucid** in your catalog. C1 registers Lucid's own hosted MCP server (`mcp.lucid.app`) as a downstream server C1 governs. Authentication is always per-user OAuth using dynamic client registration (DCR) — Lucid's hosted MCP server doesn't support a bearer token or API key, so there's no application to create in Lucid first. Before anyone can connect, a Lucid account admin must enable MCP access for the account from the Lucid Admin Panel. Tool calls run with the connected user's full Lucid permissions. +- **Lucid API** — C1 hosts its own MCP server that translates Lucid's REST API into tools. You choose between per-user OAuth or a shared API token, and you scope access with the **scopes** you grant the Lucid OAuth application (or token). + +| | Lucid MCP | Lucid API | +| :--- | :--- | :--- | +| **Who hosts the MCP server** | Lucid | C1 | +| **Authentication** | Per-user OAuth with dynamic client registration (DCR) only — no bearer token or API key option | Per-user OAuth, or a shared API token | +| **Access scoping** | The connected user's full Lucid permissions — not independently scoped | The OAuth **scopes** you configure on the application, or the token | +| **Tool surface** | Lucid's own tool set: document search, content retrieval, diagram creation (including org charts, mind maps, and UML sequence diagrams), image export, and sharing | Documents, folders, teams, and users, mapped to Lucid API endpoints | +| **Setup effort** | An account admin enables MCP access in Lucid, then register and authorize in C1 — nothing else to create in Lucid first | Create a Lucid OAuth application or API token first, then register it in C1 | + +Use the native **Lucid MCP** option (listed as plain **Lucid** in your catalog) if you want Lucid's own broader, agentic tool set and per-user OAuth is acceptable for your tenant. Use **Lucid API** if you need a shared service-account credential (API token), or you want to scope access with OAuth scopes. + + + + + +C1 registers as a client of Lucid's own hosted MCP server ([Integrate Lucid with AI tools using the Lucid MCP server](https://help.lucid.co/hc/en-us/articles/42578801807508-Integrate-Lucid-with-AI-tools-using-the-Lucid-MCP-server)) rather than translating Lucid's REST API itself. Your users' AI clients still only ever see C1-governed MCP tools, but C1 proxies each tool call straight through to `mcp.lucid.app` under the connected user's authorized session, then returns the result. The tools available are exactly the ones Lucid's own MCP server exposes — C1 doesn't reshape or add to them. + +## Before you begin + +- AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). +- A Lucid account admin must enable MCP access for the account from the Lucid Admin Panel before anyone can connect ([Integrate Lucid with AI tools using the Lucid MCP server](https://help.lucid.co/hc/en-us/articles/42578801807508-Integrate-Lucid-with-AI-tools-using-the-Lucid-MCP-server#for-admins-enable-or-disable-use-of-the-mcp-server-for-your-account)). Skipping this step means users won't be able to connect. If MCP access is enabled after a user has already signed in from a connected AI tool, that user may need to re-authenticate for the change to take effect ([Introducing the Lucid Model Context Protocol (MCP) server](https://community.lucid.co/community-news-and-announcements-9/introducing-the-lucid-model-context-protocol-mcp-server-12230)). +- Nothing else to create in Lucid ahead of time. This option only supports per-user OAuth with dynamic client registration — Lucid's hosted MCP server doesn't offer a bearer token or API key mode, so there's no client ID, secret, or application to register. Each user just needs a Lucid account with access to the workspace. + + +In your MCP server catalog, this option is listed as **Lucid** — distinct from the **Lucid API** entry, which connects through C1's own MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. + + +## Set up per-user OAuth + +Per-user OAuth with dynamic client registration (DCR) is the only authentication method this option supports — there's no bearer token or API key fallback. Each user authorizes individually, and C1 registers itself with Lucid's authorization server automatically, so there's no application to create in Lucid first (see Lucid's [Integrate Lucid with AI tools using the Lucid MCP server](https://help.lucid.co/hc/en-us/articles/42578801807508-Integrate-Lucid-with-AI-tools-using-the-Lucid-MCP-server#faq) documentation). + + + +In Lucid, have an account admin go to the Lucid Admin Panel and enable MCP access for the account. This is a prerequisite — until it's enabled, users can't connect regardless of how the server is configured in C1. + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Lucid** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — per-user passthrough** and enable **Use dynamic client registration**. There's no client ID or secret to enter. + + +Save your changes. The first time a user calls a Lucid tool from their AI client, they're redirected to Lucid to sign in (if they aren't already) and approve the connection, then returned to C1. + + + +## What access is granted + +Unlike the Lucid API option, there are no separate scope toggles to configure in C1. Once a user authorizes, tool calls run with that user's full Lucid permissions — they can access everything the user can already access in Lucid, including documents and folders across Lucidchart, Lucidspark, and Lucidscale. This integration's tools can search for and open documents, read their contents and metadata, create and edit diagrams (including org charts, mind maps, and UML sequence diagrams), export documents as images, and manage sharing — creating share links and granting collaborators view, comment, edit, or edit-and-share access ([Integrate Lucid with AI tools using the Lucid MCP server](https://help.lucid.co/hc/en-us/articles/42578801807508-Integrate-Lucid-with-AI-tools-using-the-Lucid-MCP-server#available-actions); [Lucid MCP Server — Supported Operations](https://learn.microsoft.com/en-us/connectors/lucidmcpserver/)). Access follows your normal Lucid permissions — the integration can only reach documents and folders you can already see. + +## How Lucid MCP credentials are shared + +This option only supports per-user OAuth — there's no shared, service-account, or bearer-token mode. Every tool call runs under the calling user's own Lucid identity, and Lucid attributes each action to that individual. C1 still attributes each call to the individual user in the [AI tool usage audit log](/product/admin/audit-ai-tool-usage). + +## Discover and govern tools + +After you register the server, C1 runs tool discovery against Lucid's MCP server. Discovered tools appear on the server's **Tools** tab and include Lucid's own document search and fetch tools, diagram creation (including org charts, mind maps, and UML sequence diagrams), image export, and sharing. + +Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification). + +Before anyone can call a Lucid tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up. + + +Tool discovery runs even if authentication isn't complete yet, so seeing discovered tools doesn't confirm a user has authorized. You confirm access when an approved user successfully calls a Lucid tool from their AI client. + + +## Manage access to Lucid MCP + +Because this option uses per-user OAuth, there's no shared secret in C1 to rotate. Users and admins manage access from Lucid itself: + +- **An individual user can disconnect at any time.** In Lucid, open account settings and go to the **Authorized Websites and Applications** list, then select the app and choose the remove option to revoke it ([Access and update account settings](https://help.lucid.co/hc/en-us/articles/360049864551-Access-and-update-account-settings#apps-and-integrations-settings)). +- **An account admin can turn off MCP access for everyone.** In the Lucid Admin Panel, disable MCP access for the account. This revokes every AI tool and MCP client connected through Lucid MCP at once; users must re-authenticate if it's re-enabled later. + + + + + The Lucid MCP server lets you govern access to Lucid — documents, folders, teams, users, and account data — as tools your AI clients can call through C1. Lucid supports two ways to authenticate, and you choose one when you register the server: @@ -34,7 +115,7 @@ The credentials you set up below are what C1 uses to call Lucid on your users' b - For an API token, the Lucid account whose access the token should carry. -If you don't see **Lucid** in your MCP server catalog, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. +In your MCP server catalog, this option is listed as **Lucid API** — distinct from the **Lucid** entry, which connects to Lucid's own hosted MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. ## Option 1: Set up per-user OAuth @@ -66,7 +147,7 @@ With your OAuth application ready, register the server and provide its credentia -Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Lucid** from the catalog. +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Lucid API** from the catalog. When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose per-user OAuth and enter your OAuth application's **client ID**, **client secret**, and **scopes**. @@ -104,7 +185,7 @@ With your API token ready, register the server and provide it to C1. -Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Lucid** from the catalog. +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Lucid API** from the catalog. When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **Bearer token** and paste your API token. @@ -140,3 +221,7 @@ Tool discovery runs even if your credentials are incorrect, so seeing discovered - **Rotate the OAuth client secret** in your Lucid OAuth application under **Account settings** > **Developer**, then update the secret on the server's authentication settings in C1. - **Rotate an API token** by generating a new one in Lucid and updating it in C1, then revoking the old token. - **Adjust access** by editing the application's scopes in Lucid. + + + + diff --git a/product/admin/mcp-server/monday.mdx b/product/admin/mcp-server/monday.mdx new file mode 100644 index 00000000..5a774f04 --- /dev/null +++ b/product/admin/mcp-server/monday.mdx @@ -0,0 +1,164 @@ +--- +title: Set up the monday.com MCP server +description: Connect monday.com to C1 through monday.com's own hosted MCP server or the monday.com API, then register the server and govern its tools. +og:title: Set up the monday.com MCP server +og:description: Connect monday.com to C1 through monday.com's own hosted MCP server or the monday.com API, then register the server and govern its tools. +sidebarTitle: monday.com +--- + +{/* Editor Refresh: 2026-07-24 */} + + +**Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough. + + +C1 can govern monday.com access two ways. Both let your AI clients read from and act on monday.com through governed MCP tools, but they come from different places and appear as two separate entries in your MCP server catalog — and the two catalog names are easy to mix up: + +- **Monday** — the native MCP option. C1 registers monday.com's own hosted MCP server (`mcp.monday.com`) as a downstream server C1 governs. Authentication is always per-user OAuth using dynamic client registration (DCR) — monday.com's hosted MCP server doesn't support a bearer token or API key, so there's no integration to create in monday.com first. Tool calls run with the connected user's full monday.com permissions. +- **monday.com** — the API option. C1 hosts its own MCP server that translates monday.com's REST/GraphQL API into tools. Authentication is a single personal API token sent as a bearer token, so all tool calls reach monday.com as one shared identity. + +In your catalog, the bare name **Monday** always means the native hosted-MCP option, and **monday.com** always means the API option below — the two entries are distinct servers with different authentication models, not two names for the same thing. + +| | Monday | monday.com | +| :--- | :--- | :--- | +| **Who hosts the MCP server** | monday.com | C1 | +| **Authentication** | Per-user OAuth with dynamic client registration (DCR) only — no bearer token or API key option | A single personal API token, sent as a bearer token | +| **Access scoping** | The connected user's full monday.com permissions — not independently scoped, though an account admin can still limit hosted MCP to specific workspaces | Whatever workspace, board, column, and item access the token's creator has — not independently scoped | +| **Tool surface** | monday.com's own tool set: search, boards, items and subitems, updates, docs, dashboards, workflows, and automations | Boards, items, columns, groups, workspaces, and users, mapped to monday.com API endpoints | +| **Setup effort** | An account admin must first turn on hosted MCP access in monday.com, then register in C1 and authorize | Create a personal API token in monday.com, then register it in C1 | + +Use the native **Monday** option if you want monday.com's own broader, agentic tool set and per-user OAuth is acceptable for your tenant. Use **monday.com** if you need a shared service-account credential instead of per-user login. + + + + + +C1 registers as a client of monday.com's own hosted MCP server ([monday MCP: Connect AI assistants to your account](https://monday.com/w/mcp)) rather than translating monday.com's REST API itself. Your users' AI clients still only ever see C1-governed MCP tools, but C1 proxies each tool call straight through to `mcp.monday.com` under the connected user's authorized session, then returns the result. + +## Before you begin + +- AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). +- An account admin must turn on hosted MCP access for your monday.com account before anyone can connect. Under **Admin** > **Permissions** > **AI Connectors**, the **"Allow external AI agents to access your monday.com account data"** toggle and the **"Public Hosted MCP"** sub-permission must both be on. If access is scoped to specific workspaces instead of the whole account, the workspaces this integration needs must be included. See monday.com's [Managing AI Connectors and MCP Access](https://support.monday.com/hc/en-us/articles/35696101067154-Managing-AI-Connectors-and-MCP-Access) documentation. +- Nothing to create in monday.com ahead of time. This option only supports per-user OAuth with dynamic client registration — there's no client ID, secret, bearer token, or API key mode, so there's no integration to register in monday.com first. Each user just needs a monday.com account with access to the workspace you want to govern. + + +In your MCP server catalog, this option is listed as **Monday** — distinct from the **monday.com** entry, which connects through C1's own MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. + + +## Set up per-user OAuth with dynamic client registration + +Per-user OAuth with dynamic client registration (DCR) is the only authentication method this option supports — there's no bearer token or API key fallback. Each user authorizes individually, and C1 registers itself with monday.com's authorization server automatically, so there's no app to create in monday.com first ([Platform MCP security](https://developer.monday.com/api-reference/docs/monday-mcp-security-overview)). + + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Monday** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — per-user passthrough** and enable **Use dynamic client registration**. There's no client ID or secret to enter. + + +Save your changes. The first time a user calls a Monday tool from their AI client, they're redirected to monday.com to sign in (if they aren't already) and approve the connection, then returned to C1. + + + +## What access is granted + +Unlike the monday.com API option, there are no separate capability toggles to configure. Every MCP tool call runs as the authorizing user and is bound to that user's own monday.com permissions — board and item visibility, private boards, and workspace access all apply exactly as they would if that person were using monday.com directly. There is no elevated or shared service account that bypasses these controls ([Platform MCP security](https://developer.monday.com/api-reference/docs/monday-mcp-security-overview#multi-tenant-design-with-per-user-isolation)). Within those limits, this option's tools can search, read, and manage boards, items, and subitems (including column values, groups, and descriptions), post and reply to updates, and work with docs, dashboards, workflows, and automations across a user's monday.com workspace ([monday MCP available tools](https://support.monday.com/hc/en-us/articles/32364501317906-monday-MCP-available-tools)). + +## How Monday credentials are shared + +This option only supports per-user OAuth — there's no shared, service-account, or bearer-token mode. Every tool call runs under the calling user's own monday.com identity. C1 still attributes each call to the individual user in the [AI tool usage audit log](/product/admin/audit-ai-tool-usage). + +## Discover and govern tools + +After you register the server, C1 runs tool discovery against monday.com's MCP server. Discovered tools appear on the server's **Tools** tab. + +Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification). + +Before anyone can call a Monday tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up. + + +Tool discovery runs even if authentication isn't complete yet, so seeing discovered tools doesn't confirm a user has authorized. You confirm access when an approved user successfully calls a Monday tool from their AI client. + + +## Manage access to Monday + +Because this option uses per-user OAuth, there's no shared secret in C1 to rotate. An account admin manages access from monday.com itself: under **Admin** > **Permissions** > **AI Connectors**, uncheck **Public Hosted MCP** to cut off this integration along with every other AI tool using monday.com's hosted MCP server, or turn off the whole **"Allow external AI agents to access your monday.com account data"** toggle to block all external AI access outright. Admins can also narrow access to specific workspaces from the same panel instead of revoking entirely ([Managing AI Connectors and MCP Access](https://support.monday.com/hc/en-us/articles/35696101067154-Managing-AI-Connectors-and-MCP-Access)). + + + + + +C1 hosts the monday.com MCP server, so your users' AI clients only ever see MCP tools — they never call monday.com directly. When an AI client calls one of these tools, C1 makes the matching request to monday.com's API using the credentials you configure here, then returns the result to the AI client. + +monday.com authenticates with a personal API token that C1 sends as a bearer token. A single token authenticates everyone, so all tool calls reach monday.com as one shared identity. + +## Before you begin + +- AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). +- A monday.com account that can generate a personal API token, with access to the boards and workspaces you want this integration to have. + + +In your MCP server catalog, this option is listed as **monday.com** — distinct from the **Monday** entry, which connects to monday.com's own hosted MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. + + +## Create a monday.com personal API token + +Create a personal API token in monday.com for C1 to authenticate with. See monday.com's [Authentication](https://developer.monday.com/api-reference/docs/authentication) documentation. + + + +Sign in to monday.com and select your avatar in the bottom-left corner. + + +Select **Developers** to open the Developer Center, then select **My access tokens** in the left menu. Account admins can instead go to their avatar, then **Administration** > **Connections** > **Personal API token**. + + +Select **Show** and copy the token. + + + +A personal token inherits whatever workspace, board, column, and item permissions the creating user already has in monday.com — there's no separate scope to configure. For a shared production setup, create the token under a dedicated service-account user so activity is attributable to C1 rather than a person. + +## How monday.com credentials are shared + +Every user's tool calls use the one API token you provided, so monday.com sees a single shared identity. C1 still attributes each call to the individual user in the [AI tool usage audit log](/product/admin/audit-ai-tool-usage). + +For how shared and per-user credentials work across MCP servers, see [Configure authentication](/product/admin/mcp-servers#configure-authentication). + +## Register the monday.com MCP server in C1 + +With your API token ready, register the server and provide it to C1. + + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **monday.com** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **Bearer token** and paste your personal API token. + + +Save your changes. C1 starts a sync that discovers the tools the monday.com server exposes. + + + +## Discover and govern tools + +After you register the server, C1 runs tool discovery against monday.com. Discovered tools appear on the server's **Tools** tab. + +Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification). + +Before anyone can call a monday.com tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up. + + +Tool discovery runs even if your credentials are incorrect, so seeing discovered tools doesn't confirm that authentication is working. You confirm your monday.com credentials when an approved user successfully calls a monday.com tool from their AI client. + + +## Manage your monday.com credentials + +- **Rotate the personal API token** by regenerating it from the same **My access tokens** (or **Administration** > **Connections**) page in monday.com, then updating it in C1. Regenerating immediately invalidates the previous token, so confirm the new one works in C1 before considering the old one retired. +- **Adjust access** by changing the permissions of the user the token belongs to in monday.com, since the token mirrors whatever access that user already has. + + + + diff --git a/product/admin/mcp-server/n8n.mdx b/product/admin/mcp-server/n8n.mdx index a330e11e..57027d3f 100644 --- a/product/admin/mcp-server/n8n.mdx +++ b/product/admin/mcp-server/n8n.mdx @@ -1,18 +1,139 @@ --- title: Set up the n8n MCP server -description: Create an n8n API key on your instance, then register the n8n MCP server in C1 and govern the tools it exposes. +description: Connect n8n to C1 through n8n's own hosted MCP server (n8n Cloud only) or the n8n API, then register the server and govern its tools. og:title: Set up the n8n MCP server -og:description: Create an n8n API key on your instance, then register the n8n MCP server in C1 and govern the tools it exposes. +og:description: Connect n8n to C1 through n8n's own hosted MCP server (n8n Cloud only) or the n8n API, then register the server and govern its tools. sidebarTitle: n8n --- -{/* Editor Refresh: 2026-06-11 */} +{/* Editor Refresh: 2026-07-24 */} **Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough. -The n8n MCP server lets you govern access to n8n — workflows, executions, credentials, tags, and users — as tools your AI clients can call through C1. n8n is self-hosted, so the server connects to your own n8n instance. +C1 can govern n8n access two ways. Both let your AI clients read from and act on n8n through governed MCP tools, but they support different n8n deployments and appear as two separate entries in your MCP server catalog: + +- **n8n MCP** — listed as plain **n8n** in your catalog. C1 registers n8n's own hosted MCP server as a downstream server C1 governs. **This option works with n8n Cloud only.** Authentication is per-user OAuth 2.1 (dynamic client registration recommended), or a personal access token as a bearer credential fallback. +- **n8n API** — C1 hosts its own MCP server that translates n8n's REST API into tools. A single API key authenticates every user as one shared identity. This works with **either n8n Cloud or a self-hosted n8n instance**. + +**Use n8n MCP only if you're on n8n Cloud.** Self-hosted n8n instances can't use this option — use **n8n API** instead, or, if your self-hosted instance exposes its own MCP server, connect it to C1 as an external MCP server. + +| | n8n MCP | n8n API | +| :--- | :--- | :--- | +| **n8n deployment supported** | n8n Cloud only | n8n Cloud or self-hosted | +| **Who hosts the MCP server** | n8n | C1 | +| **Authentication** | Per-user OAuth 2.1 with dynamic client registration (recommended), or a personal access token (bearer) | A single shared API key (custom header) | +| **Access scoping** | The connected user's own n8n permissions in that workspace, or the token owner's permissions if using a personal access token | Whatever the API key's owning n8n user account can access | +| **Tool surface** | n8n's own instance-level MCP tools: workflow search, execution, testing, and publishing; execution history; credential listing; workflow building and validation; data tables | Workflows, executions, credentials, tags, and users, mapped to n8n API endpoints | +| **Setup effort** | Register in C1 and authorize — nothing to create in n8n first (unless you choose a personal access token) | Create an n8n API key first, then register it in C1 | + +Use the native **n8n MCP** option (listed as plain **n8n** in your catalog) if you're on n8n Cloud and want n8n's own broader tool set with per-user OAuth. Use **n8n API** if you're on a self-hosted instance, or you need a shared service-account credential. + + + + + +C1 registers as a client of n8n's own hosted MCP server rather than translating n8n's REST API itself. Your users' AI clients still only ever see C1-governed MCP tools, but C1 proxies each tool call straight through to your n8n Cloud workspace under the connected user's (or token's) authorized session, then returns the result. The tools available are exactly the ones n8n's own MCP server exposes — C1 doesn't reshape or add to them. See n8n's [MCP server tools reference](https://docs.n8n.io/connect/connect-to-n8n-mcp-server/mcp-server-tools-reference) for the full list. + +## Before you begin + +- AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). +- **This option is n8n Cloud only.** If you run a self-hosted n8n instance, use the **n8n API** option instead, or, if your instance has its own MCP server enabled, register it in C1 as an external MCP server. +- Your n8n Cloud workspace name — the subdomain in `.app.n8n.cloud` (for example, enter `c1-mcp` for a workspace at `https://c1-mcp.app.n8n.cloud`). You'll enter this when you register the server. +- A user account on the n8n Cloud workspace (for per-user OAuth), or a personal access token (for the bearer fallback). + + +In your MCP server catalog, this option is listed as **n8n** — distinct from the **n8n API** entry, which connects through C1's own MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. + + +## Set up per-user OAuth (recommended) + +Per-user OAuth 2.1 with dynamic client registration (DCR) is the recommended way to connect n8n MCP. Each user authorizes individually, and C1 registers itself with your workspace's authorization server automatically, so there's nothing to create in n8n first. See n8n's [Connect to n8n MCP server](https://docs.n8n.io/connect/connect-to-n8n-mcp-server#setting-up-mcp-authentication) documentation for background on n8n's MCP authentication options. + + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **n8n** from the catalog. + + +Enter your n8n Cloud workspace name when prompted. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — per-user passthrough** and enable **Use dynamic client registration**. Leave the authorize and token URL fields blank — C1 auto-discovers them from your workspace. + + +Save your changes. The first time a user calls an n8n tool from their AI client, they're redirected to n8n to sign in (if they aren't already) and approve the connection, then returned to C1. + + + +## Use a personal access token instead + +If per-user OAuth isn't an option for your tenant, n8n MCP also accepts a personal MCP access token as a bearer credential. Every user's tool calls then run under the token owner's n8n identity rather than each person's own. + +First, get a personal access token from n8n: + + + +Sign in to your n8n Cloud workspace and go to **Settings** > **Instance-level MCP**. See n8n's [Connect to n8n MCP server](https://docs.n8n.io/connect/connect-to-n8n-mcp-server#using-access-token) documentation. + + +Open **Connection details**, then switch to the **Access Token** tab. n8n generates a personal MCP access token the first time you view this tab — copy it now, since later visits only show a redacted value. + + + +For a shared production setup, generate the token from a dedicated service-account user so activity is attributable to C1 rather than a person. + +Then register the server with that token: + + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **n8n** from the catalog. + + +Enter your n8n Cloud workspace name. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **Bearer token** and paste your personal access token. + + +Save your changes. + + + +## What access is granted + +Access depends on the authentication method you chose: + +- **Per-user OAuth.** Tool calls run with the connected user's own n8n permissions in that workspace — they can access what that user can already access in n8n. +- **Personal access token.** Every tool call runs with the token owner's n8n permissions, regardless of which C1 user made the request. + +## How n8n MCP credentials are shared + +- **Per-user OAuth.** Every tool call runs under the calling user's own n8n identity, and n8n attributes each action to that individual. +- **Personal access token.** Every user's tool calls use the one token you provided, so n8n sees a single shared identity. C1 still attributes each call to the individual user in the [AI tool usage audit log](/product/admin/audit-ai-tool-usage). + +## Discover and govern tools + +After you register the server, C1 runs tool discovery against n8n's MCP server. Discovered tools appear on the server's **Tools** tab and include n8n's own workflow search, execution, testing, and publishing tools; execution history lookups; credential listing; workflow building and validation; and data table management. + +Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification). + +Before anyone can call an n8n tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up. + + +Tool discovery runs even if authentication isn't complete yet, so seeing discovered tools doesn't confirm a user has authorized or that a token is valid. You confirm access when an approved user successfully calls an n8n tool from their AI client. + + +## Manage access to n8n MCP + +- **Rotate or revoke a personal access token.** Go to **Settings** > **Instance-level MCP** in n8n, open **Connection details**, switch to the **Access Token** tab, and generate a new token. n8n automatically revokes the previous one. Update the new token in C1's authentication settings. +- **Revoke an individual user's OAuth authorization.** In n8n, go to **Settings** > **Instance-level MCP**, open the **Connected clients** tab, and use the action menu next to the client to revoke its access. See n8n's [Connect to n8n MCP server](https://docs.n8n.io/connect/connect-to-n8n-mcp-server#revoking-client-access) documentation for current steps, since exact menu locations can change. + + + + + +The n8n MCP server lets you govern access to n8n — workflows, executions, credentials, tags, and users — as tools your AI clients can call through C1. This option connects to a self-hosted n8n instance, or to an n8n Cloud workspace, through n8n's REST API. n8n authenticates with an API key that C1 sends in a request header. A single key authenticates everyone, so all tool calls reach n8n as one shared identity. @@ -29,7 +150,7 @@ The credentials you set up below are what C1 uses to call n8n on your users' beh - The base URL of your n8n instance, reachable from C1. -If you don't see **n8n** in your MCP server catalog, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. +If you don't see **n8n API** in your MCP server catalog, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. ## Create an n8n API key @@ -62,7 +183,7 @@ With your API key ready, register the server and provide it to C1. -Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **n8n** from the catalog. +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **n8n API** from the catalog. Enter the base URL of your n8n instance when prompted. @@ -91,3 +212,7 @@ Tool discovery runs even if your credentials are incorrect, so seeing discovered - **Rotate the API key** by creating a new key under **Settings** > **n8n API**, updating it in C1, then deleting the old key. - **Adjust access** by changing the permissions of the user the key belongs to on your n8n instance. + + + + diff --git a/product/admin/mcp-server/pagerduty.mdx b/product/admin/mcp-server/pagerduty.mdx index 53080c47..5d8311b2 100644 --- a/product/admin/mcp-server/pagerduty.mdx +++ b/product/admin/mcp-server/pagerduty.mdx @@ -1,17 +1,170 @@ --- title: Set up the PagerDuty MCP server -description: Connect PagerDuty to C1 with per-user OAuth or a REST API key, then register the PagerDuty MCP server and govern its tools. +description: Connect PagerDuty to C1 through the PagerDuty REST API or PagerDuty's own hosted MCP server, then register the server and govern its tools. og:title: Set up the PagerDuty MCP server -og:description: Connect PagerDuty to C1 with per-user OAuth or a REST API key, then register the PagerDuty MCP server and govern its tools. +og:description: Connect PagerDuty to C1 through the PagerDuty REST API or PagerDuty's own hosted MCP server, then register the server and govern its tools. sidebarTitle: PagerDuty --- -{/* Editor Refresh: 2026-06-11 */} +{/* Editor Refresh: 2026-07-24 */} **Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough. +C1 can govern PagerDuty access two ways. Both let your AI clients read from and act on PagerDuty through governed MCP tools, but they come from different places and appear as two separate entries in your MCP server catalog: + +- **PagerDuty MCP** — listed as plain **PagerDuty** in your catalog. C1 registers PagerDuty's own hosted MCP server (`mcp.pagerduty.com`) as a downstream server C1 governs. Authenticate with per-user OAuth — using a Scoped OAuth application you register manually in PagerDuty, since PagerDuty's hosted MCP server doesn't support dynamic client registration (DCR) — or with a shared API key or user token. Tool calls run with whichever identity you authenticated. +- **PagerDuty API** — C1 hosts its own MCP server that translates PagerDuty's REST API into tools. You choose between per-user OAuth or a shared REST API key, and access is scoped to the OAuth app's granted scopes or the REST API key's permissions. + +| | PagerDuty MCP | PagerDuty API | +| :--- | :--- | :--- | +| **Who hosts the MCP server** | PagerDuty | C1 | +| **Authentication** | Per-user OAuth with a manually registered Scoped OAuth application (no DCR), or a shared API key / user token (bearer) | Per-user OAuth, or a shared REST API key (bearer token) | +| **Access scoping** | The connected identity's own PagerDuty permissions, within whatever scopes the OAuth app was granted — not independently scoped by C1 | The scopes you grant the OAuth app, or the permissions of the REST API key you provide | +| **Tool surface** | PagerDuty's own tool set: incidents, services, on-call schedules, escalation policies, teams, event orchestrations, status pages, and more | Incidents, services, schedules, escalation policies, and users, mapped to PagerDuty REST API endpoints | +| **Setup effort** | Register a Scoped OAuth application in PagerDuty (or create an API key), then register it in C1 — no automatic registration | Register an OAuth app or create a REST API key in PagerDuty, then register it in C1 | + +Use the native **PagerDuty MCP** option (listed as plain **PagerDuty** in your catalog) if you want PagerDuty's own broader, agentic tool set and you're prepared to manually register a Scoped OAuth application (or use an API key). Use **PagerDuty API** if you'd rather scope access purely through PagerDuty's REST API scopes with either credential type. + + + + + +C1 registers as a client of PagerDuty's own hosted MCP server ([PagerDuty MCP Server](https://support.pagerduty.com/main/docs/pagerduty-mcp-server)) rather than translating PagerDuty's REST API itself. Your users' AI clients still only ever see C1-governed MCP tools, but C1 proxies each tool call straight through to `mcp.pagerduty.com/mcp` under the connected identity, then returns the result. The tools available are exactly the ones PagerDuty's own MCP server exposes — C1 doesn't reshape or add to them. + +## Before you begin + +- AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). +- For per-user OAuth, you need permission to register a Scoped OAuth application in PagerDuty — this requires an account admin or owner role. Regular users are limited to **Classic User OAuth**, which C1 doesn't use here, since it only supports coarse and unreliable access. +- For an API key or user token, you need a PagerDuty account that can create a REST API key, or your own user account to create a personal token. +- PagerDuty's hosted MCP server doesn't support OAuth dynamic client registration (DCR). Unlike some other native MCP integrations, per-user OAuth here always starts with an application you register yourself — there's no automatic client registration to skip. + + +In your MCP server catalog, this option is listed as **PagerDuty** — distinct from the **PagerDuty API** entry, which connects through C1's own MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. + + +## Option 1: Set up per-user OAuth + +With per-user OAuth, you register one Scoped OAuth application in PagerDuty and each user authorizes individually. This keeps every action attributable to the user who took it, within the scopes you granted. + +### Register a Scoped OAuth application + + + +In PagerDuty, go to **Integrations** > **App Registration** and select **New App**. Give it a name that identifies C1 for your team, such as `C1`. See PagerDuty's [Register an App](https://developer.pagerduty.com/docs/register-an-app) documentation. + + +Select **OAuth 2.0** as the app's functionality, then leave **Scoped OAuth** selected on the next screen — it's the default and the only mode with the granular, per-object scopes below. The other option, **Classic User OAuth**, only supports coarse read (and unreliable write) access, so C1 doesn't use it. + + +Set the **Redirect URL** exactly to: + +``` +https://accounts.conductor.one/auth/callback +``` + + +Select the scopes C1 needs. For full functionality, grant: + +- `incidents.read`, `incidents.write` — view, create, acknowledge, resolve, and update incidents +- `services.read`, `services.write` — view, create, and update services +- `teams.read`, `teams.write` — view, create, and update teams and their memberships +- `users.read`, `users.write` — view, create, and update users +- `schedules.read`, `schedules.write` — view, create, and update on-call schedules +- `oncalls.read` — view who is currently on call +- `escalation_policies.read` — view escalation policies +- `event_orchestrations.read`, `event_orchestrations.write` — view, create, and update event orchestrations (the rules that route events to services) +- `status_pages.read`, `status_pages.write` — view, create, and update status pages +- `webhook_subscriptions.read`, `webhook_subscriptions.write` — view, create, and update webhook subscriptions +- `change_events.read` — view change events (deployments and other changes correlated with incidents) +- `incident_workflows.read`, `incident_workflows:instances.write` — view incident workflow definitions, and run workflow instances +- `extension_schemas.read` — view extension schemas used by service extensions and integrations +- `openid` — sign in with OpenID Connect; identifies the authorizing user + +You can narrow or widen this list later from the same screen. + + +Select **Register App**, then copy the **Client ID** and **Client Secret** from the confirmation dialog. PagerDuty shows the secret only once. + + + +### Register the server with OAuth + +With your Scoped OAuth application ready, register the server and provide your credentials: + + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **PagerDuty** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — per-user passthrough** and enter your application's **client ID** and **client secret**. + + +Save your changes. The first time a user calls a PagerDuty tool from their AI client, they're redirected to PagerDuty to sign in (if they aren't already) and approve the connection, then returned to C1. + + + +## Option 2: Use an API key or user token + +An API key or user token authenticates every user as one shared PagerDuty identity. Use this when per-user attribution in PagerDuty isn't required, or when you'd rather skip registering an OAuth application. + + + +In PagerDuty, go to **Integrations** > **API Access Keys** and select **Create New API Key** — or, for a personal token, go to your user icon, then **My Profile** > **User Settings** > **API Access** > **Create API User Token**. See PagerDuty's [API Access Keys](https://support.pagerduty.com/main/docs/api-access-keys) documentation. + + +Give the key a recognizable description such as `C1`, then copy it. PagerDuty shows it only once. + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **PagerDuty** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **Bearer token** and paste your API key or user token. + + +Save your changes. C1 starts a sync that discovers the tools the PagerDuty MCP server exposes. + + + + +PagerDuty doesn't use the standard `Bearer` prefix for this credential — it expects the `Authorization` header formatted as `Token token=` ([source](https://community.pagerduty.com/ask-a-product-question-2/can-t-use-api-user-tokens-702)). C1 sends it in this format automatically; you don't need to enter the prefix yourself. + + +## What access is granted + +Tool calls run with whichever identity you authenticated: for per-user OAuth, the connected user's own PagerDuty permissions within the scopes you granted; for an API key or user token, the permissions attached to that credential. Either way, access spans PagerDuty's own tool set — incidents, services, on-call schedules, escalation policies, teams, event orchestrations, status pages, and more. + +## How PagerDuty MCP credentials are shared + +How PagerDuty sees your users' activity depends on the method you chose: + +- **Per-user OAuth.** Each user authorizes with their own PagerDuty account, so tool calls run under that user's PagerDuty identity and inherit only the scopes you granted. PagerDuty attributes each action to the individual user. +- **API key or user token.** Every user's tool calls use the one credential you provided, so PagerDuty sees a single shared identity. C1 still attributes each call to the individual user in the [AI tool usage audit log](/product/admin/audit-ai-tool-usage). + +## Discover and govern tools + +After you register the server, C1 runs tool discovery against PagerDuty's hosted MCP server. Discovered tools appear on the server's **Tools** tab. + +Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification). + +Before anyone can call a PagerDuty tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up. + + +Tool discovery runs even if authentication isn't complete yet, so seeing discovered tools doesn't confirm a user has authorized or that credentials are valid. You confirm access when an approved user successfully calls a PagerDuty tool from their AI client. + + +## Manage access to PagerDuty MCP + +- **Rotate the OAuth client secret** in your PagerDuty app under **Integrations** > **App Registration**, then update the secret on the server's authentication settings in C1. +- **Rotate an API key or user token** by creating a new one in PagerDuty and updating it in C1, then delete the old one. +- **Revoke access** from the app's page in **App Registration** — revoke its tokens to invalidate every session at once, or delete the app entirely. +- **Adjust scopes** by editing them on the OAuth application in PagerDuty, or by choosing a read-only versus full-access API key. + + + + + The PagerDuty MCP server lets you govern access to PagerDuty — incidents, services, schedules, escalation policies, and users exposed by the PagerDuty REST API — as tools your AI clients can call through C1. PagerDuty supports two ways to authenticate, and you choose one when you register the server: @@ -34,7 +187,7 @@ The credentials you set up below are what C1 uses to call PagerDuty on your user - For a REST API key, you need a PagerDuty account that can create a REST API key, and the email address of a valid PagerDuty user to record as the actor on write operations. -If you don't see **PagerDuty** in your MCP server catalog, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. +In your MCP server catalog, this option is listed as **PagerDuty API** — distinct from the **PagerDuty** entry, which connects to PagerDuty's own hosted MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. ## Option 1: Set up per-user OAuth @@ -67,7 +220,7 @@ With your OAuth app ready, register the server and provide your credentials. -Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **PagerDuty** from the catalog. +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **PagerDuty API** from the catalog. When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose per-user OAuth and enter your OAuth app's **client ID**, **client secret**, and the **scopes** you granted. @@ -87,7 +240,7 @@ Create a REST API key in PagerDuty for C1 to authenticate with as a single share -In PagerDuty, go to **Integrations** > **API Access Keys** and select **Create New API Key**. For details, see PagerDuty's [API Access Keys](https://support.pagerduty.com/main/docs/api-access-keys) documentation. +In PagerDuty, go to **Integrations** > **API Access Keys** and select **Create New API Key**. For details, see PagerDuty's [API Access Keys](https://support.pagerduty.com/main/docs/api-access-keys#generate-a-general-access-rest-api-key) documentation. Give the key a recognizable description such as `C1`. For least privilege, create a **read-only** key unless the tools you plan to approve need write access. @@ -105,7 +258,7 @@ With your REST API key ready, register the server and provide your credentials. -Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **PagerDuty** from the catalog. +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **PagerDuty API** from the catalog. Enter the **actor email** — the email of a valid PagerDuty user to record as the actor on write operations such as acknowledging or resolving incidents. @@ -144,3 +297,7 @@ Tool discovery runs even if your credentials are incorrect, so seeing discovered - **Rotate the OAuth client secret** in your PagerDuty app under **Integrations** > **Developer Tools** > **App Registration**, then update the secret on the server's authentication settings in C1. - **Rotate a REST API key** by creating a new key in PagerDuty and updating it in C1, then delete the old key. - **Adjust access** by editing the OAuth app's scopes or by choosing a read-only versus full-access REST API key in PagerDuty. + + + + diff --git a/product/admin/mcp-server/pylon.mdx b/product/admin/mcp-server/pylon.mdx new file mode 100644 index 00000000..6c67e94f --- /dev/null +++ b/product/admin/mcp-server/pylon.mdx @@ -0,0 +1,157 @@ +--- +title: Set up the Pylon MCP server +description: Connect Pylon to C1 through the Pylon API or Pylon's own hosted MCP server, then register the server and govern its tools. +og:title: Set up the Pylon MCP server +og:description: Connect Pylon to C1 through the Pylon API or Pylon's own hosted MCP server, then register the server and govern its tools. +sidebarTitle: Pylon +--- + + +**Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough. + + +C1 can govern [Pylon](https://www.usepylon.com/) access two ways. Both let your AI clients read from and act on Pylon through governed MCP tools, but they come from different places and appear as two separate entries in your MCP server catalog: + +- **Pylon MCP** — listed as plain **Pylon** in your catalog. C1 registers Pylon's own hosted MCP server (`mcp.usepylon.com`) as a downstream server C1 governs. Authentication is always per-user OAuth using dynamic client registration (DCR) — Pylon's hosted MCP server doesn't support a bearer token or API key, so there's no integration to create in Pylon first. Tool calls run with the connected user's own Pylon seat permissions. +- **Pylon API** — C1 hosts its own MCP server that translates Pylon's REST API into tools. Authentication is a single shared bearer token (an API token generated in Pylon), so every tool call reaches Pylon as one shared identity. + +| | Pylon MCP | Pylon API | +| :--- | :--- | :--- | +| **Who hosts the MCP server** | Pylon | C1 | +| **Authentication** | Per-user OAuth with dynamic client registration (DCR) only — no bearer token or API key option | Bearer token (API token) only — no OAuth option | +| **Access scoping** | The connected user's own Pylon seat and role permissions — not independently scoped | Whatever the API token's seat can reach in Pylon | +| **Tool surface** | Pylon's own tool set: search, read, create, and update issues, accounts, and contacts | Issues, accounts, contacts, teams, users, knowledge bases, and tags, mapped to Pylon API endpoints | +| **Setup effort** | Register in C1 and authorize — nothing to create in Pylon first | Generate an API token in Pylon, then register it in C1 | + +Use the native **Pylon MCP** option (listed as plain **Pylon** in your catalog) if per-user OAuth is acceptable for your tenant and Pylon's own agentic tool set is enough. Use **Pylon API** if you need a shared service-account credential (bearer token) instead. + + + + + +C1 registers as a client of Pylon's own hosted MCP server ([Pylon MCP](https://docs.usepylon.com/pylon-docs/integrations/pylon-mcp)) rather than translating Pylon's REST API itself. Your users' AI clients still only ever see C1-governed MCP tools, but C1 proxies each tool call straight through to `mcp.usepylon.com` under the connected user's authorized session, then returns the result. The tools available are exactly the ones Pylon's own MCP server exposes — C1 doesn't reshape or add to them. + +## Before you begin + +- AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). +- Nothing to create in Pylon ahead of time. This option only supports per-user OAuth with dynamic client registration — Pylon's hosted MCP server doesn't offer a bearer token or API key mode, so there's no client ID, secret, or integration to register. +- A Pylon admin must first turn on the MCP server from **Settings → AI Controls → MCP Server** in the Pylon dashboard ([Pylon MCP](https://docs.usepylon.com/pylon-docs/integrations/pylon-mcp#setup-in-pylon)). Each person who will connect needs a **Member** or **Admin** seat with the **MCP Access** role enabled; **Viewer** and **Integration** seats can't authenticate and see an "Authorization failed" error ([Connecting to the Pylon MCP Server](https://support.usepylon.com/articles/2407390554-connecting-to-the-pylon-mcp-server)). + + +In your MCP server catalog, this option is listed as **Pylon** — distinct from the **Pylon API** entry, which connects through C1's own MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. + + +## Set up per-user OAuth + +Per-user OAuth with dynamic client registration (DCR) is the only authentication method this option supports — there's no bearer token or API key fallback. Each user authorizes individually, and C1 registers itself with Pylon's authorization server automatically, so there's no app to create in Pylon first. + + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Pylon** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — per-user passthrough** and enable **Use dynamic client registration**. There's no client ID or secret to enter. + + +Save your changes. The first time a user calls a Pylon tool from their AI client, they're redirected to Pylon to sign in (if they aren't already) and approve the connection, then returned to C1. + + + +## What access is granted + +Once a user authorizes, tool calls run with that user's own Pylon seat permissions — they can search for and read issues, accounts, and contacts they can already see in Pylon, and create or update them on the same terms as in the Pylon dashboard ([Pylon MCP](https://docs.usepylon.com/pylon-docs/integrations/pylon-mcp#what-you-can-do-with-mcp-today)). The MCP server never returns data the user can't already see, or performs a write the user can't already make, in Pylon. + +## How Pylon MCP credentials are shared + +This option only supports per-user OAuth — there's no shared, service-account, or bearer-token mode. Every tool call runs under the calling user's own Pylon identity, and Pylon attributes each action to that individual. C1 still attributes each call to the individual user in the [AI tool usage audit log](/product/admin/audit-ai-tool-usage). + +## Discover and govern tools + +After you register the server, C1 runs tool discovery against Pylon's MCP server. Discovered tools appear on the server's **Tools** tab and include Pylon's own search, read, create, and update tools for issues, accounts, and contacts. + +Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification). + +Before anyone can call a Pylon tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up. + + +Tool discovery runs even if authentication isn't complete yet, so seeing discovered tools doesn't confirm a user has authorized. You confirm access when an approved user successfully calls a Pylon tool from their AI client. + + +## Manage access to Pylon MCP + +Because this option uses per-user OAuth, there's no shared secret in C1 to rotate. Users and admins manage access from Pylon itself: + +- **An individual user's session expires periodically** — some sessions last a few hours, others several days ([Connecting to the Pylon MCP Server](https://support.usepylon.com/articles/2407390554-connecting-to-the-pylon-mcp-server)). Reconnecting re-runs the same authorization flow. +- **A Pylon admin can turn off the integration workspace-wide** from the same **Settings → AI Controls → MCP Server** panel used to enable it, or remove an individual's **MCP Access** role from the Users page under Settings to cut off just that person's connection ([Roles & User Management](https://docs.usepylon.com/pylon-docs/platform/roles-and-user-management)). + + + + + +C1 hosts the Pylon MCP server, so your users' AI clients only ever see MCP tools — they never call Pylon directly. When an AI client calls one of these tools, C1 makes the matching request to the Pylon API using the bearer token you configure here, then returns the result to the AI client. + +Pylon's REST API supports a single authentication method: a bearer token generated in the Pylon dashboard. Every tool call reaches Pylon as that one shared identity. + +## Before you begin + +- AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). +- You need access to generate an API token in Pylon, at **Settings → API Tokens** in the Pylon dashboard. + + +In your MCP server catalog, this option is listed as **Pylon API** — distinct from the **Pylon** entry, which connects to Pylon's own hosted MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. + + +## Generate a Pylon API token + + + +In Pylon, go to [Settings → API Tokens](https://app.usepylon.com/settings/api-tokens). + + +Create a new token and give it a recognizable name — actions the token takes in Pylon show up under that name, so use something that identifies C1. + + +Copy the token. Treat it as a high-value credential; Pylon only shows it once. + + + +For a shared production setup, generate the token from a dedicated service-account user so activity is attributable to C1 rather than a person. + +## Register the server in C1 + + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Pylon API** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **Bearer token** and paste your Pylon API token. + + +Save your changes. C1 starts a sync that discovers the tools the Pylon server exposes. + + + +## How Pylon API credentials are shared + +Every user's tool calls use the one bearer token you provided, so Pylon sees a single shared identity, attributed to whichever token name you chose. C1 still attributes each call to the individual user in the [AI tool usage audit log](/product/admin/audit-ai-tool-usage). + +## Discover and govern tools + +After you register the server, C1 runs tool discovery against Pylon. Discovered tools appear on the server's **Tools** tab and include issues, accounts, contacts, teams, users, knowledge bases, and tags. + +Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification). + +Before anyone can call a Pylon tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up. + + +Tool discovery runs even if your credentials are incorrect, so seeing discovered tools doesn't confirm that authentication is working. You confirm your Pylon API token when an approved user successfully calls a Pylon tool from their AI client. + + +## Manage your Pylon API credentials + +- **Rotate the token** by generating a new one at **Settings → API Tokens** in Pylon, then updating it on the server's authentication settings in C1. Revoke the old token in Pylon once the new one is in place. +- **Revoke access entirely** by deleting the token in Pylon; C1's calls will start failing until you provide a new one. + + + + diff --git a/product/admin/mcp-server/slack.mdx b/product/admin/mcp-server/slack.mdx index 500c318e..02c9f2f6 100644 --- a/product/admin/mcp-server/slack.mdx +++ b/product/admin/mcp-server/slack.mdx @@ -1,17 +1,171 @@ --- title: Set up the Slack MCP server -description: Connect Slack to C1 with per-user OAuth, then register the Slack MCP server and govern the tools it exposes. +description: Connect Slack to C1 through the Slack API or Slack's own hosted MCP server, then register the server and govern its tools. og:title: Set up the Slack MCP server -og:description: Connect Slack to C1 with per-user OAuth, then register the Slack MCP server and govern the tools it exposes. +og:description: Connect Slack to C1 through the Slack API or Slack's own hosted MCP server, then register the server and govern its tools. sidebarTitle: Slack --- -{/* Editor Refresh: 2026-06-11 */} +{/* Editor Refresh: 2026-07-24 */} **Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough. +C1 can govern Slack access two ways. Both let your AI clients read from and act on Slack through governed MCP tools, but they come from different places and appear as two separate entries in your MCP server catalog: + +- **Slack MCP** — listed as plain **Slack** in your catalog. C1 registers Slack's own hosted MCP server (`mcp.slack.com`) as a downstream server C1 governs. Authentication uses Slack's dedicated user-token OAuth flow: an admin registers a Slack app and provides its client ID and secret to C1 (there's no dynamic client registration), then each user authorizes individually. A static Slack user token is also supported as a bearer fallback. Tool calls run with the connected user's **User Token Scopes** — never a bot identity. +- **Slack API** — C1 hosts its own MCP server that translates the Slack API into tools. You authorize with per-user OAuth using a Slack app's client ID and secret, and scope access with the **User Token Scopes** you configure. + +| | Slack MCP | Slack API | +| :--- | :--- | :--- | +| **Who hosts the MCP server** | Slack | C1 | +| **Authentication** | Slack's user-token OAuth flow via a Slack app you register (client ID/secret; no dynamic client registration) — or a static user token as a bearer fallback | Per-user OAuth via a Slack app's client ID/secret | +| **Access scoping** | The **User Token Scopes** you request on the Slack app | The **User Token Scopes** you configure | +| **Tool surface** | Slack's own tool set exposed by its hosted MCP server | Channels, messages, users, files, and search, mapped to Slack API endpoints | +| **Setup effort** | Create a Slack app, turn on **Enable MCP**, configure the user-token OAuth flow (or a static token), then register in C1 | Create a Slack app, configure user token scopes, then register in C1 | + +Use the native **Slack MCP** option (listed as plain **Slack** in your catalog) if you want Slack's own hosted tool set and can register a Slack app for its user-token OAuth flow (or a static token). Use **Slack API** if you'd rather use C1's own Slack integration with the scopes-based setup you're already familiar with. + + + + + +C1 registers as a client of Slack's own hosted MCP server ([Slack MCP server](https://docs.slack.dev/ai/slack-mcp-server)) rather than translating the Slack API itself. Your users' AI clients still only ever see C1-governed MCP tools, but C1 proxies each tool call straight through to `mcp.slack.com` under the connected user's authorized session (or a configured static token), then returns the result. The tools available are exactly the ones Slack's own MCP server exposes — C1 doesn't reshape or add to them. + +## Before you begin + +- AI access management must be enabled for your tenant. See [Enable AI access management](/product/admin/enable-ai-access-management). +- Permission to create and configure a Slack app. Unlike some MCP servers, Slack's hosted MCP server doesn't support dynamic client registration, so you register an app and provide its client ID and secret to C1 before anyone can authorize. +- Only a **directory-published** or **internal** Slack app can use the hosted MCP server — see Step 3 below. + + +In your MCP server catalog, this option is listed as **Slack** — distinct from the **Slack API** entry, which connects through C1's own MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. + + +## Create a Slack app for MCP + +Before configuring authentication, register a Slack app and turn on its MCP support. This step comes before any OAuth configuration — Slack's hosted MCP server rejects an app that hasn't enabled it. + + + +Sign in at [api.slack.com/apps](https://api.slack.com/apps) and select **Create New App** > **From scratch**. Enter an app name such as `C1`, pick a workspace to develop in, then select **Create App**. + + +In the app settings sidebar, open **Agents & AI Apps**. Under **Model Context Protocol**, turn on the **Enable MCP** toggle. Without this, Slack's hosted MCP server rejects the app. + + +Make the app eligible to use the MCP server: either submit it to the Slack Marketplace (directory-published), or have a workspace admin install it as an internal app. Keep the app ID fixed once you've registered it in C1, since C1's connection pins to it. + + + +## Slack MCP scopes + +Slack's hosted MCP server authenticates with a Slack **user token** (`xoxp-`), never a bot token, so every scope below is a **User Token Scope** — add them on the app's **OAuth & Permissions** page and leave **Bot Token Scopes** empty. + +Start with the read scopes for browsing channels, messages, users, canvases, files, and search: + +`search:read.public`, `search:read.private`, `search:read.mpim`, `search:read.im`, `search:read.files`, `search:read.users`, `channels:read`, `channels:history`, `groups:read`, `groups:history`, `mpim:read`, `mpim:history`, `im:history`, `canvases:read`, `users:read`, `users:read.email`, `reactions:read`, `emoji:read`, `files:read` + +Add the write scopes only where a tool needs them: + +`chat:write`, `canvases:write`, `reactions:write`, `channels:write`, `groups:write`, `im:write`, `mpim:write` + + +Scope changes take effect the next time a user connects (or the next call using a static token). If you add a scope after users have already connected, each user must reconnect their Slack account — or you must reissue the static token — to grant it. + + +## Option 1: Set up the user-token OAuth flow (recommended) + +With per-user OAuth, each person authorizes individually and tool calls run under that user's own Slack identity. Because the MCP server issues user tokens rather than bot tokens, C1 uses Slack's dedicated user-token OAuth endpoints — authorizing at `slack.com/oauth/v2_user/authorize` and exchanging the code at `slack.com/api/oauth.v2.user.access` — rather than Slack's classic bot-token authorize and token pair. There's no dynamic client registration for this flow: you register the Slack app from the previous step, then provide its client ID and secret to C1. + + + +In the app settings, open **OAuth & Permissions**. Under **Redirect URLs**, select **Add New Redirect URL** and enter exactly: + +``` +https://accounts.conductor.one/auth/callback +``` + +Select **Add**, then **Save URLs**. + + +Still on **OAuth & Permissions**, scroll to **Scopes** and add the **User Token Scopes** the tools need — see [Slack MCP scopes](#slack-mcp-scopes) above. + + +In the left sidebar, open **Basic Information**. Under **App Credentials**, copy the **Client ID**, then reveal and copy the **Client Secret**. + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Slack** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — per-user passthrough** and enter your app's **client ID** and **client secret**, plus the scopes you configured. + + +Save your changes. The first time a user calls a Slack tool from their AI client, they're redirected to Slack to authorize (if they aren't already), then returned to C1. + + + +## Option 2: Use a static user token (Bearer) + +Instead of per-user OAuth, you can connect with a single pre-issued Slack user token. Every tool call then runs as that one token's identity rather than each individual user's. + + + +In the Slack app's **OAuth & Permissions** page, add the same **User Token Scopes** as in [Slack MCP scopes](#slack-mcp-scopes) above. + + +Install the app to the workspace, then copy the **User OAuth Token** (`xoxp-…`) from that page. + + +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Slack** from the catalog. + + +When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **Bearer token** and paste the user token. + + +Save your changes. C1 sends the token as `Authorization: Bearer ` on every call to Slack's MCP server. + + + +The token must carry every scope the tools use; if it's missing a scope, the corresponding tool call fails. Rotate the token in Slack if it's ever exposed. + +## What access is granted + +Tool calls run with whichever **User Token Scopes** you granted — either the connected user's own scopes (per-user OAuth) or the static token's scopes (bearer). This is narrower than a blanket grant of everything the user or token holder can do in Slack: a tool call only succeeds if the relevant scope was requested and approved. + +## How Slack MCP credentials are shared + +How Slack sees your users' activity depends on the method you chose: + +- **Per-user OAuth (recommended).** Each user authorizes with their own Slack account, so tool calls run under that user's Slack user-token identity, scoped to the User Token Scopes you configured. Slack attributes each action to the individual user. +- **Static user token (Bearer).** Every user's tool calls use the one token you provided, so Slack sees a single shared identity. C1 still attributes each call to the individual user in the [AI tool usage audit log](/product/admin/audit-ai-tool-usage). + +For how shared and per-user credentials work across MCP servers, see [Configure authentication](/product/admin/mcp-servers#configure-authentication). + +## Discover and govern tools + +After you register the server, C1 runs tool discovery against Slack's MCP server. Discovered tools appear on the server's **Tools** tab and are exactly the ones Slack's own MCP server exposes. + +Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification). + +Before anyone can call a Slack tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up. + + +Tool discovery runs even if authentication isn't complete yet, so seeing discovered tools doesn't confirm a user has authorized (or that a static token is valid). You confirm access when an approved user successfully calls a Slack tool from their AI client. + + +## Manage access to Slack MCP + +- **Rotate the client secret** on the app's **Basic Information** page under **App Credentials**, then update the secret on the server's authentication settings in C1. +- **Rotate a static user token** by reinstalling the app in Slack to regenerate the **User OAuth Token**, then update it in C1. +- **Revoke access** by uninstalling the Slack app from the workspace on **OAuth & Permissions**, or by turning off the app's **Enable MCP** toggle. +- **Adjust access** by editing the app's **User Token Scopes** on the **OAuth & Permissions** page in Slack. + + + + + The Slack MCP server lets you govern access to Slack — channels, messages, users, files, and search — as tools your AI clients can call through C1. Slack uses per-user OAuth, which is recommended: each person authorizes with their own Slack account, so every tool call runs under that user's identity and permissions. @@ -28,7 +182,7 @@ The credentials you set up below are what C1 uses to call Slack on your users' b - Permission to create and configure a Slack app. See Slack's [guide to installing apps with OAuth](https://docs.slack.dev/authentication/installing-with-oauth/). -If you don't see **Slack** in your MCP server catalog, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. +In your MCP server catalog, this option is listed as **Slack API** — distinct from the **Slack** entry, which connects to Slack's own hosted MCP server. If you don't see either, [contact the C1 support team](mailto:support@c1.ai) to enable it for your tenant. ## Create a Slack app @@ -37,7 +191,7 @@ With per-user OAuth, you register one Slack app and each user authorizes individ -Sign in to the Slack apps dashboard and select **Create New App** > **From scratch**. Enter an app name such as `C1`, pick a workspace to develop in, then select **Create App**. For detail on the OAuth flow, see Slack's [guide to installing apps with OAuth](https://docs.slack.dev/authentication/installing-with-oauth/). +Sign in to the Slack apps dashboard and select **Create New App** > **From scratch**. Enter an app name such as `C1`, pick a workspace to develop in, then select **Create App**. For detail on the OAuth flow, see Slack's [guide to installing apps with OAuth](https://docs.slack.dev/authentication/installing-with-oauth/#how). In the app's left sidebar, open **OAuth & Permissions**. Under **Redirect URLs**, select **Add New Redirect URL** and enter exactly: @@ -95,7 +249,7 @@ Register the server in C1 and connect it to the Slack app you created. -Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Slack** from the catalog. +Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Slack API** from the catalog. When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose per-user OAuth and enter your app's **client ID** and **client secret**, plus the scopes you configured (see [Slack scopes](#slack-scopes)). @@ -121,3 +275,7 @@ Tool discovery runs even if your credentials are incorrect, so seeing discovered - **Rotate the client secret** on the app's **Basic Information** page under **App Credentials**, then update the secret on the server's authentication settings in C1. - **Adjust access** by editing the app's **User Token Scopes** on the **OAuth & Permissions** page in Slack. + + + +