Click on "Deploy 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., "@twitterapi.mcp show mentions for @elonmusk"
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.
MCP server that exposes twitterapi.io endpoints as tools for AI agents and MCP hosts. Written in TypeScript, distributed on npm, runnable with a single npx command.
Tool | Description | API Endpoint | Auth |
Fetch tweets mentioning a user. |
| API key | |
Fetch a page of the conversation thread around a tweet. |
| API key | |
Create a tweet or reply. |
| API key + cookies + proxy | |
Delete one of your tweets. |
| API key + cookies + proxy |
Related MCP server: x-mcp
Visit https://twitterapi.io/dashboard and obtain your x-api-key.
create_tweet and delete_tweet authenticate with your account's own session
cookies. From a browser logged into X, open DevTools → Application → Cookies →
https://x.com and copy the auth_token and ct0 values.
Variable | Required | Description |
| always | twitterapi.io API key |
| writes |
|
| writes |
|
| writes | Residential proxy, |
The server derives the login_cookies value twitterapi.io expects from
auth_token + ct0. These cookies expire over time (typically weeks); when a
write starts returning an auth error, refresh them from the browser.
The API key alone is enough for the read tools. Add the cookie/proxy vars only if you need write actions.
Claude Desktop (%APPDATA%\Claude\claude_desktop_config.json on Windows,
~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"twitterapi": {
"command": "npx",
"args": ["-y", "@pedrot95dev/twitterapi.mcp"],
"env": {
"TWITTERAPI_IO_KEY": "your_key_here",
"TWITTERAPI_IO_AUTH_TOKEN": "your_auth_token_cookie",
"TWITTERAPI_IO_CT0": "your_ct0_cookie",
"TWITTERAPI_IO_PROXY": "http://user:pass@ip:port"
}
}
}
}npx -y @pedrot95dev/twitterapi.mcp downloads and runs the latest published version. Only
Node.js (>= 18) is required — no global install needed.
Other MCP hosts (e.g. Cursor): add the same npx command + env vars in the
host's MCP settings UI or config file.
Fetch tweets that mention or reply to a user. Makes a single request per call;
page by passing cursor from a previous response's next_cursor.
Parameter | Type | Default | Description |
| string | (required) | X username, with or without |
| string | — | Start time filter (e.g. |
| string | — | End time filter |
| string | — | Pagination cursor from a previous |
|
|
| Sort mode |
| integer |
| Max tweets to return from this single request |
{
"tweets": [ ... ],
"count": 12,
"has_next_page": true,
"next_cursor": "DAADDAAB...",
"status": "success",
"msg": null
}Fetch the conversation thread around a tweet. Returns the original tweet, the
intermediate replies up the chain, the tweet itself, and its direct replies.
Each returned tweet includes entities.urls with expanded links — useful for
scanning a mention's surrounding conversation for URLs.
Makes exactly one request per call (1-to-1 with the endpoint — no internal
pagination). Page through longer threads with cursor.
Parameter | Type | Default | Description |
| string | (required) | The tweet ID to get the thread context for |
| string | — | Pagination cursor from a previous |
{
"tweets": [ ... ],
"count": 6,
"has_next_page": false,
"next_cursor": "",
"status": "success",
"msg": "success"
}Note: this endpoint paginates unevenly — a page may return few or zero tweets
while has_next_page is still true. Follow next_cursor until
has_next_page is false to collect the whole thread.
Post a new tweet or reply. Supports quotes, media, communities, and scheduling. Requires the cookie + proxy env vars (see step 2).
Parameter | Type | Default | Description |
| string | (required) | The text content of the tweet |
| string | — | Tweet ID to reply to (makes this a reply) |
| string | — | Tweet ID to quote |
| string | — | URL for quote (alternative to |
| string | — | Post inside a specific community |
| boolean |
| Allow >280 chars (Premium accounts) |
| string[] | — | Media IDs from a prior |
| string | — | ISO-8601 future time, e.g. |
{ "tweet_id": "1234567890123456789", "status": "success", "msg": "success" }Delete one of your tweets by ID. Requires the cookie + proxy env vars.
Parameter | Type | Default | Description |
| string | (required) | The ID of the tweet to delete |
{ "status": "success", "msg": "success" }Local development, build, and testing instructions are in CONTRIBUTING.md.
MIT — see LICENSE.
Based on the official twitterapi-io agent skill: https://github.com/kaitoInfra/twitterapi-io API service: https://twitterapi.io
Create or reply to a tweet via the v2 endpoint. Uses login_cookies built from the account's auth_token/ct0 env vars (requires TWITTERAPI_IO_AUTH_TOKEN, TWITTERAPI_IO_CT0, TWITTERAPI_IO_PROXY).
| Name | Required | Description | Default |
|---|---|---|---|
| media_ids | No | Media IDs from prior /twitter/upload_media_v2 | |
| tweet_text | Yes | The text content of the tweet | |
| community_id | No | Post inside a specific community | |
| schedule_for | No | ISO-8601 future time e.g. 2026-01-20T10:00:00.000Z | |
| is_note_tweet | No | Allow >280 chars (Premium accounts) | |
| attachment_url | No | URL for quote (alternative to quote_tweet_id) | |
| quote_tweet_id | No | Tweet ID to quote | |
| reply_to_tweet_id | No | Tweet ID to reply to (makes this a reply) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It notes the use of v2 endpoint and auth via cookies, but omits details like the irreversible nature of posting, rate limits, or that it's a write operation. Some transparency but not comprehensive.
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 sentences: first states the action, second details authentication requirements. No extraneous information; clear and front-loaded.
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?
With 8 parameters, no output schema, and no annotations, the description could discuss return values or error handling. It covers the core function and auth but lacks completeness for a complex tool.
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 parameters are well-documented in the schema. The description adds no additional parameter-specific insights, maintaining the baseline score of 3.
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?
The description clearly states the tool creates or replies to a tweet via the v2 endpoint. It uses a specific verb and resource and is distinct from siblings like get_user_mentions or delete_tweet.
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?
The description specifies required environment variables (auth_token, ct0, proxy) and the cookie mechanism, which are prerequisites. It does not explicitly compare to sibling tools but the context implies use for tweet creation, not reading or deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a tweet by ID (must be owned by the logged-in account). Uses login_cookies built from the account's auth_token/ct0 env vars.
| Name | Required | Description | Default |
|---|---|---|---|
| tweet_id | Yes | The ID of the tweet to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the destructive nature (delete), ownership requirement, and authentication mechanism via login_cookies. It does not mention reversibility or side effects, but these are typical for a delete operation.
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?
The description is two sentences long, with the first sentence stating the action and constraint, and the second adding authentication context. Every sentence is necessary and front-loaded.
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 delete tool with one parameter and no output schema, the description covers the essential aspects: action, target, ownership requirement, and auth setup. It does not explain error behavior or return values, but these are not critical given the simplicity.
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 coverage is 100%, with the single parameter `tweet_id` described as 'The ID of the tweet to delete'. The description adds context about ownership and auth but does not add new detail about the parameter itself, resulting in adequate but minimal added value.
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?
The description clearly states 'Delete a tweet by ID' and adds the ownership constraint, distinguishing it from read-only or creation siblings like get_user_mentions and create_tweet.
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?
It specifies that the tweet must be owned by the logged-in account and mentions the required authentication setup, giving clear context for when to use. It does not explicitly state when not to use, but the ownership condition implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one page of the conversation thread around a tweet (to find links in context). Returns the original tweet, intermediate replies up the chain, the tweet itself, and its direct replies; each tweet includes entities.urls with expanded links. Makes exactly one request per call: pages are uneven (a page may be empty while has_next_page is true), so pass next_cursor back as cursor to fetch the next page.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Pagination cursor from a previous response's next_cursor | |
| tweet_id | Yes | The tweet ID to get the thread context for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully carries the burden. It discloses return structure: 'original tweet, intermediate replies up the chain, the tweet itself, and direct replies; each tweet includes entities.urls'. It also notes pagination irregularity and single-request nature. Comprehensive for a non-annotated tool.
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 sentences, front-loaded with purpose. Every sentence adds unique value without repetition. No filler or redundant phrasing.
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?
Despite no output schema, the description fully explains what is returned (including expanded URLs) and pagination mechanics. Covers all aspects needed for correct invocation: purpose, parameters, behavior, and return structure.
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 coverage is 100%, so baseline is 3. The description adds minor value by explaining the cursor parameter's usage ('pass next_cursor back as cursor'), but the schema already describes both parameters adequately. No additional semantics beyond what schema provides.
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?
The description clearly states the verb 'Fetch', the resource 'conversation thread around a tweet', and the specific use case 'to find links in context'. It distinguishes from sibling tools (get_user_mentions, create_tweet, delete_tweet) by focusing on thread context and link extraction.
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?
The description explains pagination behavior: 'Makes exactly one request per call' and 'pages are uneven... so pass next_cursor back as cursor'. It implies when to use (when needing thread context with links) but does not explicitly state when not to use or list alternatives besides sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch tweets mentioning a specific X/Twitter user. Makes a single request per call. The caller handles pagination by passing cursor (from a previous next_cursor).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max tweets to return from this single request (default 50) | |
| cursor | No | Pagination cursor from a previous response's next_cursor | |
| user_name | Yes | X username, with or without @ | |
| query_type | No | Sort mode (default Latest) | |
| since_time | No | Start time filter (e.g. 2025-06-01 or ISO datetime) | |
| until_time | No | End time filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description notes single-request behavior and cursor-based pagination, which adds transparency, but lacks details on authentication, rate limits, errors, or response structure.
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 sentences, front-loaded with purpose, then pagination behavior. No unnecessary words.
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?
Without an output schema, the description should explain response structure more. It mentions next_cursor but not full response format, defaults, or error handling. Adequate but not fully self-contained.
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 coverage is 100%, so all parameters have descriptions. The tool description references 'cursor' but adds no new semantics beyond the schema.
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?
The description clearly states 'Fetch tweets mentioning a specific X/Twitter user', which is a specific verb+resource. Sibling tools are for thread context, creating, and deleting, so this distinguishes well.
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?
No explicit guidance on when to use this tool vs alternatives. While pagination handling is described, there is no when/when-not or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0create_tweetdelete_tweetget_tweet_thread_contextget_user_mentionsScored across 4 tools
Each tool targets a distinct action: fetching mentions, retrieving thread context, creating tweets, and deleting tweets. No overlap in purpose.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_user_mentions, create_tweet), making them predictable.
4 tools is slightly minimal for a Twitter API server but reasonable for a focused subset. Each tool serves a clear purpose without redundancy.
The tool set covers core CRUD for tweets (create, delete) and some read operations (mentions, thread context), but lacks common features like timeline retrieval, search, or interactions (like, retweet).
Twitter/X read-only MCP server — 12 tools: search, users, tweets, followers, timelines, trends.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server exposing the Backtest360 engine API as tools for AI agents.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
