Config Manager OverviewConfig Manager Concepts

Remote MCP Access

View as Markdown

NVIDIA Config Manager includes a remote Model Context Protocol (MCP) server for MCP-capable clients. The MCP server runs inside the Config Manager deployment. You do not need to run a local MCP server.

Use MCP when you want an assistant or other MCP-capable client to answer operational questions from Config Manager data, such as Nautobot inventory, DHCP reservations, stored device configs, workflow history, and selected safe workflow actions.

Quick Setup

There are three supported ways to connect to the MCP server.

Use the helper CLI

The nvcm-mcp-cli helper discovers the MCP endpoint, handles OIDC login when SSO is enabled, and prints generic Streamable HTTP connection details.

1nvcm-mcp-cli config -H config-manager.example.com

For SSO-enabled environments, sign in first:

1nvcm-mcp-cli login -H config-manager.example.com

The helper opens a browser when a fresh OIDC login is required. If the browser does not open automatically, it prints the login URL. After login, the helper caches the user token locally.

You can also print just the endpoint or token:

1nvcm-mcp-cli endpoint -H config-manager.example.com
2nvcm-mcp-cli token -H config-manager.example.com

For local development environments that use a self-signed certificate, add -k.

Use client-native OAuth

Remote MCP clients with native OAuth support can authenticate directly against the MCP endpoint when SSO is enabled. The MCP service exposes standard OAuth discovery metadata at the MCP host under /.well-known/.

The OAuth client ID is required. Config Manager does not support OAuth Dynamic Client Registration, so the client must be configured with the public/native OIDC client ID from the Config Manager auth discovery endpoint.

Get the client ID and MCP URL from /auth/discovery:

