ConductorOne · c1-squire-dev · Sep 11, 2026 · Sep 11, 2026 · Sep 11, 2026
diff --git a/docs.json b/docs.json
@@ -252,7 +252,7 @@
                 ]
               },
               {
-                "group": "MCP servers",
+                "group": "MCP sources",
                 "tag": "NEW",
                 "pages": [
                   "product/admin/mcp-servers",

diff --git a/product/admin/aiam-overview.mdx b/product/admin/aiam-overview.mdx
@@ -1,8 +1,8 @@
 ---
 title: AI access management overview
-description: How C1 governs AI tool and resource access — MCP servers, tools, toolsets, and AI clients.
+description: How C1 governs AI tool and resource access — MCP sources, tools, toolsets, and AI clients.
 og:title: AI access management overview - C1 docs
-og:description: How C1 governs AI tool and resource access — MCP servers, tools, toolsets, and AI clients.
+og:description: How C1 governs AI tool and resource access — MCP sources, tools, toolsets, and AI clients.
 sidebarTitle: How AIAM works
 ---
 
@@ -12,14 +12,14 @@
 **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.
 </Note>
 
-AI Access Management (AIAM) extends C1's identity governance platform to the AI tool layer. It acts as a control plane between AI clients (Claude Desktop, Cursor, ChatGPT, Copilot, and other MCP-compatible clients) and the downstream MCP servers those clients connect to.
+AI Access Management (AIAM) extends C1's identity governance platform to the AI tool layer. It acts as a control plane between AI clients (Claude Desktop, Cursor, ChatGPT, Copilot, and other MCP-compatible clients) and the MCP sources your organization governs.
 
-When AIAM is enabled, every tool call from an AI client is routed through C1's identity-aware proxy. The proxy authenticates the caller, checks the tool call against the user's granted access profile, enforces any configured policy constraints, forwards the call to the downstream MCP server, and writes an audit log entry with full identity context.
+When AIAM is enabled, every tool call from an AI client is routed through C1's identity-aware proxy. The proxy authenticates the caller, checks the tool call against the user's granted access profile, enforces any configured policy constraints, forwards the call to the source's MCP server, and writes an audit log entry with full identity context.
 
 AIAM covers the following capabilities:
 
-- Registering and configuring MCP servers (from the 3,000+ hosted catalog)
-- Discovering and classifying the tools and resources each server exposes
+- Adding and configuring MCP sources from the catalog or an external URL
+- Discovering and classifying the tools and resources each source exposes
 - Governing tool access at a granular level — admins review, approve, or disable individual tools and control which tools each user and agent can call
 - Governing resource access at a granular level — admins review, approve, or disable each static resource and URI template; C1 checks its linked read entitlement on every read
 - Bundling approved tools into toolsets and binding them to access profiles
@@ -35,23 +35,23 @@
 
 | Concept | Description |
 | :--- | :--- |
-| **MCP server** | A downstream service that exposes one or more tools via the Model Context Protocol. C1 hosts a curated catalog. |
-| **C1 MCP** | The proxy your AI clients connect to. It accepts connections from AI clients, routes requests to the appropriate downstream servers, and enforces authorization on every tool call. AI clients connect to one URL — C1 MCP — not to each downstream server directly. |
-| **Tool** | A single capability exposed by an MCP server (for example, `github_create_issue` or `salesforce_query`). C1 discovers tools automatically when an MCP server is registered. |
-| **MCP resource** | A static resource or URI template exposed by an MCP server. C1 discovers it automatically. C1 checks its approval state and linked, resource-specific read entitlement on every read. Resources are not toolsets or catalog items. |
-| **Toolset** | A named bundle of approved tools. Two kinds: C1-maintained per connector ("All approved tools" and "Read tools", suffixed with the server name) and custom (admin-curated). |
+| **MCP source** | An upstream MCP endpoint or integration from which C1 discovers and governs tools. A Catalog MCP source comes from C1's available catalog; an External MCP source uses a customer- or vendor-provided endpoint. |
+| **C1 MCP** | The proxy your AI clients connect to. It accepts connections from AI clients, routes requests to the appropriate MCP sources, and enforces authorization on every tool call. AI clients connect to one URL — C1 MCP — not to each upstream MCP server directly. |
+| **Tool** | A single capability exposed by an MCP source (for example, `github_create_issue` or `salesforce_query`). C1 discovers tools automatically when a source is added. |
+| **MCP resource** | A static resource or URI template exposed by an MCP source. C1 discovers it automatically. C1 checks its approval state and linked, resource-specific read entitlement on every read. Resources are not toolsets or catalog items. |
+| **Toolset** | A named bundle of approved tools. Two kinds: C1-maintained per source ("All approved tools" and "Read tools", suffixed with the source name) and custom (admin-curated). |
 | **Access profile** | The same mechanism C1 already uses for traditional app access. A toolset is bound to an access profile, which carries the approval policy, expiry, and approvers. |
 | **AI client** | A specific registered AI client instance (for example, "Jess's Claude Desktop" or "the team's shared Cursor agent"). Registered via Dynamic Client Registration (DCR) or Client ID Metadata Document (CIMD). |
 | **AI connection** | The authenticated link between a user's AI client and C1. When a user connects an AI client to C1, C1 creates an AI connection record that ties the client instance to the user's identity. Admins can view, manage, and revoke AI connections across the tenant. |
-| **Auth mode** | How an MCP server authenticates downstream. Supported methods include bearer token, custom header, basic auth, and OAuth2 (client credentials, service mode, per-user passthrough, and JWT bearer). |
+| **Auth mode** | How C1 authenticates to an MCP source. Supported methods include bearer token, custom header, basic auth, and OAuth2 (client credentials, service mode, per-user passthrough, and JWT bearer). |
 | **Client type** | A classification on each AI client: personal, shared, service, or ephemeral. Tenant-level policy controls which types are allowed. |
 
 ## How the pieces fit together
 
 A typical end-to-end flow:
 
-1. **Admin registers an MCP server** in C1 (for example, the GitHub MCP server) and configures its auth mode.
-2. **C1 discovers the tools and resources** the server exposes. Tools begin as Unset; resources begin as Pending.
+1. **Admin adds an MCP source** in C1 (for example, the GitHub Catalog MCP source) and configures its auth mode.
+2. **C1 discovers the tools and resources** the source exposes. Tools begin as Unset; resources begin as Pending.
 3. **Admin reviews and approves tools**, then bundles approved tools into a toolset.
 4. **Admin reviews and approves resources**. C1 links each approved resource to its resource-specific read entitlement; resources remain independent of toolsets.
 5. **Admin binds the toolset to an access profile** with an approval policy.
@@ -63,7 +63,7 @@
 ## Where to go from here
 
 - New to AIAM? Start with [Enable AI access management](/product/admin/enable-ai-access-management).
-- Already enabled? Move on to [Set up an MCP server](/product/admin/mcp-servers).
+- Already enabled? Move on to [Set up an MCP source](/product/admin/mcp-servers).
 - Setting up audit and compliance? See [Audit AI tool usage](/product/admin/audit-ai-tool-usage).
 - Ready to test your setup as an end user? See [Get started with AI tools](/product/how-to/ai-tools).
 - Need to approve a discovered resource or manage its access? See [Govern MCP resources](/product/admin/mcp-resources).

diff --git a/product/admin/audit-ai-tool-usage.mdx b/product/admin/audit-ai-tool-usage.mdx
@@ -8,7 +8,7 @@
 {/* Editor Refresh: 2026-05-08 */}

 <Note>
 **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.
 </Note>

 Every tool call and resource read that flows through C1 MCP is logged. This page covers what's captured and how to export it for long-term retention, SIEM ingestion, or compliance reviews.
@@ -22,21 +22,21 @@
 | **Timestamp** | `2026-05-07T14:23:11Z` |
 | **End user** | The C1 user the AI client is bound to |
 | **AI client** | Client ID and display name |
-| **MCP server** | Registered server name |
+| **MCP source** | MCP source name |
 | **Tool** | Tool name (for example, `github_create_issue`) |
 | **Result** | Success / denied / error |
 | **Denial reason** | Populated when result = denied (for example, "tool not in user's access profile", "kill switch active", "client closed") |
 | **Latency** | Round-trip time for the call |
 
-Each MCP resource read also produces an audit log entry. It includes the end user, AI client, MCP server, resource URI or URI template, result, denial reason when applicable, latency, and response byte count. C1 does not store resource content in the audit event.
+Each MCP resource read also produces an audit log entry. It includes the end user, AI client, MCP source, resource URI or URI template, result, denial reason when applicable, latency, and response byte count. C1 does not store resource content in the audit event.
 
 In addition to tool call events, the following non-call events are also captured:
 
 - Access request submitted / approved / denied
 - Tool approved / disabled / classification changed
-- MCP server registered / removed / auth changed
+- MCP source added / removed / auth changed
 - AI client registered / state changed (active → hidden → closed → deleted)
-- Kill switch flipped (tenant, server, tool, or client level)
+- Kill switch flipped (tenant, source, tool, or client level)
 - Tenant defaults changed
 
 ## Review AI agent conversations

diff --git a/product/admin/code-mode.mdx b/product/admin/code-mode.mdx
@@ -15,9 +15,9 @@
 
 ## How the gateway fits in
 
-C1 is an MCP gateway. AI clients connect to one C1 MCP endpoint, and C1 sits in front of every MCP server and integration your organization has approved. Agents never connect to those servers directly.
+C1 is an MCP gateway. AI clients connect to one C1 MCP endpoint, and C1 sits in front of every MCP source your organization has approved. Agents never connect to those upstream MCP servers directly.
 
-On each call, C1 authenticates the human or workload behind the agent, applies per-tool governance, and routes the call to the right upstream server — a hosted server from the catalog, a vendor MCP server, or a private server reached over an [MCP bridge](/product/admin/mcp-server/mcp-bridge). One MCP connection, many governed systems behind it.
+On each call, C1 authenticates the human or workload behind the agent, applies per-tool governance, and routes the call to the right MCP source — a Catalog MCP source, an External MCP source at a vendor-provided endpoint, or an External MCP source reached over an [MCP bridge](/product/admin/mcp-server/mcp-bridge). One MCP connection, many governed systems behind it.
 
 ## What code mode changes
 
@@ -73,7 +73,7 @@

 ### One program per call

 Each `execute` call deploys an ephemeral function, while `tools.X()` calls inside the running program are fast. An agent that needs six tool calls should write one program that makes all six, not six `execute` calls. Dependent calls become sequential `await`s; independent lookups go in a `Promise.all()`.

 ### Example: paginate a large result set

@@ -117,7 +117,7 @@
 }
 ```

 The tool is requestable but not yet granted, so C1 opened an access request on the caller's behalf. **The upstream API was not called.** Approval runs through the tool's normal policy — manager approval and the rest — and once the grant lands, the same call executes.

 ```json
 {
@@ -138,13 +138,13 @@

 A program that runs past the synchronous wait window of roughly 25 seconds doesn't fail. `execute` returns `{ "status": "pending", "execution_id": "..." }` and the program keeps running server-side.

 The agent then polls `get_execution` with that `execution_id`. Each response carries a `status` of `pending`, `running`, `success`, or `error`, plus the full output and logs once the program finishes either way. Poll with exponential backoff — 1 second, then 2, 4, 8, 16, 30, capped at 30 seconds — and do other independent work in between rather than polling in a tight loop.

 Executions are capped at 15 minutes total; the polling response reports elapsed and remaining time. The `execution_id` is opaque and scoped to the calling session's tenant and principal, so it's useful for the polling loop and nothing beyond it.
 
 ## Where to go from here
 
-- Setting up the servers behind the gateway? See [Set up an MCP server](/product/admin/mcp-servers).
+- Setting up the sources behind the gateway? See [Set up an MCP source](/product/admin/mcp-servers).
 - Governing which tools are callable? See [Govern tools and toolsets](/product/admin/tools-and-toolsets).
 - Constraining calls at runtime? See [Tool call hooks](/product/admin/tool-call-hooks).
 - Reviewing what agents actually called? See [Audit AI tool usage](/product/admin/audit-ai-tool-usage).

diff --git a/product/admin/enable-ai-access-management.mdx b/product/admin/enable-ai-access-management.mdx
@@ -1,23 +1,23 @@
 ---
 title: Enable AI access management
-description: Turn on AIAM for your tenant and configure tenant-wide defaults for MCP servers, tools, and AI clients.
+description: Turn on AIAM for your tenant and configure tenant-wide defaults for MCP sources, tools, and AI clients.
 og:title: Enable AI access management - C1 docs
-og:description: Turn on AIAM for your tenant and configure tenant-wide defaults for MCP servers, tools, and AI clients.
+og:description: Turn on AIAM for your tenant and configure tenant-wide defaults for MCP sources, tools, and AI clients.
 ---
 
 {/* Editor Refresh: 2026-09-02 */}

 <Note>
 **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.
 </Note>
 
-AIAM lets you govern which AI clients can call which tools on your behalf, and which end users are allowed to use them. Enabling AIAM for your tenant is a one-time task that requires the **Super Administrator** role. Configuring tenant defaults, registering MCP servers, governing tools, managing AI clients, and using kill switches can be performed by either a Super Administrator or a user with the [AI Governance Administrator](/product/admin/user-roles#ai-governance-administrator) role.
+AIAM lets you govern which AI clients can call which tools on your behalf, and which end users are allowed to use them. Enabling AIAM for your tenant is a one-time task that requires the **Super Administrator** role. Configuring tenant defaults, adding MCP sources, governing tools, managing AI clients, and using kill switches can be performed by either a Super Administrator or a user with the [AI Governance Administrator](/product/admin/user-roles#ai-governance-administrator) role.
 
-Individual MCP servers, tools, and clients can override most of these defaults later. Set the defaults to the safest configuration you're willing to live with as a fallback.
+Individual MCP sources, tools, and clients can override most of these defaults later. Set the defaults to the safest configuration you're willing to live with as a fallback.
 
 ## Enable AIAM for your tenant
 
-Enabling AIAM exposes the AIAM surfaces (MCP servers, tools, AI clients, AIAM audit log) to admins. It does **not** automatically grant any end user access to any tool — every tool still has to be approved, added to a toolset, and bound to an access profile before it becomes requestable.
+Enabling AIAM exposes the AIAM surfaces (MCP sources, tools, AI clients, AIAM audit log) to admins. It does **not** automatically grant any end user access to any tool — every tool still has to be approved, added to a toolset, and bound to an access profile before it becomes requestable.
 
 <Steps>
 <Step>
@@ -37,7 +37,7 @@
 </Step>
 </Steps>
 
-Once enabled, **MCP servers**, **MCP clients**, and the **AIAM audit log** appear in the tenant.
+Once enabled, **MCP sources**, **MCP clients**, and the **AIAM audit log** appear in the tenant.
 
 ## Configure tenant defaults
 
@@ -76,7 +76,7 @@
 
 ### Default tool classification
 
-When C1 discovers a new tool on a registered MCP server, it assigns the tool this initial state. Until an admin reviews and approves the tool, it cannot be added to a toolset and end users cannot request it.
+When C1 discovers a new tool from an MCP source, it assigns the tool this initial state. Until an admin reviews and approves the tool, it cannot be added to a toolset and end users cannot request it.
 
 - **State**: Pending Review / Unset (recommended — keeps every newly-discovered tool out of end-user reach until you've reviewed it)
 - **Classification**: Sensitive (default)
@@ -85,7 +85,7 @@
 
 <Steps>
 <Step>
-In **AI > MCPs > Settings**, find **Default tool classification**.
+In **AI > MCP Sources > Settings**, find **Default tool classification**.
 </Step>
 <Step>
 Select the state and classification to apply to newly-discovered tools.
@@ -97,13 +97,13 @@

 ### Require tool approval

 When on, every newly-discovered tool starts in **Pending Review** and must be approved by an admin before it can be added to a toolset. When off, tools become available to be added to toolsets immediately on discovery.

 - **Default**: On
 - **Recommended**: On for production tenants. Off is appropriate only for sandbox tenants where you're testing the end-to-end flow.

 <Note>
 Turning this off does not bypass access profile approval — end users still go through the access profile's approval policy when they request a toolset.
 </Note>

 ### Client lifecycle policy
@@ -134,7 +134,7 @@
 
 ### Emergency kill switch
 
-The kill switch immediately revokes every AI client's access to every tool, across all MCP servers in your tenant. Use it when you suspect an active compromise — for example, a leaked client credential or an MCP server that's behaving unexpectedly.
+The kill switch immediately revokes every AI client's access to every tool, across all MCP sources in your tenant. Use it when you suspect an active compromise — for example, a leaked client credential or an MCP server that's behaving unexpectedly.
 
 **What happens when you flip it:**
 
@@ -152,13 +152,13 @@
 </Step>
 </Steps>
 
-### Per-server kill switch
+### Per-source kill switch
 
-Each registered MCP server also has its own kill switch, independent of the tenant-wide one. Flipping it blocks all MCP requests for that connector only — other servers keep working.
+Each MCP source also has its own kill switch, independent of the tenant-wide one. Flipping it blocks all MCP requests for that source only — other sources keep working.
 
 <Steps>
 <Step>
-Open the MCP server's configuration tab.
+Open the MCP source's configuration tab.
 </Step>
 <Step>
 Toggle the kill switch.
@@ -168,5 +168,5 @@
 </Step>
 </Steps>
 
-Combined with the per-tool kill switch ([Govern tools and toolsets](/product/admin/tools-and-toolsets)) and the per-client kill switch ([Manage AI clients](/product/admin/ai-clients)), C1 offers kill switches at four scopes: tenant, server, tool, and client.
+Combined with the per-tool kill switch ([Govern tools and toolsets](/product/admin/tools-and-toolsets)) and the per-client kill switch ([Manage AI clients](/product/admin/ai-clients)), C1 offers kill switches at four scopes: tenant, source, tool, and client.