# MCP Configure Model Context Protocol (MCP) actions in Quor Model Context Protocol (MCP) enables AI Agents to invoke tools and services in a controlled manner. You can configure Quor to be an MCP client and allow your Agents to retrieve data or perform operations. Quor can also act as an MCP server! See the [Quor MCP Server](/overview/onyx_anywhere/mcp_server) guide to connect Claude, Cursor, and other AI tools to your Quor knowledge base. ## MCP in Quor Click your user profile icon and select **Admin Panel** and select the **MCP Actions** tab in the sidebar. MCP Actions dashboard in Quor Admin Panel Click the **Add MCP Server** button and fill out the following fields: Add MCP Server dialog in Quor Admin Panel - **Server Name** — A human-readable name for this MCP server. Typically the name of the service you're connecting to (e.g. "Slack", "Jira"). - **Description** — Any additional information that helps identify the server. Useful for distinguishing multiple configured MCP server connections that talk to the same service. - **MCP Server URL** — The URL of the MCP server, which must be reachable from your Quor instance. Most URLs end in `/mcp`, or `/sse` for older servers. - **Managed MCP server:** The URL is typically found in the provider's documentation describing how to connect. - **Self-hosted MCP server:** You'll need to run your server in HTTP transport mode — Quor doesn't currently support connecting via stdio. If the server is running on the same machine as Quor, use `http://127.0.0.1:`. Otherwise, use the URL and port the server is exposed at. When you click **Add Server**, Quor will create the server in a **disconnected** state. The next steps will set up authentication (if any) and validate that Quor can connect to it. MCP server authentication configuration in Quor Quor supports four authentication types when connecting to an MCP server: ### No Auth Use this when your MCP server is unprotected. Typically only used for testing when connecting to a local MCP server on a local Quor instance, but may be useful if the server is deployed inside a VPC and you want all users to have the same unrestricted access to it. ### API Key The server is protected by API key authentication, typically using the `Authorization: Bearer ` format. There are two sub-modes: - **Shared Key** — The admin configures a single API key used for all user requests. Similar to No Auth in that users won't need any additional configuration and will all get the same level of access (whatever is provided by the API key you choose). - **Individual Key** — Users authenticate in the chat flow by providing their own API key(s) to connect to the server. Useful when you want users to have differing access to an external service by identity. This mode is also the most configurable — Quor allows the admin to specify arbitrary header patterns to send to the MCP server. ### OAuth Many modern MCP servers support OAuth authentication to give users access to tools and data using the same login flow they use when manually accessing the service. Many OAuth-enabled MCP servers support [Client ID Metadata Documents (CIMD)](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) or [Dynamic Client Registration (DCR)](https://datatracker.ietf.org/doc/html/rfc7591). These standards let Quor connect without a manually configured **Client ID** or **Client Secret**. In most cases, you can simply click **Connect** and complete the OAuth flow. If the MCP server's documentation requires you to register an OAuth app: 1. Create an OAuth app in the IdP (Identity Provider) used by the MCP server. 2. Add the following Quor callback URL to the app: `https:///mcp/oauth/callback` 3. Enter the generated **Client ID** and **Client Secret** in Quor, then click **Connect**. On HTTPS deployments, Quor automatically publishes and uses a deployment-level, Quor-branded CIMD at `https:///api/mcp/oauth/client-metadata` when the authorization server supports it. HTTP local development uses DCR instead. ### Pass-Through OAuth Only available when your Quor instance is configured to authenticate via OAuth. In this mode, Quor passes the user's OAuth access token through as an `Authorization: Bearer` header to the MCP server. This is most often useful if your organization hosts its own MCP servers and would rather not require users to authenticate again after already going through the OAuth flow to log in to Quor. Many MCP servers require scopes that Quor does not request by default during login. Check the MCP server's documentation for the exact scopes it requires, then add them to the comma-separated scope override for your authentication type: - **Google OAuth:** `GOOGLE_OAUTH_SCOPE_OVERRIDE` - **OIDC:** `OIDC_SCOPE_OVERRIDE` These settings replace the default scopes, so retain `openid`, `email`, and `profile` alongside the additional scopes. See [Google OAuth scope configuration](/deployment/authentication/oauth#customizing-requested-scopes) or [OIDC scope configuration](/deployment/authentication/oidc#customizing-requested-scopes) for examples. Requesting a scope in Quor does not guarantee that the identity provider will grant it. The scope must also be exposed and permitted for the Quor OAuth/OIDC client in the identity provider, and some providers require an administrator to grant consent. The exact configuration varies by provider. The issued access token must include both the required scopes and an audience accepted by the MCP server. --- Clicking **Connect** will validate that Quor can reach the MCP server using the provided authentication method. The MCP Actions dashboard then lets the admin list the tools available from the MCP server and select which subset of tools should be made available for use in Agents across the organization.