Grok Connectors: Add a Custom MCP Connector for Live Twitter (X) Data

The SpaceXSI docs (docs.x.ai/grok/connectors) describe connectors as a way to let Grok "access your external tools and data sources directly within a conversation" and state that connectors are available to all Grok users. Some third-party setup guides say custom connectors need a paid plan; the official page does not say that, so check grok.com/connectors on your own account rather than assuming either way. On Grok Business and Enterprise a team admin must provision a connector before members can use it.

Built-in connectors. The docs list seven: Gmail and Google Calendar, Google Drive (files, Docs, Sheets, Slides), OneDrive, Outlook Mail and Calendar, Microsoft Teams, SharePoint, and Salesforce (explore objects, query records, create and update). Once connected, "Grok can use the connector's tools automatically whenever your questions relate to that service."

Catalog connectors. A larger set of pre-configured OAuth connectors for popular third-party services, browsed at grok.com/connectors. The docs do not print the list, and third-party write-ups disagree about what is in it, so we do not repeat one here.

Custom MCP connectors. If a service is not in the catalog you can "bring your own" Model Context Protocol server. MCP is the open standard (modelcontextprotocol.io) that lets an AI client discover a server's tools through tools/list and call them through tools/call. The docs list three uses: expose an internal API or database, define your own tools, and control authentication on your own infrastructure. X data is a textbook case: there is no built-in or documented catalog connector for reading Twitter (X) data with parameters you choose.

Three requirements come straight from the SpaceXSI docs, and they decide which MCP servers can work at all.

A public URL. "Your MCP server must be reachable over the public internet." The tunneling page adds that servers on localhost or a private address (127.0.0.1, 10.x.x.x, 172.16.x.x, 192.168.x.x) "are not directly reachable, and Grok will reject these URLs." Grok's servers call your server, not your browser, so anything only your laptop can see is out.

A remote transport. The tunneling guide covers servers that speak HTTP: it warns that Cloudflare quick tunnels do not support Server-Sent Events, so an SSE server should use ngrok, while "servers using the newer Streamable HTTP transport work fine." The xAI API's remote MCP tool spells it out for developers: "Only Streaming HTTP and SSE transports are supported." A stdio server, the kind you start with npx in a desktop client config, has no URL, so it needs a bridge that serves it over HTTP before a tunnel can expose it.

Authentication still applies. "If your MCP server requires OAuth or API keys, you will still complete that flow in Grok after providing the tunnel URL." The docs do not describe the fields of the custom-connector dialog beyond the URL, so whether you can paste a static bearer token there is something we could not confirm. A server that implements the MCP authorization flow (a 401 challenge pointing at OAuth metadata) is the route that matches the docs' "complete any required authentication."

Tunnels are temporary. The docs warn that most free tunnel URLs change on restart, and then "you will need to remove the old connector in Grok and add a new one with the updated URL." For a connector you rely on every day, a stable hosted URL saves that churn.

TwitterAPI.io runs a hosted MCP server at https://mcp.twitterapi.io/mcp. It speaks Streamable HTTP over HTTPS, so it meets the public-URL and transport requirements without a tunnel. The published npm package @twitterapi_io/mcp-server (version 0.2.0 on npm) is the stdio build for desktop clients such as Claude Desktop and Cursor; for Grok, use the hosted URL instead.

Step 1: get an account and an API key. Sign up at twitterapi.io; new accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days). Your API key is on the dashboard. Reads need no X account.

Step 2: open the connectors page. Go to grok.com/connectors and click New Connector, then Custom (documented). On Grok Business or Enterprise, an admin with Team Read-Write permission first adds it at console.x.ai, under Grok Business, Connectors: + Add Connector, then Other, then the URL (documented). Members then connect their own accounts on grok.com/connectors.

Step 3: enter the server URL. Paste https://mcp.twitterapi.io/mcp. Grok's servers can reach it directly; no tunnel.