1DISCOVERY_JSON=$(curl -fsS https://config-manager.example.com/auth/discovery)
2
3CLIENT_ID=$(printf '%s' "$DISCOVERY_JSON" | jq -r '.clientId')
4MCP_URL=$(printf '%s' "$DISCOVERY_JSON" | jq -r '.services.mcp')

The response includes the same fields directly:

1{
2  "authRequired": true,
3  "issuerUrl": "https://idp.example.com/realms/nv-config-manager",
4  "clientId": "nv-config-manager-cli",
5  "scopes": ["openid", "profile", "email"],
6  "services": {
7    "mcp": "https://svc-mcp.config-manager.example.com/mcp"
8  }
9}

For Codex, add the Streamable HTTP MCP server with the client ID, then log in:

1codex mcp add nv-config-manager \
2  --url "$MCP_URL" \
3  --oauth-client-id "$CLIENT_ID"
4
5codex mcp login nv-config-manager

For Claude Code, add the HTTP MCP server with the same client ID:

1claude mcp add --transport http \
2  --client-id "$CLIENT_ID" \
3  nv-config-manager "$MCP_URL"

If your identity provider requires a pre-registered localhost callback URI, also pass --callback-port <port> and register http://localhost:<port>/callback with the client.

After adding the server, run /mcp in Claude Code and select Authenticate. Claude Code should discover the MCP OAuth metadata from the remote endpoint and print or open the browser login URL.

For other MCP clients, configure:

SettingValue
TransportStreamable HTTP
URLhttps://svc-mcp.<hostname>/mcp, or the endpoint from /auth/discovery
OAuth flowAuthorization Code with PKCE
Client IDRequired; use clientId from /auth/discovery

Clients that expect OAuth Dynamic Client Registration and do not let you provide a client ID cannot complete the native OAuth flow. Use the nvcm-mcp-cli helper and bearer-token configuration for those clients.

Provider examples

Keep the default Helm setting:

1mcp:
2  auth:
3    oauth:
4      forwardResourceParameter: true

The MCP protected-resource metadata advertises the HTTPS MCP endpoint as resource and the Keycloak realm as its authorization server. OAuth requests go directly to Keycloak, including the RFC 8707 resource parameter supplied by the MCP client.

Create a public/native Keycloak client for MCP clients and allow its loopback redirect URIs. DCR-oriented MCP CLIs can use a redirect URI with an ephemeral port and per-login path:

http://127.0.0.1:<port>/callback/<login-id>

Configure an appropriate Keycloak redirect URI pattern, such as http://127.0.0.1:*, and pass the preconfigured client ID when adding the server.

Microsoft Entra ID v2 can reject a token request when the RFC 8707 resource parameter contains the HTTPS MCP resource while the requested API scopes use a different Application ID URI, such as api://<application-id>. Use the MCP compatibility bridge for this configuration:

1mcp:
2  auth:
3    oauth:
4      forwardResourceParameter: false

The compatibility bridge preserves the RFC 9728 metadata contract: resource remains the HTTPS MCP endpoint. It advertises OAuth endpoints on the MCP origin, removes resource before forwarding authorization and token requests to Entra, and leaves the configured API scopes unchanged.

DCR-oriented MCP CLIs can generate a different loopback callback path for each login. The bridge presents one fixed HTTPS callback to Entra, then relays the authorization response to the MCP CLI’s loopback listener while preserving OAuth state and PKCE. Register this exact redirect URI on the Entra public client:

https://svc-mcp.<hostname>/oauth/callback

Add the server with the preconfigured Entra public-client ID and without --oauth-resource. The callback relay accepts loopback callbacks using 127.0.0.1, an explicit port, and a /callback/<login-id> path. Other native MCP clients should use the direct provider pattern unless their callback format is supported by the bridge.

Use discovery directly

You can also tell an MCP-capable assistant or client to discover the server details from:

https://config-manager.example.com/auth/discovery

For example:

Connect to the NVIDIA Config Manager MCP server. Discover the MCP endpoint and auth details from https://config-manager.example.com/auth/discovery. Do not start a local MCP server.

The discovery response tells the client which remote MCP endpoint to use and whether bearer authentication is required. In SSO-enabled environments, the MCP tools act with the signed-in user’s bearer token. They do not switch to broader service credentials for Config Manager APIs.

Client Settings

Use these settings when configuring a client manually:

SettingValue
TransportStreamable HTTP
URLUse nvcm-mcp-cli endpoint -H <hostname> or the endpoint from /auth/discovery
AuthenticationUse client-native OAuth with an explicit client ID, or use bearer authentication when discovery or the helper says it is required
OAuth client IDRequired for client-native OAuth; use clientId from /auth/discovery

When bearer authentication is required, prefer an environment variable or the client’s secret storage instead of writing tokens into static configuration files.

What You Can Ask

The available tools are discoverable at runtime, so exact tool names may vary by deployment. In general, the operational Config Manager MCP server can answer questions like these:

  • “Find device leaf1.example.com and summarize its role, site, serial number, platform, and Nautobot ID.”
  • “How many DHCP reservations do we have, split by pool reservations and static reservations?”
  • “Show the DHCP reservation details for leaf1.example.com.”
  • “List the intended config files for leaf1.example.com.”
  • “Show the latest stored running config for this device, with secrets redacted.”
  • “Compare two stored config versions for this device and summarize the differences.”
  • “List recent failed workflows for this site and include the Config Manager workflow links.”
  • “Run a backup for leaf1.example.com and give me the workflow URL.”
  • “Run cable validation for this site and summarize the result.”
  • “Check the InfiniBand fabric for unhealthy ports.”

MCP clients can also inspect the Nautobot GraphQL schema through the server. If you are asking a broad inventory question, it is usually best to let the client explore the schema and then issue targeted read-only queries.

Public Documentation MCP

NVIDIA also publishes a public documentation MCP server for Config Manager:

https://docs.nvidia.com/switch-infrastructure/config-manager/_mcp/server

Connect to this as a separate MCP server when you want product documentation, usage guidance, or conceptual reference. It does not require authentication.

The operational Config Manager MCP server includes a list_related_mcp_servers tool that returns the public docs MCP URL for clients that support discovering related servers.

Examples of documentation-focused questions:

  • “Find the Config Manager documentation for MCP setup.”
  • “Explain how Config Manager handles workflow approvals.”
  • “What does the backup workflow do?”
  • “Find the installation guidance for SSO-enabled deployments.”
  • “Which documented workflow should I use to validate cabling?”

For the best results, connect both MCP servers: use the deployment MCP server for live operational data, and use the public documentation MCP server for product guidance.

Security Notes

  • The bearer token represents the signed-in user.
  • MCP tools use the caller’s access for Config Manager APIs.
  • External Nautobot deployments may use a configured read-only Nautobot token for MCP Nautobot queries.
  • OAuth discovery metadata does not register clients. Native OAuth MCP clients must use a preconfigured public/native OIDC client ID.
  • Native OAuth MCP clients should not use an OIDC client secret.
  • Protected-resource metadata always advertises the HTTPS MCP endpoint as its RFC 9728 resource.
  • Entra compatibility mode changes upstream request forwarding, not the resource advertised in metadata.
  • Token values should be treated as secrets and kept out of documentation, logs, and committed configuration.