Skip to main content
Use MCP Servers to bring a hosted, self-hosted, registry-provided, or deployable MCP server under MCP Foundry governance. After configuration, validate the connected catalog and expose only the approved capabilities through a virtual server. This guide focuses on the configuration lifecycle. It does not assume that every connected capability should be published to every client.

​
Before you begin

Gather the information appropriate to the server type: Also identify the owning team, the intended clients, and the smallest set of capabilities required for the use case.
Security note: Store and manage credentials according to your organization’s secret-handling policy. Do not use a broad administrator credential when a server-specific, least-privileged credential is available.

​
1. Select the server source

  1. Open MCP Servers in the MCP Foundry dashboard.
  2. To use a pre-integrated option, select Browse Registry and choose the server that matches your use case.
  3. To connect an existing deployment, add the server and select its transport or connection type.
  4. To expose a command-line or packaged server, choose the deploy or wrapper workflow supported by your deployment.
Describe the server in terms that help catalog users understand its business purpose and data boundary—for example, “read-only customer knowledge” rather than a generic product name.

​
2. Configure the connection

Provide the server address and select the transport that the server supports. Confirm that the address is reachable from the MCP Foundry deployment, not only from your local workstation. Check these items before continuing:
  • The URL uses the expected protocol and points to the intended environment.
  • Network policy, DNS, proxy, and TLS configuration permit MCP Foundry to reach the server.
  • The selected transport matches the server implementation.
  • Timeouts are suitable for the server’s expected response time.
  • For command-line workloads, required binaries and dependencies are available in the execution environment.

​
3. Configure authentication and access

Set the credentials or authentication method required by the connected server. Then establish its governance boundary:
  1. Assign ownership to the responsible team.
  2. Choose visibility appropriate to the intended audience.
  3. Limit the credentials to the APIs, data, and actions required by the server.
  4. When filesystem access is relevant, configure Roots so the server can access only explicitly permitted directories.
  5. Use API Tokens for programmatic clients and rotate or revoke tokens according to policy.
A connected server and a virtual server are separate controls. Connecting a server makes it manageable; attaching capabilities to a virtual server determines what an MCP client can discover and use.

​
4. Validate the connected catalog

After saving the connection, verify server health and inspect the catalog it provides.
  • Confirm the server reports as reachable or healthy.
  • Review imported tools, resources, and prompts for names, descriptions, and expected scope.
  • Exercise a safe, read-only capability where possible.
  • Check that backend authentication behaves as expected.
  • Review logs for connection failures, authorization errors, or protocol mismatches.
If the server returns more capabilities than the use case requires, do not publish them by default. Curate the client-facing catalog in the next step.

​
5. Publish approved capabilities through a virtual server

  1. Open Virtual Servers and create a new server or edit an existing one.
  2. Configure the client connection and visibility for the virtual server.
  3. Attach only the approved tools, resources, prompts, and skills supplied by the connected MCP server or local catalog.
  4. Save or publish the virtual server.
  5. Open Playground, select the virtual server, and confirm that clients see only the curated catalog.

​
6. Monitor and maintain the integration

Review dashboard metrics and Logs after release. Investigate increases in latency, errors, denied requests, or unexpected tool usage. When the remote server changes, revalidate its connection and catalog before expanding its virtual-server exposure. For additional help, see Troubleshooting and MCP Foundry concepts.