External Tools and Supported SDKs

Three entry points to the same mechanism

xAI exposes remote MCP through three interfaces. They target different developers: one for new projects, another for migrated projects, and the third for specific usage contexts. MCP behavior is exactly the same in all three cases; only the configuration syntax and peripheral tooling change. Your choice therefore depends on your existing stack, not on the protocol’s capabilities.

The native xAI SDK

This is the method xAI recommends. It provides an mcp() helper that condenses configuration into a single function call.

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://mcp.deepwiki.com/mcp")
    ],
    include=["verbose_streaming"],
)

The mcp() helper accepts all MCP configuration parameters—URL, label, description, allowed tools, authentication—and handles formatting them correctly for the API. This is the most concise syntax, and crucially, the one where you’re least likely to make a mistake, since key names and nesting are handled for you. Choose this path for a new project without compatibility constraints, for any rapid prototyping, and whenever you leverage xAI-specific features like the verbose streaming visible above.

The Responses API, OpenAI-compatible

This interface accepts exactly the OpenAI API format. It exists for a specific reason: so a team that has already written their application in this format doesn’t have to rewrite everything to try Grok. The change is limited to the API key and the base URL.

from openai import OpenAI

client = OpenAI(
    api_key=os.getenv("XAI_API_KEY"),
    base_url="https://api.x.ai/v1",
)

response = client.responses.create(
    model="grok-4.20-0309-reasoning",
    input=[{"role": "user", "content": "Explain the React project"}],
    tools=[{
        "type": "mcp",
        "server_url": "https://mcp.deepwiki.com/mcp",
        "server_label": "deepwiki",
    }],
)

Here, the MCP server is declared as an element of the tools array, with the type "mcp" and parameters as key-value pairs in the same object. No helper: you write the dictionary by hand, which leaves more room for a typo in a key name.

This compatibility comes at a cost, and you should know it before building on top of it. Two parameters available in the native SDK aren’t available here: require_approval, which lets you require human validation before executing an MCP tool, and connector_id, which manages OpenAI connectors. If your agent handles sensitive operations and you were counting on manual validation, this limitation is a blocker and should steer you back to the native xAI SDK. The Responses API remains the right choice for a migration from OpenAI without rewriting, for a multi-provider project where you alternate between Grok and other models, and for a team already familiar with this format.

The Voice Agent API

The third interface is designed for voice agents. The typical scenario is a phone assistant that, in the middle of a conversation, needs to consult a knowledge base, check an order status, or query an external system—without the caller experiencing unexplained silence.

MCP configuration follows the same format as in the other SDKs, with the same server_url, server_label parameters and others. The difference lies in what happens after the tool call: the result is integrated into the voice synthesis flow rather than rendered as text. This shapes how you write your tool descriptions and frame their responses, since the user will never see a table or a list—they will only hear them.

What doesn’t change across interfaces

Whatever the SDK, the sequence is the same. Grok discovers the tools exposed by the MCP server, selects the one that matches the request, formulates the call with the correct parameters, then integrates the result into its response. None of the three interfaces makes the model more or less skilled at choosing a tool.

So the differences lie elsewhere: syntax concision, available peripheral features—verbose streaming on the xAI SDK, format compatibility on the Responses API, voice synthesis on the Voice Agent—and the two parameters missing from the OpenAI format. Decide based on these criteria, and you won’t go wrong.

Key takeaways

• The native xAI SDK with mcp() is the simplest and most complete method
• The Responses API (OpenAI format) eases migration but does not support require_approval or connector_id
• The Voice Agent API connects voice agents to MCP tools
• MCP behavior is identical in all three cases; only the syntax changes
• Choose based on your existing stack and specific needs