> ## Documentation Index > Fetch the complete documentation index at: https://docs.budecosystem.com/llms.txt > Use this file to discover all available pages before exploring further. # Configure MCP Server > Connect, secure, validate, and publish a managed MCP server through MCP Foundry. 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. ```mermaid theme={null} flowchart LR A[Select server source] --> B[Configure connection] B --> C[Configure authentication and access] C --> D[Validate health and catalog] D --> E[Attach approved capabilities] E --> F[Publish through a virtual server] F --> G[Test and monitor] ``` ## Before you begin Gather the information appropriate to the server type: | Server type | Information to have ready | | --------------------------------- | ---------------------------------------------------------------------------------------------------- | | Hosted MCP server | Server URL, supported transport, and client authentication requirements. | | Self-hosted MCP server | Reachable endpoint, network and TLS requirements, and service credentials. | | Registry integration | The selected registry entry and any required provider credentials or permissions. | | Deployable or command-line server | Deployment package or command, runtime dependencies, environment configuration, and permitted roots. | 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. Image 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. ```mermaid theme={null} flowchart TD A[Connection configuration] --> B{Server transport} B -->|Network hosted| C[Configure server URL and TLS] B -->|Self-hosted| D[Configure reachable endpoint and network access] B -->|Command-line or package| E[Configure command, runtime, and wrapper] C --> F[Set authentication] D --> F E --> F F --> G[Validate server health] ``` 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. ```mermaid theme={null} flowchart LR A[Connected MCP server catalog] --> B[Review and approve] B --> C[Virtual server composition] C --> D[Authorized MCP client] D --> E[Discover and invoke approved capabilities] ``` ## 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](../troubleshooting) and [MCP Foundry concepts](../mcp-foundry-concepts).