Step 4: authenticate. An unauthenticated tool call to the server returns HTTP 401 with a www-authenticate: Bearer header naming the resource metadata URL and the scope twitter.read. The metadata points at the authorization server https://api.twitterapi.io, which advertises the authorization-code and refresh-token grants, PKCE with S256, a dynamic registration endpoint and client ID metadata documents. That is the standard MCP OAuth flow, so the expected experience is a sign-in page for TwitterAPI.io and a consent step. We verified the server side of this chain; we did not complete the grok.com side in a recorded session, so treat the exact screens as unverified.

Step 5: let Grok discover the tools. Per the docs, "Grok will discover the tools your MCP server exposes." Our server's tools/list returns 12 tools, every one annotated readOnlyHint: true.

Step 6: ask a question that needs X data. For example: "Using the TwitterAPI.io connector, search Latest posts mentioning Supabase from the last 6 hours, skip replies, and summarize the top complaints with links." Naming the connector and the time window keeps Grok from falling back to its built-in X search and keeps each call to one or two pages.

Most "connector won't connect" problems are on the server side, and you can test those in a minute without Grok. These are the requests we ran against the hosted server; the first two need no key and cost nothing, and the third deliberately fails.

What we saw. The initialize call returned HTTP 200 with serverInfo named twitterapi-mcp and protocol version 2025-06-18. The tools/list response listed 12 tools and weighed 11,390 bytes, about 2,848 tokens by our 4-characters-per-token estimate: that is the context Grok spends just knowing the tools exist. A tools/call without a key returned 401 with the resource_metadata pointer. The resource metadata listed https://api.twitterapi.io as authorization server, and that server's metadata listed S256 and refresh_token.

Run the same four checks against any MCP server you plan to add. If request 1 fails, Grok cannot reach the server. If request 3 returns 200 without a key, the server is open to anyone with the URL. If request 4 lacks S256, an OAuth client that requires PKCE will refuse it.

A connector tool result is text that Grok reads into its context. MCP servers commonly return the API response as a JSON string; the open-source npm build of our server, for example, returns JSON.stringify(result, null, 2), which is pretty-printed with two-space indentation. We could not inspect the hosted server's tool output without spending a key outside our study client, so we measured the REST responses those tools wrap, both compact and pretty-printed.

Post text is a small slice. The median post's text was 176 characters, and across all posts the text was 5.0% of the pretty-printed bytes. The rest is structure: the full author object on every post, entities, media variants, cards and quoted posts. Pretty-printing alone added 66.2% to a median page.

Timelines weigh more than searches. Organization timelines (360 posts) had a median of 9,393 bytes per post pretty-printed, against 3,514 for keyword-search posts (1,594), because brand accounts post more media (39.4% of timeline posts against 22.8%) and more link cards (26.4% against 11.4%).

