What can you do with this server?

The X MCP Server provides tools to interact with the X (Twitter) API through a Model Context Protocol server: * Post Tweets: Create and post tweets up to 280 characters, with optional replies to existing tweets by specifying reply_to_tweet_id * Get User Timeline: Retrieve your recent tweets with customizable count limits (default 10, maximum 100) * Search Tweets: Search for tweets using specific queries with adjustable result counts (default 10, maximum 100) * Error Handling: Comprehensive handling for missing API credentials, invalid tweet content, API rate limits, network errors, and invalid parameters * Security: Secure management of API credentials and sensitive data through environment variables

How do I use X MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@X MCP Server post a tweet saying 'Just launched our new MCP integration! 🚀 #developer #ai'" 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.

X MCP Server

by krishna-paulraj

Overview Schema Related Servers Score Discussions

JavaScript

Remote

X MCP Server

A Model Context Protocol (MCP) server for posting tweets to X (Twitter) and interacting with the X API.

Features

Post Tweets: Create and post tweets to X (Twitter)
Get User Timeline: Retrieve your recent tweets
Search Tweets: Search for tweets using queries
Reply to Tweets: Reply to existing tweets
Error Handling: Comprehensive error handling and validation

Related MCP server: Apex MCP for X Management

Prerequisites

X Developer Account: You need a Twitter/X developer account
- Go to Twitter Developer Portal
- Create a new app and get your API credentials
Node.js: Version 18 or higher

Setup

Clone and Install Dependencies:
```
npm install
```

Configure Environment Variables:

cp env.example .env

Edit .env and add your X API credentials:

X_API_KEY=your_api_key_here
X_API_SECRET=your_api_secret_here
X_ACCESS_TOKEN=your_access_token_here
X_ACCESS_TOKEN_SECRET=your_access_token_secret_here

Build the Project:
```
npm run build
```

Usage

Running the Server

# Development mode
npm run dev

# Production mode
npm start

Available Tools

The server provides the following tools:

1. `post_tweet`

Post a new tweet to X.

Parameters:

text (required): The tweet content (max 280 characters)
reply_to_tweet_id (optional): ID of the tweet to reply to

Example:

{
  "text": "Hello, world! This is my first tweet via MCP! 🚀",
  "reply_to_tweet_id": "1234567890123456789"
}

2. `get_user_timeline`

Get your recent tweets.

Parameters:

count (optional): Number of tweets to retrieve (default: 10, max: 100)

Example:

{
  "count": 5
}

3. `search_tweets`

Search for tweets using a query.

Parameters:

query (required): Search query
count (optional): Number of results (default: 10, max: 100)

Example:

{
  "query": "MCP protocol",
  "count": 20
}

MCP Client Configuration

To use this server with an MCP client, add it to your client configuration:

{
  "mcpServers": {
    "x-server": {
      "command": "node",
      "args": ["dist/index.js"],
      "env": {
        "X_API_KEY": "your_api_key",
        "X_API_SECRET": "your_api_secret",
        "X_ACCESS_TOKEN": "your_access_token",
        "X_ACCESS_TOKEN_SECRET": "your_access_token_secret"
      }
    }
  }
}

Development

Project Structure

x-mcp-server/
├── src/
│   └── index.ts          # Main server implementation
├── dist/                 # Compiled JavaScript (generated)
├── package.json          # Dependencies and scripts
├── tsconfig.json         # TypeScript configuration
├── env.example           # Environment variables template
└── README.md            # This file

Scripts

npm run build: Compile TypeScript to JavaScript
npm start: Run the compiled server
npm run dev: Run in development mode with hot reload
npm test: Run tests (when implemented)

Error Handling

The server includes comprehensive error handling for:

Missing API credentials
Invalid tweet content (length, format)
API rate limits
Network errors
Invalid parameters

Security Notes

Never commit your .env file to version control
Keep your API credentials secure
Use environment variables for all sensitive data
Consider using a .gitignore file to exclude sensitive files

Contributing

Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request

License

MIT License - see LICENSE file for details.

Support

For issues and questions:

Check the error messages for common issues
Verify your API credentials are correct
Ensure you have the necessary X API permissions
Check the X API documentation for rate limits and restrictions

Available Tools

3 tools

get_user_timelineC

Get the user's recent tweets

ParametersJSON Schema

Name	Required	Description	Default
`count`	No	Number of tweets to retrieve (max 100)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'recent tweets' which implies a time-based scope, but doesn't specify what 'recent' means, whether authentication is required, rate limits, or the format of returned data. This is a significant gap for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. However, it could be more front-loaded with additional context to improve utility, slightly reducing the score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'recent' means, authentication requirements, rate limits, or the structure of returned tweets. For a tool that retrieves user data, this leaves critical gaps in understanding how to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents the single parameter 'count'. The description doesn't add any parameter-specific information beyond what's in the schema, but since the schema does the heavy lifting, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('user's recent tweets'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'search_tweets' which might also retrieve tweets, so it doesn't reach the highest score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'search_tweets' or 'post_tweet'. The description only states what it does, not when it's appropriate, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

