How to Use Google Gemini with the Twitter (X) API

Neither the Gemini models, Gemini CLI nor the Gemini API ship a Twitter/X connector. Gemini can only use data that is in its context window, so to answer "what are people saying about this launch?" it needs something that fetches the posts and hands them over as text. Two mechanisms do that, and Gemini supports both: the Model Context Protocol (MCP), which Gemini CLI loads from settings.json, and function calling, which the Gemini API exposes to your own code.

Path A: Gemini CLI + MCP. The Gemini CLI docs list three MCP transports: stdio, SSE and Streamable HTTP (geminicli.com/docs/tools/mcp-server). TwitterAPI.io hosts a Streamable HTTP server at https://mcp.twitterapi.io/mcp and publishes an npm package for stdio, so you can pick either. Once configured, Gemini CLI sees 12 tools (search_tweets, get_user_info, get_user_about, get_user_followers, get_user_followings, get_user_last_tweets, get_user_mentions, get_tweets_by_ids, get_tweet_replies, get_tweet_quotes, get_tweet_retweeters and a trends tool) and calls them from plain-language prompts. No code.

Path B: Gemini API + function calling. In your own Python, Node or Go app you declare a function, Gemini returns a structured request to call it, your code runs it against https://api.twitterapi.io, and Gemini writes the answer from the result. The google-genai Python SDK goes one step further with automatic function calling: pass the function object itself and the SDK handles the call-and-return loop (googleapis.github.io/python-genai). This is the path for apps, scheduled jobs and anything that is not a human typing in a terminal.

The official X API is the third option and the one the no-code connectors quietly rely on. It works, but it means an X developer account, an OAuth 2.0 app, a saved payment card and $0.005 per post read (docs.x.com/x-api/getting-started/pricing). We keep it in the comparison table below as the reference point; everything else on this page runs on a TwitterAPI.io key that you get by signing in with Google at twitterapi.io and copying it from the dashboard.

Install Gemini CLI if you have not (npm install -g @google/gemini-cli, or brew install gemini-cli; the README also allows a one-off npx @google/gemini-cli). Sign in with a Google account or set GEMINI_API_KEY. Then open the user-level settings file, ~/.gemini/settings.json, or the project-level .gemini/settings.json if you only want the tools in one repo, and add an mcpServers object. The property names below are the ones the Gemini CLI docs define: httpUrl selects the Streamable HTTP transport, headers carries custom HTTP headers, command / args / env define a stdio server, and timeout is the request timeout in milliseconds (default 600,000).

The block below shows both variants in one file so you can see them side by side; keep whichever you prefer and delete the other. twitterapi is the hosted server: nothing to install, authenticated by the X-API-Key header. twitterapi-local runs the open-source package through npx on your machine and reads the key from the TWITTERAPI_IO_API_KEY environment variable; the docs' own stdio example uses the same $VAR form inside env, which keeps the secret out of the JSON file.

If you prefer the command line to editing JSON, the docs document gemini mcp add --transport http --header "X-API-Key: YOUR_KEY" twitterapi https://mcp.twitterapi.io/mcp, which writes the same entry for you, and gemini mcp list to confirm it. Inside a session, /mcp lists every connected server and its tools; if twitterapi is there with 12 tools, you are done.

Two optional keys are worth knowing. trust: true skips the confirmation prompt Gemini CLI shows before each tool call, which you will want once you have seen the tools work; and includeTools / excludeTools let you expose a subset, for example only search_tweets and get_user_last_tweets on a shared machine.

Gemini CLI reads each tool's description and parameters from the MCP server, so you do not name the tool; you describe the outcome and mention the fields you care about. The three prompts below cover the three jobs people actually wire Gemini to X for, and each maps to one or two tool calls. Naming queryType, likeCount or next_cursor in the prompt is optional, but it nudges Gemini to pass the right argument and to paginate instead of stopping after one page.

Prompt 1, sentiment on a product launch, triggers search_tweets with queryType=Latest. Two pages is 40 tweets, which is enough for a quick read and costs about $0.006 of credits. Ask for the @handle on each quote so you can verify the examples yourself.

