Grok can work with your Meta Ads data and campaigns through AdStellar, but not through a button in the Grok chat interface. The connection is made through the xAI API, where you declare a remote MCP server in your request. This guide walks through that setup end to end, so your Grok Meta Ads MCP connection can list AdStellar's tools and answer questions about your accounts. Before you start, you need an AdStellar account with Meta connected, an xAI API key, and a way to send requests to the xAI API, such as a script or an API client.
Step 1: Confirm your prerequisites
Three things need to be in place before you write any request.
- An AdStellar account with your Meta ad account connected. The MCP tools are only as useful as the data behind them. If Meta is not connected yet, do that inside AdStellar first, so Grok has real campaign history, creative performance, and account context to work with.
- An xAI API account and API key. Create the key in the xAI console. In API requests it works as a bearer credential, which means anyone holding it can make calls billed to your account. Store it in an environment variable and keep it out of shared code, notebooks, and screenshots.
- A way to send API requests. A short script, curl, or an API client such as Postman is enough.
It also helps to be clear about the shape of this integration. You are not enabling a connector from a menu in a Grok chat window. This is an API-based pattern: you add a remote MCP server to the tools list of a request, and the model can then call that server's tools while generating its answer. This guide does not describe any chat UI toggle for MCP, because none is documented for this workflow. If you see a tutorial that promises one, treat it with suspicion.
Finally, note the only server address used throughout this guide:
https://app.adstellar.ai/api/mcp
Copy it exactly. Do not add a trailing slash, extra path segment, or query string, and do not substitute an http address.
Step 2: Understand how xAI remote MCP tools work
MCP, the Model Context Protocol, is an open standard that lets a model discover and call tools hosted on an external server. Instead of every integration needing custom glue code, the server describes what it can do (its tools and their inputs), and any MCP-aware client can use them.
The xAI API supports this through remote MCP tools. In your request, you add an entry to the tools list that declares an MCP server by URL. When the model decides it needs a tool, xAI's infrastructure connects to that server on the model's behalf, retrieves the tool list, makes the call, and feeds the result back into the response. Your own script never talks to AdStellar directly in this flow; it only talks to xAI.
That has a practical consequence. Because xAI's side makes the connection, the MCP server must be reachable over the public internet via HTTPS. A server running on localhost or behind a VPN will not work. AdStellar's endpoint at https://app.adstellar.ai/api/mcp is a public HTTPS address, so this requirement is met.
Check the current xAI docs first
Request formats for tool use change. As of November 2026, remote MCP tools are documented for use with xAI's Responses API and a defined set of Grok models, but you should confirm three things against the current xAI documentation before you build on this guide:
- The exact request format for declaring an MCP tool.
- Which endpoint supports remote MCP (the Responses API, at the time of writing).
- Which Grok models support server-side tool calling on your account.
If the docs and this guide ever disagree, the docs win.
Step 3: Set up your xAI API key and environment
Export your key as an environment variable so it never appears in your code. In a Unix shell:
export XAI_API_KEY="your-key-here"
On Windows, set the same variable through your system environment settings or your shell's equivalent. Your scripts then read XAI_API_KEY at runtime. If you use a .env file, add it to your .gitignore before your first commit.
Next, choose one client and stick with it. The common options are:
- The xAI SDK, if you want the officially maintained route.
- An OpenAI-compatible SDK pointed at the xAI base URL, which is convenient if your team already uses one.
- Plain HTTP with curl, which is the clearest way to see exactly what is sent and returned.
Mixing clients while debugging makes it hard to tell whether a problem is in your request or in the library's handling of it. For a first setup, curl is a good default because nothing is hidden.
Run a sanity check with no tools
Before adding MCP, send a plain request with no tools at all, asking something trivial such as "Reply with the word ready." If this works, you have confirmed that your key is valid, your client is configured correctly, and the model name is accepted. Any error you hit later can then be isolated to the MCP step.
The most common mistake here is using a model name that your account cannot access. Check the models list in the xAI console or API documentation, copy the identifier exactly, and use a model that supports the tool features you need.
Step 4: Add the AdStellar MCP server to your Grok request
The connection itself is one entry in the tools array. That entry needs three things: a type of mcp, the server URL, and a label that names the server. Use adstellar as the label so tool calls in the response are easy to recognize.
Here is a minimal example in the shape xAI documents for the Responses API as of November 2026. Check it against the current docs before you run it, and do not add fields that the docs do not list.
curl https://api.x.ai/v1/responses \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $XAI_API_KEY" \
-d '{
"model": "YOUR_GROK_MODEL",
"input": "What AdStellar tools do you have access to?",
"tools": [
{
"type": "mcp",
"server_url": "https://app.adstellar.ai/api/mcp",
"server_label": "adstellar"
}
]
}'
Replace YOUR_GROK_MODEL with the model identifier you verified in Step 3. If you use an SDK instead of curl, the same three values go into the equivalent tool definition; the SDK's own documentation shows where.
Authentication: verify, do not assume
xAI's MCP tool definition may include a parameter for passing authorization to the server. Whether you need it, and what value it should carry, depends on how AdStellar authenticates MCP clients. Confirm that in AdStellar's MCP documentation or inside your AdStellar account, and cross-check the parameter name in the xAI docs. This guide does not assert a specific authentication scheme, so do not guess one. If the server requires credentials and your request supplies none, expect an authentication error in the response rather than a tool list.
Mistakes to avoid
- Using any URL other than https://app.adstellar.ai/api/mcp.
- Adding a trailing slash or path variation.
- Using an http address instead of https.
- Putting your key directly in the command instead of reading it from the environment variable.
Step 5: Let Grok discover the AdStellar tools
MCP servers advertise their own tools. On the first call that includes the server, xAI retrieves the list of tools AdStellar exposes and makes them available to the model. You do not register tools one by one.
The request from Step 4 already asks the right question: "What AdStellar tools do you have access to?" Grok should answer with the tools it found on the server, and depending on the response format you may also see the tool listing as its own item in the output. Read that list from the live response. Do not rely on a list in a blog post, including this one, because tool names and capabilities can change as AdStellar's MCP server evolves. This guide deliberately does not name them.
Once you have the list, map it to what you want to do. You should see tools that line up with AdStellar's capabilities, such as analytics and campaign work, and you can plan your prompts around what is actually exposed.
Restricting which tools Grok can use
If the xAI API supports an allowed-tools option on MCP tool definitions, you can limit Grok to a subset of the server's tools. This is useful for a read-only setup. Verify the parameter name and format in the current xAI docs before using it, and add it only if it is documented.
If no tools appear
Work through the checks in order:
- Confirm the URL is exactly https://app.adstellar.ai/api/mcp.
- Confirm the plain no-tools request from Step 3 still succeeds, which rules out the key and model.
- Confirm the model supports remote MCP tools and that you are calling the endpoint the docs specify for them.
- Compare your request body to the current documented shape, field by field.
- Read the full error message. Authentication problems and request-format problems read very differently.
Step 6: Run your first Meta Ads prompts
Start with read-only requests. They carry no risk to live spend and they show quickly whether the data coming back is trustworthy. Good first prompts map to AdStellar's analytics and AI Insights:
- "Using AdStellar, summarize campaign performance for the last 14 days in my [ad account name], ranked by ROAS."
- "Which creatives in [ad account name] show signs of fatigue over the last 30 days, and what changed in their performance?"
- "Which ad elements are driving the best CPA this month?"
Specificity matters. Name the date range, the goal metric (ROAS, CPA, or whatever you optimize for), and the ad account. A vague prompt like "how are my ads doing?" forces the model to guess scope, and you will get an answer that is hard to verify.
Then try a build request
Once reads look right, ask for a draft. For example: "Draft a campaign for [product] aimed at a ROAS target of [your target], based on my past performance in AdStellar. Explain your reasoning, and do not launch anything." AdStellar's builder is designed to work from your historical data and show the reasoning behind a campaign, so read that explanation carefully. Check that the audiences, creatives, and budget logic make sense for your account before anything goes near a live launch.
Check the numbers
Never accept a figure at face value just because the model stated it fluently. Compare the spend, ROAS, and CPA Grok quotes against what you see in AdStellar and in Meta Ads Manager for the same date range. Small differences can come from attribution windows or reporting delays, but large gaps mean you should stop and find out why before acting on the output.
Step 7: Add guardrails and troubleshoot
An agent that can read data is low risk. An agent that can launch campaigns or change budgets can spend real money, so put controls around any action that touches live spend.
Guardrails
- Require explicit confirmation. State in your prompt, or build into your workflow, that Grok must present a plan and wait for your approval before launching or changing anything live.
- Test in a separate workspace. AdStellar supports unlimited workspaces, so use a test or low-budget one while you learn how Grok behaves with the tools.
- Limit the toolset. If the xAI API offers an allowed-tools option (see Step 5), start with read-only tools and widen access deliberately.
- Protect your key. Rotate your xAI API key on a schedule and immediately if it is ever exposed. Keep it out of logs, error trackers, and shared terminals, and be careful that verbose request logging does not print your Authorization header.
Troubleshooting checklist
- Authentication errors: confirm your xAI key is valid and set in the current shell, then check AdStellar's MCP documentation for how the server expects clients to authenticate.
- Tool call timeouts: retry with a narrower prompt, such as a shorter date range or a single campaign, since large pulls take longer.
- Wrong model: use a model your account can access and that supports remote MCP tools.
- Outdated request format: compare your request to the current xAI documentation, since field names and supported endpoints can change.
- Wrong URL: the only address in this setup is https://app.adstellar.ai/api/mcp.
When something breaks, go back to the no-tools request from Step 3 first. It splits the problem cleanly between your xAI setup and the MCP connection.
Your connection is live: verify it, then supervise your first build
Confirm the setup with two checks. First, have Grok list the AdStellar tools it can access and confirm the list comes from the live response. Second, run one read-only performance query for a known date range and match the numbers against AdStellar and Meta Ads Manager. If both pass, the integration is working.
From there, move to supervised campaign creation: ask Grok to draft a campaign in a test workspace, review the reasoning AdStellar provides, and approve each launch yourself until you trust the workflow. Widen Grok's permissions only as your confidence grows.
