Skip to main content
Lesson 7 of 12 · Remote MCP: Connect External Tools

Complete MCP Server Configuration

Lesson 7 of 12 Updated July 29, 2026 Developer
On this page
  1. Putting It All Together
  2. The Simplest Case
  3. A Read-Only Internal Server
  4. A Comprehensive Configuration
  5. Check Before Deploying
  6. Key Takeaways

Putting It All Together

You’ve encountered each parameter in isolation. This lesson brings them together into complete configurations, exactly as you’ll write them in practice, showing the equivalent in both main SDKs each time. The goal isn’t to introduce new concepts but to give you patterns you can adapt directly.

Here is an overview of the six parameters, with their required or optional status.

ParameterRequiredRole
server_urlYesHTTPS URL of the MCP server
server_labelYesTool call prefix
server_descriptionNoGuides Grok in server selection
allowed_tool_namesNoRestricts accessible tools
authorizationNoAuthentication token
headersNoAdditional HTTP headers

The Simplest Case

Two parameters suffice when the server is public and requires no authentication.

# xAI SDK
tools = [mcp(server_url="https://mcp.deepwiki.com/mcp", server_label="deepwiki")]

# Responses API (OpenAI)
tools = [{
    "type": "mcp",
    "server_url": "https://mcp.deepwiki.com/mcp",
    "server_label": "deepwiki"
}]

This is exactly what you’ll write for DeepWiki. Grok then has access to all the server’s tools, which remains acceptable here since it’s a public read-only service. As soon as the server belongs to your organization, this configuration becomes insufficient.

A Read-Only Internal Server

Let’s take a step up: an enterprise CRM that the agent must be able to query but never modify. Three parameters are added, each for a distinct reason—the description guides the model, the token proves identity, and the allowlist prohibits writes.

# xAI SDK
tools = [
    mcp(
        server_url="https://api.monentreprise.com/mcp",
        server_label="crm",
        server_description="Internal CRM. Contact and company lookup only.",
        authorization=f"Bearer {os.getenv('CRM_TOKEN')}",
        allowed_tool_names=["search_contacts", "get_contact", "list_companies"]
    )
]

# Responses API (OpenAI)
tools = [{
    "type": "mcp",
    "server_url": "https://api.monentreprise.com/mcp",
    "server_label": "crm",
    "server_description": "Internal CRM. Contact and company lookup only.",
    "authorization": f"Bearer {os.getenv('CRM_TOKEN')}",
    "allowed_tool_names": ["search_contacts", "get_contact", "list_companies"]
}]

Compare the two blocks: the content is identical; only the wrapper changes. The mcp() helper takes named arguments; the OpenAI format expects a dictionary with an additional "type" key. This is the only difference to remember when translating a configuration from one SDK to the other.

A Comprehensive Configuration

Final step, with all six parameters combined in a real-world call to the xAI SDK.

import os
from xai_sdk import Client
from xai_sdk.tools import mcp

client = Client(api_key=os.getenv("XAI_API_KEY"))

chat = client.chat.create(
    model="grok-4.20-0309-reasoning",
    tools=[
        mcp(
            server_url="https://tools.monentreprise.com/v1/mcp",
            server_label="outils-internes",
            server_description="Internal tools platform: document management, support tickets, knowledge base. Read-only access.",
            authorization=f"Bearer {os.getenv('TOOLS_MCP_TOKEN')}",
            headers={
                "X-Organization-Id": os.getenv("ORG_ID"),
                "X-Environment": "production",
                "X-Request-Source": "grok-agent"
            },
            allowed_tool_names=[
                "search_documents",
                "get_document",
                "search_tickets",
                "get_ticket",
                "search_knowledge_base"
            ]
        )
    ],
    include=["verbose_streaming"],
)

Notice the internal consistency of this example. The description announces read-only access, and the five allowed tools are all query operations—no contradiction between what the model believes it can do and what the configuration allows. The X-Environment header set to production prevents a test agent from writing to live data, and X-Request-Source will make your server traces actionable should you need to track down where an unexpected request originated.

Check Before Deploying

Six points warrant a review before any production deployment, and each corresponds to a pitfall encountered earlier in this course. The URL must be HTTPS with a valid certificate, otherwise nothing will go through. The label must stay short, descriptive, and unique within the configuration. The description must match the tools actually exposed, otherwise the model will attempt calls destined to fail. Allowed tools must be reduced to the strict minimum. The token must come from an environment variable, not source code. And additional headers must be exactly what your server expects, with correct casing—a casing error on X-Organization-Id produces a silent failure that is particularly painful to diagnose.

Key Takeaways

  • Minimal configuration requires only server_url and server_label
  • Add server_description to guide Grok, especially in multi-server setups
  • Restrict with allowed_tool_names for security and performance
  • Use authorization and headers for authentication
  • Both SDKs (native xAI and OpenAI Responses) accept the same parameters with different syntax