Grok MCP: Image and Video Tools for xAI's API

Remote MCP tools in Grok are a server-side feature of the xAI API: you name an MCP server inside the tools array of a request, and xAI's own runtime opens the connection, reads the tool list and calls tools while Grok writes its answer. Nothing runs on your laptop. That is the whole difference from Cursor or Claude Code, where the MCP client sits in the editor in front of you and your machine does the talking.

Quick answer: add one object to tools — {"type": "mcp", "server_url": "https://bananabanana.pro/api/mcp", "server_label": "bananabanana", "authorization": "Bearer bb_live_…"} — and Grok gains ten generation tools: images on the Nano Banana family, video on Veo 3.1 and Gemini Omni Flash, speech on Gemini TTS. Images start at $0.03, video at $0.10, and a fresh account carries $0.20 to try it with. On grok.com the same URL goes under Connectors → New Connector → Custom, though the sign-in half of that path is less settled (there's a section on it below).

Everything about our side of the wire below was measured with live requests on September 1, 2026. Everything about xAI's side comes from their documentation as it read that same day, and I quote it rather than paraphrase, because this part of their API moves.

Two surfaces, one server

"Does Grok support MCP" is really two questions, and they have different answers.

Two constraints from the same page are worth reading twice. Transports: "Only Streaming HTTP and SSE transports are supported." And the OpenAI-compatible path drops two parameters, require_approval and connector_id, so an approval gate before a paid tool call is not something you can ask xAI for there. You build it yourself, or you pick your tools carefully.

Our endpoint is stateless Streamable HTTP, which is the transport that clears that bar. No session header to keep alive, no SSE stream to babysit, one JSON response per JSON-RPC request.

Wiring BananaBanana into the xAI API

The smallest thing that works, straight cURL against the Responses API:

curl https://api.x.ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -d '{
    "model": "grok-4.6",
    "input": [
      { "role": "user",
        "content": "Generate a 16:9 product photo of a ceramic cup on linen, soft morning light. Use nano-banana-pro, then give me the URL." }
    ],
    "tools": [
      {
        "type": "mcp",
        "server_url": "https://bananabanana.pro/api/mcp",
        "server_label": "bananabanana",
        "server_description": "Image, video and speech generation on Google models",
        "authorization": "Bearer bb_live_your_key_here",
        "allowed_tools": ["list_models", "generate_image", "get_result"]
      }
    ]
  }'

The same thing in xAI's Python SDK, where two parameter names change:

from xai_sdk import Client
from xai_sdk.chat import user
from xai_sdk.tools import mcp
 
client = Client(api_key=os.environ["XAI_API_KEY"])
 
chat = client.chat.create(
    model="grok-4.6",
    tools=[
        mcp(
            server_url="https://bananabanana.pro/api/mcp",
            server_label="bananabanana",
            authorization=os.environ["BB_KEY"],          # extra_headers=… also works
            allowed_tool_names=["list_models", "generate_image", "get_result"],
        )
    ],
)
chat.append(user("Make me a 16:9 hero image of a ceramic cup on linen."))

Get an bb_live_… key from your profile under API Keys. It is shown once.

Two details cost people an afternoon each.

The Bearer prefix. xAI describes authorization as "a token that will be set in the Authorization header on requests to the MCP server," which leaves it open whether they wrap the value in Bearer for you. Our server does not guess. Send a bare token and you get a specific complaint back:

{"error":{"code":-32001,"message":"Unsupported Authorization scheme. Use 'Authorization: Bearer <token>'."}}

So write the scheme in yourself: "authorization": "Bearer bb_live_…". If that ever double-wraps on xAI's side, use the unambiguous form instead and set the header directly with headers: {"Authorization": "Bearer bb_live_…"}.

allowed_tools is not optional in spirit. xAI's docs are blunt that without it, every tool definition the server exposes lands in the model's context: "if an MCP server exposes 10 different tools and you don't specify allowed_tools, all 10 tool definitions will be available." We expose exactly ten. Half of them spend money. I'd allow list_models, generate_image and get_result for an image bot and nothing else, then widen when you actually want video.

What Grok sees when it knocks

Here's our handshake, run for this article. Tool discovery needs no credentials at all:

curl -s -X POST https://bananabanana.pro/api/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

list_models, get_account, top_up, generate_image, edit_image,
generate_video, edit_video, generate_speech, get_result, list_generations

Anything that actually does something answers 401 until you present a token, and the response carries the pointer a well-behaved client needs:

HTTP/2 401
www-authenticate: Bearer realm="bananabanana",
  error_description="Authentication required. Connect this server with OAuth,
  or create an API key at https://bananabanana.pro/profile",
  resource_metadata="https://bananabanana.pro/.well-known/oauth-protected-resource/api/mcp",
  scope="mcp"

That resource_metadata URL returns the protected resource metadata document from the MCP authorization spec, which is how OAuth-capable clients find our authorization server on their own. For the xAI API path you'll never meet the 401, because your key rides along on every call. It matters for the connector story below.

One more compatibility note, since it bites people with hand-rolled clients: we don't demand an Accept: application/json, text/event-stream header, and we answer plain JSON. Servers that insist on the SSE-flavoured Accept header are the ones that fail mysteriously against gateways.

