GitHub Copilot

Use browser OAuth for interactive Copilot clients connecting to OneMCP. GitHub's repository cloud agent and code review require a separate token-based setup. These are different clients with different configuration and authentication capabilities.

Documentation checked: October 15, 2026. This guide combines the gateway's documented behavior with official client documentation. Complete the pilot below against your assigned deployment before organization-wide rollout; these instructions are not a live interoperability certification.

Administrator preparation

Get the exact MCP URL from the Quilr dashboard. The public base is https://mcpgateway.quilr.ai, or the exact customer hostname assigned under quilrai.com. A wildcard such as *.quilrai.com is a domain pattern, never a server URL.

Required item	Administrator action
Quilr tenant	Confirm the Quilr tenant ID, which is not automatically the Microsoft Entra tenant ID or GitHub organization name.
Interactive endpoint	Copy the dashboard-provided OneMCP URL. The tenant-scoped example is https://mcpgateway.quilr.ai/quilrone/<quilr-tenant-id>/mcp. Use /quilrone/mcp when that is the URL assigned by the dashboard.
Individual connector	Use https://mcpgateway.quilr.ai/<backend-id>/mcp for a single MCP. Copy the backend ID rather than inferring it from a display name.
Quilr permissions	Permit the pilot users and actual client under server access control and Allowed Agents. Complete upstream connections for the pilot account.
Network	Allow HTTPS from the runtime running MCP and from the browser used for sign-in to the assigned gateway and its advertised authentication endpoints. A successful browser visit alone does not prove a remote development environment can connect.
Client entitlement	Confirm users can use the chosen Copilot product and that organization/enterprise MCP policies allow the gateway.

See client overview and authentication for endpoint selection, token types, and upstream credentials. A GitHub PAT used to sign in to Copilot is not a Quilr gateway credential.

Copilot in VS Code

Add the gateway

1. Open a trusted workspace in a current supported VS Code installation with Copilot enabled.
2. Run MCP: Add Server from the Command Palette, select HTTP, paste the gateway MCP URL, and name the server quilr-onemcp.
3. Select user configuration for personal access or workspace configuration for a reviewed team setup. The equivalent workspace file is .vscode/mcp.json:

{
  "servers": {
    "quilr-onemcp": {
      "type": "http",
      "url": "https://mcpgateway.quilr.ai/quilrone/<quilr-tenant-id>/mcp"
    }
  }
}

Replace the placeholder and host before use. Merge this entry into an existing file instead of replacing unrelated servers. The VS Code format uses servers; portable Copilot configurations use mcpServers. Configuration reference.

4. Run MCP: List Servers, choose quilr-onemcp, and start it. Review any trust prompt.
5. Complete browser sign-in with the permitted company identity.
6. Open an agent chat with tools enabled, confirm the Quilr tools are available, and run the pilot checks below. Server management.

Authentication fields

For the normal OneMCP discovery flow, supply only the MCP URL. VS Code supports OAuth discovery and dynamic client registration. The client obtains the registration details and opens a browser for authorization. VS Code authorization.

OneMCP registration returns a public client with no client secret. Do not put an upstream Microsoft, Salesforce, or other connector's client secret into mcp.json. Do not enable an enterprise-managed identity assertion setting simply because the user's company uses Entra: that is a different protocol and requires separately confirmed server support.

Optional direct-backend API-token configuration

Use this only when the gateway administrator has created an API token for an eligible non-OAuth/static-key MCP. This example does not work for OneMCP:

{
  "servers": {
    "quilr-direct": {
      "type": "http",
      "url": "https://mcpgateway.quilr.ai/<backend-id>/mcp",
      "headers": {
        "Authorization": "Bearer ${input:quilr-api-token}",
        "mcpuser": "user@company.com"
      }
    }
  },
  "inputs": [
    {
      "id": "quilr-api-token",
      "type": "promptString",
      "description": "Quilr API token for this MCP",
      "password": true
    }
  ]
}

The mcpuser value must identify an allowed company user. The token and header are both required for this gateway path. Input prompts avoid committing the token to a repository. VS Code's Copilot harness forwarding excludes servers requiring interactive ${input:...} values; validate the exact session/harness you use. VS Code configuration reference.

Copilot CLI

Add a remote HTTP server from a terminal:

