Social Media MCP Server
Integrated for research capabilities, allowing the MCP server to search for information, facts, and news using Brave Search
Enables posting content to Mastodon with platform-specific formatting, managing API rate limits, and tracking post performance
Used for content generation, allowing the MCP server to create social media posts using OpenAI's models
Integrated as a research tool, allowing the MCP server to research topics and gather information for social media content
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., "@Social Media MCP ServerPost about AI ethics trends on Twitter and LinkedIn"
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.
Social Media MCP Server
A Model Context Protocol (MCP) server that connects to multiple social media platforms, allowing users to create and publish content across platforms through natural language instructions.
Features
Natural Language Interface: Create posts for multiple platforms with simple instructions
Research Capabilities: Automatically research hashtags, trends, facts, and news
Multi-platform Support: Post to Twitter/X, Mastodon, and LinkedIn with platform-specific formatting
Content Generation: Generate engaging content using multiple AI models
Rate Limit Management: Handle API rate limits gracefully with queuing and fallbacks
Analytics: Track post performance and optimize content strategy
Related MCP server: PostWire
Getting Started
Prerequisites
Node.js (v18+)
npm or yarn
API keys for:
Twitter/X
Mastodon
LinkedIn
OpenAI and/or Anthropic (for content generation)
Brave Search (for research)
Installation
Clone the repository:
git clone https://github.com/yourusername/social-media-mcp.git
cd social-media-mcpInstall dependencies:
npm installCreate a
.envfile with your API keys:
# Twitter API Credentials
TWITTER_API_KEY=your_api_key
TWITTER_API_SECRET=your_api_secret
TWITTER_BEARER_TOKEN=your_bearer_token
TWITTER_ACCESS_TOKEN=your_access_token
TWITTER_ACCESS_SECRET=your_access_secret
TWITTER_OAUTH_CLIENT=your_oauth_client
TWITTER_CLIENT_SECRET=your_client_secret
# Mastodon API Credentials
MASTODON_CLIENT_SECRET=your_client_secret
MASTODON_CLIENT_KEY=your_client_key
MASTODON_ACCESS_TOKEN=your_access_token
# LinkedIn API Credentials
LINKEDIN_CLIENT_ID=your_client_id
LINKEDIN_CLIENT_SECRET=your_client_secret
LINKEDIN_ACCESS_TOKEN=your_access_token
# AI API Keys
ANTHROPIC_API_KEY=your_anthropic_key
OPENAI_API_KEY=your_openai_key
BRAVE_API_KEY=your_brave_key
# Application Settings
LOG_LEVEL=info
CACHE_ENABLED=true
RATE_LIMIT_ENABLED=trueBuild the project:
npm run buildStart the server:
npm startMCP Integration
To use this MCP server with Claude or another MCP-compatible assistant, add it to your MCP settings:
{
"mcpServers": {
"social-media-mcp": {
"command": "node",
"args": ["path/to/social-media-mcp/build/index.js"],
"env": {
"TWITTER_API_KEY": "your_api_key",
"TWITTER_API_SECRET": "your_api_secret",
"TWITTER_BEARER_TOKEN": "your_bearer_token",
"TWITTER_ACCESS_TOKEN": "your_access_token",
"TWITTER_ACCESS_SECRET": "your_access_secret",
"TWITTER_OAUTH_CLIENT": "your_oauth_client",
"TWITTER_CLIENT_SECRET": "your_client_secret",
"MASTODON_CLIENT_SECRET": "your_client_secret",
"MASTODON_CLIENT_KEY": "your_client_key",
"MASTODON_ACCESS_TOKEN": "your_access_token",
"LINKEDIN_CLIENT_ID": "your_client_id",
"LINKEDIN_CLIENT_SECRET": "your_client_secret",
"LINKEDIN_ACCESS_TOKEN": "your_access_token",
"ANTHROPIC_API_KEY": "your_anthropic_key",
"OPENAI_API_KEY": "your_openai_key",
"BRAVE_API_KEY": "your_brave_key"
},
"disabled": false,
"autoApprove": []
}
}
}Available Tools
create_post
Create and post content to social media platforms based on natural language instructions.
{
"instruction": "Post about the latest AI developments in healthcare",
"platforms": ["twitter", "mastodon", "linkedin"],
"postImmediately": false
}get_trending_topics
Get trending topics from social media platforms.
{
"platform": "twitter",
"category": "technology",
"count": 5
}research_topic
Research a topic using Brave Search and Perplexity.
{
"topic": "artificial intelligence ethics",
"includeHashtags": true,
"includeFacts": true,
"includeTrends": true,
"includeNews": true
}Development
Project Structure
social-media-mcp/
├── src/
│ ├── index.ts # Entry point
│ ├── config/ # Configuration
│ ├── types/ # TypeScript type definitions
│ ├── core/ # Core orchestration logic
│ ├── nlp/ # Natural language processing
│ ├── research/ # Research engine
│ │ ├── brave/ # Brave Search integration
│ │ ├── perplexity/ # Perplexity integration
│ │ └── aggregator/ # Research result aggregation
│ ├── content/ # Content generation
│ │ ├── strategies/ # AI model strategies
│ │ ├── formatter/ # Platform-specific formatting
│ │ └── templates/ # Content templates
│ ├── platforms/ # Social media platform integrations
│ │ ├── twitter/ # Twitter API integration
│ │ └── mastodon/ # Mastodon API integration
│ ├── analytics/ # Analytics engine
│ ├── rate-limit/ # Rate limit management
│ └── utils/ # Utility functions
├── memory-bank/ # Project documentation
├── build/ # Compiled JavaScript
├── .env # Environment variables
├── package.json # Dependencies and scripts
└── tsconfig.json # TypeScript configurationScripts
npm run build: Build the projectnpm run dev: Run in development mode with hot reloadingnpm start: Start the production servernpm test: Run testsnpm run lint: Run lintingnpm run format: Format code
Utility Scripts
The scripts directory contains utility scripts for the Social Media MCP Server:
scripts/linkedin-oauth.js: Handles the OAuth 2.0 flow for LinkedIn to obtain an access tokenUsage:
cd scripts && npm install && npm run linkedin-oauthSee scripts/README.md for more details
Documentation
The documentation directory contains detailed documentation for each social media platform integration:
License
This project is licensed under the ISC License.
Acknowledgements
Available Tools
3 toolscreate_postC
Create and post content to social media platforms based on natural language instructions
| Name | Required | Description | Default |
|---|---|---|---|
| instruction | Yes | Natural language instruction for the post (e.g., "Post about the latest AI developments") | |
| platforms | No | Social media platforms to post to | |
| postImmediately | No | Whether to post immediately or return a preview | |
| conversationId | No | ID of an existing conversation to continue | |
| questionId | No | ID of the question being answered | |
| answer | No | Answer to the question | |
| ignoreHistory | No | Whether to ignore similar posts in history | |
| actionableInsights | No | Whether to include actionable insights in the post |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic function. It doesn't disclose critical behavioral traits like authentication requirements, rate limits, whether posts are permanent or draftable, error handling, or what happens when posting to multiple platforms. The mention of 'return a preview' via the postImmediately parameter is helpful but insufficient.
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 a single, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('create and post', 'social media platforms', 'natural language instructions') contributes directly to understanding the tool's function.
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 complex tool with 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (e.g., post IDs, success status), error conditions, or how it handles the various parameters like conversationId or actionableInsights. The sibling tools suggest a broader context that isn't addressed.
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 itself. The description adds minimal value beyond the schema by implying natural language processing for the 'instruction' parameter, but doesn't explain parameter interactions or provide additional context for the 8 parameters.
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 action ('Create and post content') and target ('social media platforms'), with the specific method 'based on natural language instructions' distinguishing it from typical API-based posting tools. However, it doesn't differentiate from sibling tools like 'get_trending_topics' or 'research_topic', which serve completely different purposes.
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 guidance is provided about when to use this tool versus alternatives or prerequisites. The description mentions posting to social media but doesn't specify use cases, constraints, or how it relates to the sibling tools for research and trend analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trending_topicsC
Get trending topics from social media platforms
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Social media platform to get trending topics from | |
| category | No | Category of trending topics (e.g., "technology", "entertainment") | |
| count | No | Number of trending topics to return |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't reveal any behavioral traits such as rate limits, authentication requirements, data freshness, or whether it's a read-only operation. For a tool fetching live social media data, this is a significant gap in transparency.
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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of fetching trending topics from social media (which involves real-time data, platform-specific behaviors, and potential rate limits), the description is insufficient. With no annotations, no output schema, and minimal behavioral context, it doesn't provide enough information for an agent to understand the tool's full scope and limitations.
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?
The schema description coverage is 100%, with all parameters documented in the schema itself. The description doesn't add any meaning beyond what the schema provides, such as explaining how 'all' works for the platform parameter or what categories are available. Baseline 3 is appropriate when the schema does the heavy lifting.
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 'Get' and the resource 'trending topics from social media platforms', making the purpose unambiguous. It doesn't explicitly distinguish from sibling tools like 'create_post' or 'research_topic', but the action is specific enough to imply a read-only operation distinct from creation or research.
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 provides no guidance on when to use this tool versus alternatives like 'research_topic' or other potential tools for social media analysis. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
research_topicC
Research a topic using Brave Search and Perplexity
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic to research | |
| includeHashtags | No | Whether to include relevant hashtags | |
| includeFacts | No | Whether to include facts about the topic | |
| includeTrends | No | Whether to include trending information | |
| includeNews | No | Whether to include news articles |
TDQS
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 but offers minimal information. It mentions the search engines used but doesn't describe rate limits, authentication needs, response format, pagination, or what constitutes 'research' output. For a tool with 5 parameters and no annotations, this is insufficient behavioral context.
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 extremely concise at just 6 words, with zero wasted language. It's front-loaded with the core action and immediately specifies the search engines used. Every word serves a purpose in this minimal but complete statement of function.
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 research tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the research output looks like, how results are structured, what sources are consulted beyond the named search engines, or limitations of the research process. The agent would have significant gaps in understanding how to effectively use this 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 all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. This meets the baseline expectation when schema coverage is complete, but doesn't provide additional contextual meaning about how parameters interact.
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 ('research') and resource ('topic') with specific methods ('using Brave Search and Perplexity'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_trending_topics' or 'create_post', which would require more specific scope definition.
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 provides no guidance on when to use this tool versus alternatives like 'get_trending_topics' for trending information or 'create_post' for content creation. There's no mention of prerequisites, limitations, or appropriate contexts for choosing this research tool over other methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- First observed
create_post - First observed
get_trending_topics - First observed
research_topic
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: create_post handles content creation, get_trending_topics retrieves trending information, and research_topic performs topic research using external search tools. There is no overlap in functionality, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun pattern (create_post, get_trending_topics, research_topic), using snake_case throughout. This predictability enhances readability and usability for agents.
With only 3 tools, the server feels under-scoped for a social media domain. Key operations like reading posts, updating/deleting content, or interacting with comments are missing, limiting the server's utility for comprehensive social media tasks.
The toolset is severely incomplete for social media operations. It lacks basic CRUD functionality (e.g., no read, update, or delete for posts), interaction tools (e.g., like, comment, share), and platform-specific features, leaving significant gaps that will hinder agent workflows.
Related MCP Connectors
Draft, schedule and publish social posts to nine platforms from any AI agent.
Schedule and publish social media posts to 10 platforms from your AI agent
- AntworkOAuthio.antwork
Draft, schedule, and publish social posts for your workspace straight from your AI.
Post, schedule, and track social posts on X, Bluesky, LinkedIn, Instagram and more from AI agents.
Related MCP Servers
- AlicenseAqualityBmaintenanceEnables AI assistants to schedule and publish social media posts to platforms like Instagram, TikTok, YouTube, LinkedIn, Facebook, X, Threads, and Pinterest using natural language.3399 npm3MIT
- AlicenseAqualityBmaintenanceLets any AI agent post to TikTok, Instagram, YouTube, X, LinkedIn, Bluesky, Telegram, Mastodon and Discord through a single post_to_social tool. Connect an account once, then publish everywhere.2127 npmMIT
- AlicenseNot gradedqualityAmaintenanceEnables posting to multiple social media platforms (X, LinkedIn, Facebook, Instagram, etc.) via a unified API, handling OAuth, media, and scheduling for each network.AGPL 3.0

PostMCP MCP Serverofficial
AlicenseAqualityBmaintenanceEnables AI assistants to manage social media publishing across platforms like LinkedIn, Twitter, Facebook, Instagram, Threads, and Bluesky.759 npmMIT