post_tweetC

Post a tweet to X (Twitter)

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	The text content of the tweet (max 280 characters)
`reply_to_tweet_id`	No	Optional: ID of the tweet to reply to

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions posting to X (Twitter) but doesn't disclose critical traits like authentication requirements, rate limits, whether it's a destructive write operation, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that states the core functionality without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a write operation to a social media platform), lack of annotations, and absence of an output schema, the description is insufficient. It doesn't cover behavioral aspects, error conditions, or return values, leaving significant gaps for the agent to navigate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents both parameters ('text' and 'reply_to_tweet_id') with their types and constraints. The description adds no parameter-specific information beyond what's in the schema, resulting in a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Post') and target resource ('a tweet to X (Twitter)'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_user_timeline' or 'search_tweets' beyond the obvious action difference, missing explicit sibling comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., authentication), use cases (e.g., broadcasting vs. replying), or exclusions, leaving the agent to infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_tweetsC

Search for tweets using a query

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query for tweets
`count`	No	Number of tweets to retrieve (max 100)

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden but provides minimal behavioral insight. It mentions searching but doesn't disclose key traits like rate limits, authentication needs, result format, or pagination. This is inadequate for a search tool that likely involves API constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words, making it appropriately concise. However, it lacks front-loaded detail that could better guide usage, slightly reducing its effectiveness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations or output schema, the description is incomplete. It fails to explain behavioral aspects like result structure, error handling, or constraints, which are critical for a search tool. This leaves significant gaps for agent operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents parameters (query and count). The description adds no additional meaning beyond implying a 'query' is used, aligning with the baseline score when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the verb ('search') and resource ('tweets') with a basic action, making the purpose understandable but vague. It doesn't specify what aspects of tweets are searched (e.g., text, hashtags, users) or distinguish it from sibling tools like 'get_user_timeline' for user-specific tweets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention scenarios like general searches versus user-specific timelines (get_user_timeline) or creating tweets (post_tweet), leaving the agent to infer usage from tool names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: get_user_timeline retrieves a user's recent tweets, post_tweet creates a new tweet, and search_tweets finds tweets by query. There is no overlap in functionality, making tool selection straightforward for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (get_user_timeline, post_tweet, search_tweets) with clear, descriptive verbs. The naming is uniform and predictable across the set.

Tool Count3/5

With only 3 tools, the server feels slightly thin for a Twitter/X integration, as it lacks operations like deleting tweets, managing likes, or handling direct messages. However, it covers basic posting and reading, which is reasonable for a minimal scope.

Completeness3/5

The tools provide core read and write capabilities (get, post, search) but miss key Twitter/X features such as tweet deletion, like/unlike, retweeting, or user profile management. This leaves notable gaps that agents might need to work around for full functionality.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

SocialDataX X / Twitter MCP A
com.52choujiang
X / Twitter public post, comment, reply, user, and search tools.
Social Media Search
161
twitter D
com.jojapi
X (formerly Twitter): X (formerly Twitter) public and private data API for search, posts (Tweets).
Social Media Search
321
twitr.sh A
sh.twitr
X/Twitter reads, search, monitors and posting. Pay-per-call in USDC — no signup, no API keys.
Social Media Communication
1421
twitter-x-aio C
com.jojapi
Twitter: Access real-time Twitter/X data as soon as it's posted! With the Twitter/X AIO API, you.
Social Media Communication
231

Related MCP Servers

X (Twitter) MCP Server
Social Media Communication
Dishant27
A
license
Not graded
quality
D
maintenance
Enables interaction with X (formerly Twitter), allowing for posting tweets, searching content, managing accounts, and organizing lists.
Updated a year ago (2025-04-06 07:59 UTC)
25
3
MIT
Apex MCP for X Management
Social Media
xonack
A
license
Not graded
quality
D
maintenance
Enables complete management of X (Twitter) accounts through a single API key, supporting functions like getting tweets, searching, generating and posting replies.
Updated a year ago (2025-10-17 06:18 UTC)
40
2
MIT
X (Twitter) MCP
Social Media Communication
arnaldo-delisio
A
license
Not graded
quality
D
maintenance
Enables interaction with X (Twitter) to post tweets, threads, and replies while retrieving tweet metrics and account information. It supports core management tasks like deleting tweets and verifying authentication through the Twitter API.
Updated 9 months ago (2025-12-09 15:19 UTC)
MIT
x-mcp-server
MindMadeLab
A
license
Not graded
quality
C
maintenance
Enables AI assistants to interact with X (Twitter) API v2 for posting tweets, searching, liking, retweeting, and more through natural language.
Updated 5 months ago (2026-03-27 12:17 UTC)
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/krishna-paulraj/x-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

X MCP Server

Features

Prerequisites

Setup

Usage

Running the Server

Available Tools

1. post_tweet

2. get_user_timeline

3. search_tweets

MCP Client Configuration

Development

Project Structure

Scripts

Error Handling

Security Notes

Contributing

License

Support

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

1. `post_tweet`

2. `get_user_timeline`

3. `search_tweets`