copilot mcp add --transport http quilr-onemcp \
  'https://mcpgateway.quilr.ai/quilrone/<quilr-tenant-id>/mcp'

After replacing the placeholder, launch copilot and inspect /mcp. If sign-in is required, run:

/mcp auth quilr-onemcp

Finish the browser flow. /mcp show quilr-onemcp shows server status and tools. User configuration normally lives at ~/.copilot/mcp-config.json; the CLI does not read .vscode/mcp.json. Its JSON format uses mcpServers. Organization registry and allowlist policies also apply to the CLI. Adding CLI servers.

For a needs-auth status, /mcp auth quilr-onemcp starts a fresh OAuth flow and reconnects. The CLI also documents a headless client_credentials mode, but current OneMCP supports authorization-code exchange, not that grant. Do not configure it for unattended OneMCP access. CLI authentication reference.

GitHub cloud agent and code review

GitHub currently excludes remote MCP OAuth from these repository features. Use a direct endpoint backed by an eligible gateway API token; OneMCP is not an API-token endpoint. Repository administrators configure Settings > Copilot > MCP servers. Enable an explicit tool allowlist because the agent can invoke tools without asking first. Code review additionally requires annotations.readOnlyHint: true in each tool's definition. Repository MCP setup.

Example template:

{
  "mcpServers": {
    "quilr-direct": {
      "type": "http",
      "url": "https://mcpgateway.quilr.ai/<backend-id>/mcp",
      "headers": {
        "Authorization": "Bearer ${COPILOT_MCP_QUILR_TOKEN}",
        "mcpuser": "${COPILOT_MCP_QUILR_USER}"
      },
      "tools": ["REPLACE_WITH_APPROVED_READ_ONLY_TOOL"]
    }
  }
}

Create an Agents secret named COPILOT_MCP_QUILR_TOKEN and an Agents variable or secret named COPILOT_MCP_QUILR_USER. Replace the backend ID, host, and tool name before saving the repository configuration. GitHub only exposes names prefixed COPILOT_MCP_ to this configuration. Secret substitution and validation.

For Quilr, use an explicitly approved automation identity and record its owner. This is a shared configured identity; it does not become each pull-request author's identity. Verify the token is scoped to the intended agent and backend, and that the email is allowed. If the server requires OAuth and cannot issue an API token, do not copy a browser token into a long-lived repository secret as a workaround; this integration needs an approved non-interactive authentication design.

Pilot and acceptance checks

1. Connect as a normal allowed user, not only as a gateway administrator.
2. Verify the gateway audit records show the expected tenant, backend, user, and client.
3. List tools. OneMCP dynamic mode may expose router tools such as list_mcp_connections, find_relevant_tools, and call_tool; a short list does not necessarily mean upstream tools are missing.
4. Perform one approved read-only operation against a test record the user is allowed to access. Verify its result against the upstream service.
5. Test a user without access and confirm rejection. Confirm an unapproved tool is unavailable or blocked.
6. Reconnect after restarting the client. Exercise token revocation and recovery in the pilot before documenting an operational procedure.
7. Record the client version, gateway deployment, configuration scope, test identity, expected tool names, and evidence. Repeat for each runtime, including remote development and repository cloud agents when used.

Troubleshooting and removal

Symptom	First checks
VS Code server missing	Confirm .vscode/mcp.json uses servers; check the active profile, workspace, and remote configuration.
CLI server missing	Confirm the CLI configuration uses mcpServers; inspect /mcp and enterprise allowlist restrictions.
No browser sign-in	Inspect the initial 401 and discovery metadata using authentication checks. Check the assigned host and browser popup restrictions.
Sign-in succeeds, tool call denied	Check Quilr Allowed Agents, user/group access, and the user's upstream connection.
Empty or stale tools	Reconnect; in VS Code use MCP: Reset Cached Tools. Check gateway visibility rules and OneMCP dynamic mode.
Repository cloud agent cannot connect to OneMCP	Remote OAuth is unsupported there. Use the eligible direct-backend setup above.
Code review omits a listed tool	Check the tool allowlist and the upstream tool's readOnlyHint annotation.
Token example gets 401	Confirm this is a direct backend, the correct API token, and both required headers.

Use MCP: List Servers > Show Output for VS Code diagnostics. Remove or disable the configuration when retiring access, and revoke the associated gateway credential as appropriate; removing a JSON entry alone does not revoke a credential. See shared troubleshooting.