Social Media MCP Server
소셜 미디어 MCP 서버
여러 소셜 미디어 플랫폼에 연결되는 MCP(Model Context Protocol) 서버로, 사용자는 자연어 명령어를 통해 여러 플랫폼에서 콘텐츠를 만들고 게시할 수 있습니다.
특징
자연어 인터페이스 : 간단한 지침으로 다양한 플랫폼에 대한 게시물을 작성하세요
연구 기능 : 해시태그, 트렌드, 사실 및 뉴스를 자동으로 연구합니다.
다중 플랫폼 지원 : 플랫폼별 서식을 사용하여 Twitter/X, Mastodon 및 LinkedIn에 게시
콘텐츠 생성 : 다양한 AI 모델을 사용하여 매력적인 콘텐츠 생성
비율 제한 관리 : 대기열 및 폴백을 통해 API 비율 제한을 원활하게 처리합니다.
분석 : 게시물 성과를 추적하고 콘텐츠 전략을 최적화합니다.
Related MCP server: PostWire
시작하기
필수 조건
Node.js(v18+)
npm 또는 yarn
API 키:
트위터/X
마스토돈
링크드인
OpenAI 및/또는 Anthropic(콘텐츠 생성용)
Brave Search(연구용)
설치
저장소를 복제합니다.
지엑스피1
종속성 설치:
npm installAPI 키로
.env파일을 만듭니다.
# 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=true프로젝트를 빌드하세요:
npm run build서버를 시작합니다:
npm startMCP 통합
이 MCP 서버를 Claude 또는 다른 MCP 호환 어시스턴트와 함께 사용하려면 MCP 설정에 추가하세요.
{
"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": []
}
}
}사용 가능한 도구
게시물 생성
자연어 명령에 따라 콘텐츠를 제작하여 소셜 미디어 플랫폼에 게시합니다.
{
"instruction": "Post about the latest AI developments in healthcare",
"platforms": ["twitter", "mastodon", "linkedin"],
"postImmediately": false
}인기 주제 얻기
소셜 미디어 플랫폼에서 트렌드 주제를 받아보세요.
{
"platform": "twitter",
"category": "technology",
"count": 5
}연구 주제
Brave Search와 Perplexity를 사용하여 주제에 대해 조사해 보세요.
{
"topic": "artificial intelligence ethics",
"includeHashtags": true,
"includeFacts": true,
"includeTrends": true,
"includeNews": true
}개발
프로젝트 구조
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 configuration스크립트
npm run build: 프로젝트 빌드npm run dev: 핫 리로딩을 통해 개발 모드로 실행npm start: 프로덕션 서버 시작npm test: 테스트 실행npm run lint: 린팅 실행npm run format: 형식 코드
유틸리티 스크립트
scripts 디렉토리에는 소셜 미디어 MCP 서버용 유틸리티 스크립트가 포함되어 있습니다.
scripts/linkedin-oauth.js: LinkedIn이 액세스 토큰을 얻기 위한 OAuth 2.0 흐름을 처리합니다.사용법:
cd scripts && npm install && npm run linkedin-oauth자세한 내용은 scripts/README.md를 참조하세요.
선적 서류 비치
documentation 디렉토리에는 각 소셜 미디어 플랫폼 통합에 대한 자세한 문서가 포함되어 있습니다.
특허
이 프로젝트는 ISC 라이선스에 따라 라이선스가 부여되었습니다.
감사의 말
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
- PostponeOAuthapp.postpone
Schedule and manage social media posts across connected platforms using natural language.
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
Multi-platform social media post creation, scheduling, and publishing.
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.33774 npm4MIT
- 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.243 npmMIT

PostMCP MCP Serverofficial
AlicenseAqualityBmaintenanceEnables AI assistants to manage social media publishing across platforms like LinkedIn, Twitter, Facebook, Instagram, Threads, and Bluesky.728 npmMIT
AdaptlyPostofficial
AlicenseAqualityAmaintenanceGives AI agents the ability to schedule and publish social media posts to Instagram, TikTok, YouTube, X, LinkedIn, Facebook, Pinterest, Threads, and Bluesky. Create, schedule, and bulk-plan posts with per-platform captions, then check per-platform results and retry failures.12MIT