Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@x-feed-mcp get recent tweets from @OpenAI and @AnthropicAI"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A least-privilege, read-only Model Context Protocol server that returns recent tweets from a set of tracked X (Twitter) accounts.
It exposes one tool, get_recent_tweets, and nothing else:
It can read the most recent tweets from a set of handles, using a logged-in session.
It cannot post, reply, like, follow, DM, read your home timeline, or write anything. Only reading tracked handles is implemented.
The tracked handles are passed dynamically by the caller on each call, so the set can grow over time without redeploying. It authenticates with a cookie-derived API key (via rettiwt-api), no paid X API tier, and, importantly, no automated password login: you log in by hand once and encode the resulting cookies.
Against X's Terms of Service. Programmatic access via session cookies breaks X's ToS. Use a dedicated throwaway account, never your personal one; expect it to be flagged/banned eventually.
Cookies expire. The session dies periodically (days to weeks, sooner if flagged). When it does, the tool returns a clear "session expired" error and you must log in again, regenerate X_API_KEY, and update it. Low-maintenance, not zero-maintenance.
Brittle upstream. It depends on X's internal endpoints via rettiwt-api; X changes break it until the library updates.
If you need durability, prefer official RSS/news feeds. This server is the pragmatic option when you specifically want to read a curated set of X accounts and accept the upkeep.
Related MCP server: X API FastMCP Server
Node.js 20+.
A dedicated X account, logged in.
Variable | Required | Description |
| Yes | base64 of your account cookies ( |
| No | Optional static fallback set of handles (comma/space separated, |
For remote (HTTP) deployment, also: MCP_TRANSPORT=http, MCP_AUTH_TOKEN (bearer secret), optional PORT, and optional keepalive (KEEPALIVE_URL / RENDER_EXTERNAL_URL, KEEPALIVE_MINUTES).
X_API_KEYLog into your dedicated account, open the browser console, and run:
btoa("auth_token=YOUR_AUTH_TOKEN;ct0=YOUR_CT0;twid=YOUR_TWID;")Get each value from DevTools → Application → Cookies → https://x.com (auth_token ~40 chars, ct0 long, twid looks like u%3D<userid>). The console prints a long base64 string, that is your X_API_KEY (a few hundred characters). It grants full access to that account, so keep it to the throwaway and never commit it.
get_recent_tweetsField | Type | Required | Description |
| string[] | Optional if | Handles to fetch (with or without |
| number | No | How many merged tweets to return, newest first (1-100). Default 30. |
| boolean | No | Include |
Handles are fetched in small batches (X caps from: operators per search query), merged, de-duplicated, and sorted newest-first. Output is a compact text list of author, timestamp, text, and URL.
Run as an always-on service and add it to Claude as a custom connector. The /mcp endpoint requires a bearer token (MCP_AUTH_TOKEN), reachable as an Authorization: Bearer header or as /mcp/<token> in the path for connector UIs that only take a URL. GET /health is unauthenticated (health check + keepalive). A render.yaml blueprint is included; set secrets in the host dashboard, never in the file.
npm install
npm run build
npm test # unit + HTTP tests (no network)
npm run test:feed # live: default handles
npm run test:feed -- 20 @sama @OpenAI # live: count + explicit handles
npm run test:users -- @sama @AnthropicAI # live: probe specific handlesThe live scripts hit real X endpoints and need a valid X_API_KEY.
See SECURITY.md. The cookie key is read only from the environment, never logged, and grants full access to the connected account, keep it on a dedicated throwaway. Revoking it (log the account out of all sessions) immediately disables this integration.
Return the most recent tweets from a set of X (Twitter) handles, newest first, using a logged-in session. Read-only: this server can only read, it cannot post, reply, like, follow, DM, or write anything. Defaults to the server's configured handle set; useful for summarising what a curated group of accounts has posted.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many recent tweets to return after merging (1-100). Default 30. | |
| handles | No | X handles to fetch (with or without @). Optional if the server has a default set (X_HANDLES) configured. | |
| includeReplies | No | Include @-replies. Default false, replies are usually noise for a digest. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It explicitly states the tool is read-only and cannot post, reply, like, follow, DM, or write. Also mentions ordering (newest first) and default handle set, providing comprehensive behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first covers purpose and ordering, second covers read-only constraint and default behavior. No redundant information, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 3 parameters, no output schema, and no annotations, the description adequately covers purpose, behavior, and defaults. Lacks details on error handling or rate limits, but these are not essential for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minor context (e.g., 'using a logged-in session') but does not significantly enhance understanding beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns the most recent tweets from a set of X handles, newest first. Specifies read-only nature, distinguishing it from write actions. Even without siblings, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the tool's use case: summarizing a curated group of accounts. Notes it defaults to server-configured handles. Provides context but lacks explicit when-not or alternatives, though not critical given simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is no possibility of confusion or overlap between tools.
The single tool name follows a clear verb_noun pattern (get_recent_tweets), which is consistent with common MCP naming conventions.
The server has exactly one tool, which appropriately matches its narrow, read-only purpose of retrieving recent tweets from a curated set of handles.
The tool fully covers the server's stated purpose of summarizing recent tweets from configured handles, with no missing operations for that specific domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Twitter/X read-only MCP server — 12 tools: search, users, tweets, followers, timelines, trends.
Hosted MCP for X/Twitter and Reddit. 12 read-only tools, no API keys, free during beta.
FastMCP server for posting formatted content to X (Twitter) — Tollbooth-monetized, DPYC-native
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/excellario/X-feed'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