Prompt 2, one account's last week, triggers get_user_last_tweets, which wraps /twitter/user/last_tweets. The endpoint sorts by createdAt newest first, so asking Gemini to keep only the last 7 days is a filter on the returned list, not a parameter; if the account posts a lot, tell Gemini to follow the cursor for a second page.

Prompt 3, most-retweeted posts on a topic, is search_tweets with queryType=Top followed by Gemini sorting on retweetCount. Top ranks by relevance and engagement across time, while Latest is strictly newest first; for "which posts travelled furthest" you want Top. Three pages is 60 tweets, about $0.009.

When a prompt does not trigger a tool call at all, say "search X" or "use the twitterapi tools" explicitly, or check /mcp to confirm the server connected. When it triggers one call where you expected several, ask for the pagination in words ("follow next_cursor until you have three pages").

The current SDK is the google-genai package (pip install google-genai, then from google import genai and from google.genai import types). Its reference documents automatic function calling: "You can pass a Python function directly and it will be automatically called and responded by default." The SDK derives the function's JSON schema from the type hints and the docstring, so the quality of the Args: block in your docstring is what decides whether Gemini fills query and query_type sensibly. The model id used throughout the SDK examples is gemini-flash-latest; the complete script at the end of this page uses the same.

Google's function-calling guide (ai.google.dev/gemini-api/docs/function-calling) now documents the newer Interactions API as well: client.interactions.create(model="gemini-3.8-flash", input=..., tools=[...]), where you inspect function_call steps and send back a function_result yourself. It is the same idea with more control and more code. For a search-and-summarise job, the generate_content path with automatic calling is shorter and is what we show.

The function itself is ordinary requests code: GET https://api.twitterapi.io/twitter/tweet/advanced_search with the X-API-Key header and query plus queryType parameters, follow next_cursor while has_next_page is true, and return a compact list so Gemini's context is not filled with fields it does not need. The manual variant below disables automatic calling, which is the right mode when you want to log or rate-limit what Gemini asks for before any credits are spent: read response.function_calls[0], run it, and send the result back with types.Part.from_function_response, as the SDK reference shows.

Two practical notes. Keep max_pages small and let the prompt widen it; each page is up to 20 tweets and 15 credits per tweet, so a runaway loop is the only way this gets expensive. And trim the tweet objects before returning them: the raw response carries around thirty fields per tweet (entities, cards, quoted tweets), and the six you keep (id, text, likeCount, retweetCount, createdAt, author.userName) are what a summary needs.

Whether Gemini reaches the endpoint through the MCP tool or your function, the JSON is the same. /twitter/tweet/advanced_search returns a top-level tweets array plus has_next_page and next_cursor for pagination; each tweet carries camelCase counters (likeCount, retweetCount, replyCount, viewCount), an X-style createdAt string and an author object with userName. There is no nested metrics wrapper and no versioned path prefix; those belong to the official X API, and seeing them in a snippet is a sign it was written from memory. A failed call shows up as a non-200 HTTP status, so raise_for_status() is the error check; the search response itself has no error field.

The shape below is trimmed to the fields the examples use. get_user_last_tweets is the one wrinkle: it nests the list as data.tweets instead of top-level tweets, with has_next_page and next_cursor still at the top. If you write your own function for timelines, read page["data"]["tweets"].

Each page holds up to 20 tweets and is billed at 15 credits per tweet returned, so a full page is 300 credits, which is $0.003. A search that matches nothing still costs the 15-credit minimum ($0.00015). There is no per-request cap: a 20-tweet page is $0.003, 1,000 tweets are $0.15.

The three ways to get X data in front of Gemini differ less in what they return than in what they ask of you first. The table puts the dimensions side by side; prices are the published per-unit rates, and rate limits are quoted from each provider's docs.