What that means in tokens. At a rule-of-thumb 4 characters per token (an estimate, not a count from Grok's tokenizer), a median page is about 34,452 tokens, so grok-4.7's 500,000-token context holds roughly 14.5 such pages before anything else. In the Grok app that is a context limit, not a bill; on the xAI API it is input tokens you pay for (next section).

Size depends more on what a post carries than on the account: @grok had the most quoted posts in the sample (45.0%), and a quoted post embeds a second full post. A tenth handle we requested, @xai, returned an empty page.

"What did people say about our brand yesterday?" is the obvious connector question, and it is the one that runs up calls. Each search call returns 20 posts. We ran a 24-hour Latest search for eight brand names, capped at 10 pages each, and extrapolated the full day from the hours those pages covered; only the GitHub Copilot query came close to covering the whole day inside the cap.

The median brand needed 68 calls for about 1,360 posts. No chat assistant pages through 68 tool results in one turn, and none should: at roughly 34,000 tokens a page, 68 pages would be far past any context window. The data cost is small; the context is the constraint.

Ask narrower questions. Shrink the window (since_time: and until_time: operators), drop replies and reposts (-filter:replies -filter:retweets), restrict language (lang:en), or switch queryType to Top and accept a sample instead of everything. Each of those cuts calls, and none needs a new tool. For a full day of a busy brand, run the search in code and hand Grok a summary or a file instead.

Note that "Notion" and "Linear" are also ordinary English words, which inflates their counts; that is exactly the kind of query a connector user should tighten with quotes and operators.

There are two bills to think about: the data the tool fetches, and the tokens Grok spends reading it.

Data. TwitterAPI.io tweet endpoints cost 15 credits per tweet returned, which is $0.15 per 1,000 tweets ($1 = 100,000 credits). A full 20-post page is $0.003. A request that returns nothing still costs the 15-credit minimum, $0.00015. Profiles are $0.18 per 1,000; followers and followings are 1 to 3 credits per user returned. Purchased credits never expire, and plans run from Starter at $29 a month to Business at $1,499 (see the pricing page).

Tokens, in the Grok app. The connector docs list no separate charge for connector calls; chat usage on grok.com is governed by your Grok plan, and the plans page lists Free, Plus, Premium, Super and Ultra tiers with different usage multipliers. How heavily a large tool result counts against that usage is not documented, but it certainly occupies the context window, which is why the page-count advice above matters.

Tokens, on the xAI API. If you call Grok from code with the remote MCP tool, SpaceXSI's pricing page says "you will not be charged for the tool invocation but will be charged for any tokens used." At grok-4.7's $2.00 per million input tokens, our median page of about 34,452 tokens (estimate) is about $0.069 in input tokens, against $0.003 for the data in it. On the API, the tokens cost more than the posts.

The native alternative. The X Search tool on the xAI API is billed per item fetched: $5 per 1,000 posts and $10 per 1,000 profiles, plus tokens. That is $0.10 for 20 posts before any tokens.

Per 1,000 posts, $5 against $0.15 is about 33x. The X API's pay-per-use rate card also charges $0.010 per user read and is capped at 3 million post reads a month, with Enterprise above that.

Developers can attach the same server to Grok through the xAI API, without the chat app. The remote MCP tool takes server_url, server_label, an optional allowed_tools list and an optional authorization value that "will be set in the Authorization header on requests to the MCP server." Our server accepts a TwitterAPI.io API key as that bearer token (its initialize instructions say so), so no OAuth step is needed in code.

Limit the tools. Without allowed_tools, every tool definition the server exposes is injected into the model's context. Our 12 definitions are about 11 KB; allowing only search_tweets and get_user_last_tweets trims that and keeps Grok from wandering into follower lists.

What the docs say is unsupported. The OpenAI-compatible require_approval and connector_id parameters are not supported. For a full agent built this way, with reasoning about when to call which tool, see our Grok agent guide; this section only shows the connection. We did not run this request for the page (it needs an xAI key); the shape follows the SpaceXSI example.

Question. When Grok calls a Twitter (X) data tool through a custom MCP connector, how large is what comes back, how many calls does a typical question take, and what do the data and the tokens cost?

Accounts and queries. Timelines of ten organization accounts (@grok, @xai, @OpenAI, @AnthropicAI, @vercel, @github, @NASA, @SpaceX, @nvidia, @Microsoft), two pages each through /twitter/user/last_tweets; and a 24-hour Latest search through /twitter/tweet/advanced_search for eight brand keywords (Notion, Vercel, Supabase, Cloudflare, Salesforce, Canva, "GitHub Copilot", Linear), up to 10 pages each. Plus one unauthenticated tools/list request to the hosted MCP server.

Window and sample. The accounts' most recent posts and the 24 hours before collection, collected in 2026: 1,954 posts from 99 API requests, about $0.29 in credits.

Method. Bytes are UTF-8 JSON as the REST API returned it, measured compact and pretty-printed with two-space indentation. Tokens are estimated at 4 characters per token; Grok's tokenizer may count differently. Daily volumes beyond the 10-page cap are extrapolated from the hours the first 200 posts covered, so busy keywords carry more uncertainty than quiet ones.

What the sample cannot show. It does not measure the hosted server's exact tool text (it may trim or reformat fields), Grok's actual token count or its choice of how many pages to request, or a full day for any keyword other than by extrapolation. One day of searches is one day; brand volume swings with news.

Privacy. Aggregates only. Organization timelines are kept as raw pages; keyword-search authors are private individuals, so their posts were reduced to de-identified size rows (no IDs, URLs, text or handles) and the raw pages were not kept.