Quote, job, poll: the flow that surprises agents

Image generation is one call and a wait. Video is not, and this is where an agent loop written for "call tool, read answer" gets stuck.

Video and multi-image requests come back with a price quote instead of a job. The model has to call the tool a second time with confirm_cost set to that exact number, to the cent, before anything is charged. It's a deliberate speed bump: an agent should not be able to spend $4.40 on a 4K Veo clip because someone typed "make it cinematic."

Then generation is asynchronous. generate_image and generate_video return a job_id immediately; get_result long-polls for up to 30 seconds per call and you call it again until the status settles. Images typically land in 10 to 60 seconds. Video runs 1 to 10 minutes depending on model and length.

Practical consequence for the Responses API: one user turn can need four or five server-side tool calls, and if your integration caps tool steps at two, Grok will report a job_id and stop like a waiter who took the order and went home. Give it room. Pass idempotency_key on generation calls too, so a retried request doesn't produce a second charge.

Failures refund themselves. If Google's content filter rejects a prompt or an upstream call dies, the balance goes back automatically and get_result explains which stage rejected it. You are never billed for a video you didn't get.

Can grok.com do this too?

Partly, and the honest answer has a hole in it.

xAI documents the path clearly: go to grok.com/connectors, click New Connector, pick Custom, then "Enter the MCP server URL and complete any required authentication." The server has to be reachable from the public internet, which ours obviously is. Built-in connectors, the page says, each authenticate via OAuth.

What the page does not say is which authentication methods a custom connector accepts. That single sentence, "complete any required authentication," is the entire specification, and it was last updated on July 17, 2026.

Here's where we stand. We run a full OAuth 2.1 authorization server: dynamic client registration, PKCE with S256, protected resource metadata, resource indicators, the whole MCP authorization spec. Any client that follows that spec connects to us without a single line of work on our side, which is exactly how the Claude and ChatGPT connectors do it. If Grok's custom connector walks the same flow, it will just work, and you'll get a normal sign-in page with your account name on it.

If it only stores a URL and sends no credentials, you'll see all ten tools appear in the connector's tool list and every single call will come back 401. Tool discovery is anonymous on our server, so a connector can look healthy while being unable to generate anything.

I'd love to be more definite here. If you've tried it, the result is worth an email to [email protected], and the compatibility table on our MCP page gets updated the same day.

What it costs

Prices are per generation, charged from a prepaid balance, no subscription attached.

That cup is the prompt from the cURL example higher up, run for real while writing this: Nano Banana Pro at 2K, charged $0.11, finished 32 seconds after the tool call.

A new account starts with $0.20, which buys six Lite images or one short Veo Lite clip. Enough to check the wiring, not enough to judge the good models, and I'd rather say that plainly than pretend otherwise.

Top-ups add a volume bonus: 5% from $50, 10% from $100. An active promo code adds another 10% of the deposit on top, calculated from the same base, so $100 with a code credits $120. Current numbers always live on the pricing section.

Grok already makes images. Why route around it?

Fair question, and xAI's own model list answers half of it: they ship grok-imagine-image-2.0 and grok-imagine-video-1.5. For a quick picture inside a chat, use them. Nobody needs an MCP server for that.

The reasons to send generation out to us are narrower, and they're mostly about which models and how the billing reads:

• Specific Google models. Nano Banana Pro for text-in-image and product work, Veo 3.1 for video with native audio, Omni Flash when you want sound and a conversational edit pass on the same clip.
• A price before the charge. list_models returns live per-unit prices, and video quotes before it spends. An agent can be told to stay under a budget and actually honour it.
• One balance across clients. The same key works from Grok, Gemini CLI, Codex and the web studio, and every result lands in one history.
• Refunds on failure, which matters more than it sounds once a content filter is in the loop.

The honest costs of this route: an extra network hop and a polling loop, video that needs a confirm step, Omni Flash capped at 720p, and tool schemas that clients cache at connect time, so a new parameter on our side needs you to reconnect before Grok can pass it. None of that is fatal. All of it is real.

FAQ

Does Grok support MCP servers?

Yes, on the API side. xAI's Remote MCP Tools work in the native SDK, the OpenAI-compatible Responses API and the Speech to Speech API, with server_url and server_label required and authorization, headers and allowed_tools optional. On grok.com, custom MCP connectors exist under Connectors → New Connector → Custom.

Do I need OAuth, or is an API key enough?

For the xAI API, a bb_live_… key is enough and simpler: pass it as authorization with the Bearer prefix included. OAuth matters for connector-style clients that sign users in themselves. Our server supports both against the same endpoint.

Which Grok model should I use?

xAI's MCP examples use grok-4.6, currently their default recommendation. Any model that supports server-side tools will do; the tool contract doesn't change between them.

Can Grok generate video with sound through this?

Yes, through Veo 3.1 with audio or Gemini Omni Flash, which always produces sound. Expect the two-step confirm and a poll of a minute or more. Omni tops out at 720p, so it's not the choice for a full-screen hero clip.

What happens when a generation fails?

The charge reverses automatically and get_result returns the upstream reason plus a suggested next step. Content-filter rejections are worth retrying with different wording; the same prompt can pass on a second run, because the filter judges the produced pixels, not just the request.