On price the gap is the same 33x in both TwitterAPI.io columns: $5.00 divided by $0.15. On setup the gap is the OAuth app and the developer account, which the two Gemini paths simply do not have. The official API's advantage is being official: if your product needs that status, it is the only choice, and its documentation (docs.x.com) is the reference for the operator syntax that search_tweets queries also accept.

There are two meters. The X data meter is TwitterAPI.io's: 15 credits per tweet returned on search, mentions, replies, quotes, timelines and tweets-by-ID, with $1 buying 100,000 credits. That is $0.15 per 1,000 tweets, $0.003 for a full 20-tweet page, and a 15-credit minimum ($0.00015) for a request that returns nothing. Profiles are 18 credits each ($0.18 per 1,000). The official X API charges $0.005 per post read, so the same 1,000 tweets are $5.00: $5.00 / $0.15 is about 33x, and the chart below is just those two numbers.

The Gemini meter is Google's token pricing, which is separate and unchanged by where the tweets come from. Google's pricing page lists Gemini 2.5 Flash at $0.30 per 1M input tokens and $2.50 per 1M output tokens, and Gemini 3.8 Flash at $0.75 input / $3.75 output per 1M for 2026 (ai.google.dev/gemini-api/docs/pricing); a free tier with limited model access also exists. Derived from those list prices: 10,000 input tokens on Gemini 2.5 Flash cost $0.003, the same as one 20-tweet page of X data, and $0.0075 on Gemini 3.8 Flash. Trimming tweets to six fields before they reach the model is what keeps this side small.

Worked example, prompt 1 above: two pages of 20 tweets is 600 credits, $0.006 of X data. Run it hourly for a month (720 runs) and the X side is $4.32. A monitoring loop that checks every 5 minutes and usually finds nothing pays the 15-credit floor each time: $1.30 a month; every 60 seconds is 43,200 checks, $6.48. New accounts that pass the automatic bot check start with $1 in free credits (no card; one per person and network; the free credits expire after 31 days), which covers everything on this page several times over. Subscriptions from Starter at $29 a month add bonus credits and the paid rate limit of 20 requests/s; the full ladder is on the pricing page.

Writes, if you need them, run through an authenticated session rather than a read key: one /twitter/user_login_v2 login ($0.10, with a proxy you supply) returns login_cookies, and each /twitter/create_tweet_v2, like, retweet, follow or unfollow is then $0.002, billed per HTTP 200 call. The call acts as that X account, so X can rate-limit, lock or suspend it; keep a human pace, and expect to re-login when the session expires. Reads need none of this.

The server is missing from /mcp. The usual causes are a JSON syntax error in settings.json (a trailing comma is enough), the key written as url instead of httpUrl (in Gemini CLI url means an SSE endpoint, and the hosted server speaks Streamable HTTP), or the file saved in a different location than the one Gemini CLI is reading (user ~/.gemini/settings.json versus project .gemini/settings.json). Restart the session after editing.

Tool calls fail with 401 / unauthorized. The X-API-Key header is missing or wrong in the headers object, or, for the stdio package, TWITTERAPI_IO_API_KEY is not set in the shell that launched Gemini CLI. Copy the key again from the dashboard; keys can be rotated there at any time.

Gemini CLI asks for confirmation on every call. That is the default safety prompt for MCP tools. Set trust: true on the server entry once you are comfortable, or accept per session.

response.text is empty in Python. With automatic function calling disabled, the first response is the function call, not prose: read response.function_calls and continue the loop as in the manual example. With automatic calling on, an empty text usually means the function raised; print the HTTP status and body from requests: a search that failed returns a non-200 status rather than an error field.

429 or slow responses on a new account. Before the first payment the rate limit is 0.2 requests/s (one call every five seconds), which is fine for interactive prompts but will trip a loop that paginates aggressively. Once paid it is 20 requests/s. Lower max_pages, or add a short sleep between pages.

Timeouts on big searches. Tighten the query (lang:en, since:/until: bounds, min_faves:), ask for fewer pages, or raise timeout on the server entry (milliseconds; the docs' default is 600,000). Queries use X's advanced-search operator syntax, so anything that works in the X search box works here.