소셜 플랫폼 데이터와 온체인 데이터에 대한 표준화된 액세스를 제공하는 확장 가능한 모델 컨텍스트 프로토콜 서버입니다. 현재 Farcaster(Neynar API를 통해)를 지원하며, 트위터 통합을 위한 플레이스홀더도 제공합니다. Telegram 등 온체인 데이터를 포함하는 더 많은 플랫폼이 곧 추가될 예정입니다.
MCP 호환 : 모델 컨텍스트 프로토콜 사양을 완벽하게 구현합니다.
다중 플랫폼 : 여러 소셜 미디어 플랫폼을 지원하도록 설계되었습니다.
확장 가능 : 새로운 플랫폼 공급자를 쉽게 추가할 수 있습니다.
Well-Formatted : LLM 사용을 위한 최적화된 컨텍스트 형식
유연한 전송 : stdio 및 SSE/HTTP 전송을 모두 지원합니다.
Related MCP server: MCP URL Fetcher
Farcaster : Neynar API를 통한 전체 구현
Twitter : 플레이스홀더(구현되지 않음)
노드.js 16+
Neynar API 키(Farcaster 액세스용) https://neynar.com/
저장소를 복제합니다
지엑스피1
종속성 설치
npm install템플릿에서 .env 파일을 만듭니다.
cp .env.example .env
# Edit .env with your API keys환경 변수 구성
필수 : .env 파일에 NEYNAR_API_KEY 설정합니다.
https://neynar.com/ 에서 Neynar API 키를 얻을 수 있습니다.
유효한 API 키가 없으면 Farcaster 기능이 작동하지 않습니다.
서버를 빌드하고 시작합니다
npm run build
npm start # For stdio mode (default)
# OR
npm run start:http # For HTTP/SSE mode서버를 빌드하세요
npm run buildAPI 키로 .env 파일이 올바르게 구성되었는지 확인하세요.
서버는 다음 위치에서 .env를 찾습니다.
현재 작업 디렉토리
프로젝트 루트 디렉토리
상위 디렉토리(최대 3단계)
또한 시스템에서 직접 환경 변수를 설정할 수도 있습니다.
Claude Desktop 구성에 서버를 추가하세요.
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"beyond-social": {
"command": "/usr/local/bin/node",
"args": [
"/full/path/to/beyond-mcp-server/dist/index.js",
"--stdio"
]
}
}
}또는 Claude Desktop 구성에서 API 키와 기타 환경 변수를 직접 전달할 수 있습니다( 권장 ):
{
"mcpServers": {
"beyond-social": {
"command": "/usr/local/bin/node",
"args": [
"/full/path/to/beyond-mcp-server/dist/index.js",
"--stdio"
],
"env": {
"NEYNAR_API_KEY": "YOUR_API_KEY_HERE",
"ENABLE_FARCASTER": "true",
"ENABLE_TWITTER": "false"
}
}
}
}데스크톱용 Claude 재시작
social://{platform}/{query}/search - 플랫폼에서 콘텐츠 검색
social://{platform}/user/{userId}/profile - 사용자 프로필 가져오기
social://{platform}/wallet/{walletAddress}/profile - 지갑 주소로 사용자 프로필 가져오기(Farcaster 전용)
social://{platform}/user/{userId}/balance - 사용자의 지갑 잔액을 가져옵니다(Farcaster 전용)
FID(숫자) 또는 사용자 이름을 허용합니다.
사용자 이름이 제공된 경우 잔액을 가져오기 전에 자동으로 FID로 변환됩니다.
social://{platform}/wallet/{walletAddress}/profile - 지갑 주소로 사용자 프로필 가져오기
social://{platform}/user/{userId}/content - 사용자 콘텐츠 가져오기
social://{platform}/thread/{threadId} - 대화 스레드 가져오기
social://{platform}/trending - 트렌드 주제 가져오기
social://{platform}/trending-feed - 다중 공급자 지원을 통해 트렌드 피드 콘텐츠를 받으세요(Farcaster 전용)
지원 공급자: neynar(기본값), openrank, mbd
매개변수: timeWindow(1시간, 6시간, 12시간, 24시간, 7일, 30일), limit
search-content - 소셜 플랫폼에서 콘텐츠 검색
get-user-profile - 사용자 프로필 정보 가져오기
get-user-profile-by-wallet - 지갑 주소를 사용하여 사용자 프로필 가져오기(Farcaster 전용)
get-user-balance - 사용자의 지갑 잔액을 가져옵니다(Farcaster 전용)
FID(숫자) 또는 사용자 이름을 허용합니다.
사용자 이름을 FID로 자동 변환합니다.
get-user-content - 특정 사용자의 콘텐츠 가져오기
get-thread - 대화 스레드 가져오기
get-trending-topics - 현재 인기 있는 주제 가져오기
getTrendingFeed - 다중 공급자 지원을 통해 트렌드 피드 받기(Farcaster 전용)
get-wallet-profile - 지갑 주소 기반 프로필 가져오기
analyze-thread - 소셜 미디어 스레드 분석
summarize-user-activity - 사용자 활동을 요약합니다.
explore-trending-topics - 플랫폼에서 인기 있는 주제 탐색
analyze-search-results - 쿼리에 대한 검색 결과 분석
explore-trending-feed - 다양한 공급업체의 트렌드 피드 콘텐츠 분석
get-wallet-profile - 지갑 주소로 사용자 프로필을 가져오고 분석합니다.
check-user-balance - 사용자의 지갑 잔액 및 보유 자산 분석
FID와 사용자 이름 입력 모두에서 작동합니다.
사용자 이름에 대한 자동 FID 확인을 처리합니다.
새로운 소셜 플랫폼 제공자를 추가하려면:
src/providers/ 에 새 디렉토리를 만듭니다.
ContentProvider 인터페이스를 구현합니다
레지스트리에 공급자 등록
예:
import { ContentProvider } from '../interfaces/provider';
export class MyPlatformProvider implements ContentProvider {
public name = 'myplatform';
public platform = 'myplatform';
// Implement all required methods
}npm run dev # stdio mode
npm run dev:http # HTTP modenpm testnpm run lint
npm run lint:fixMIT
기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.
이 프로젝트의 모든 주요 변경 사항은 이 파일에 기록됩니다.
최초 출시
Neynar API를 통한 Farcaster 통합
MCP 호환 서버 구현
stdio 및 HTTP 모드 모두 지원
지갑 주소로 사용자 프로필을 가져오기 위한 새로운 도구와 리소스가 추가되었습니다.
새로운 테스트 추가됨
ID 또는 사용자 이름을 통해 Farcaster 사용자의 지갑 잔액을 검색하는 기능이 추가되었습니다.
트렌드 피드 콘텐츠에 대한 다중 공급자 지원 구현
추가 사용자 세부 정보가 포함된 향상된 updateUserProfile
신뢰성과 성능을 보장하기 위해 포괄적인 테스트가 추가되었습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Social platform (farcaster, twitter, telegram) | |
| threadId | Yes | Thread or conversation ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of trending items to return (default: 20) | |
| platform | Yes | Social platform (farcaster, twitter, telegram) | |
| provider | No | Provider to use for trending feed (default: neynar) | |
| timeWindow | No | Time window for trending content (default: 24h) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of trending topics to return | |
| platform | Yes | Social platform (farcaster, twitter, telegram) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Social platform (farcaster, twitter, telegram) | |
| userId | Yes | Farcaster ID (FID) or username of the user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of posts to return | |
| platform | Yes | Social platform (farcaster, twitter, telegram) | |
| userId | Yes | User ID or username on the platform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Social platform (farcaster, twitter, telegram) | |
| userId | Yes | User ID or username on the platform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Social platform (farcaster, twitter, telegram) | |
| walletAddress | Yes | Ethereum wallet address (0x...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for multiple channels on a social platform in parallel
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Cursor for pagination | |
| limit | No | Maximum number of results to return per query | |
| platform | Yes | The platform to search on (e.g., 'farcaster') | |
| queries | Yes | Array of search queries |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions parallel execution without detailing rate limits, authentication needs, error handling, or what constitutes a 'channel'. It lacks critical behavioral context for a search operation with multiple queries.
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 unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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 tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error cases, or the implications of parallel execution, leaving significant 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.
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 meaning about parameters beyond implying 'queries' are processed in parallel, which aligns with schema but doesn't enhance understanding of individual 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 ('search for multiple channels') and resource ('channels on a social platform'), with the distinctive feature of parallel execution. However, it doesn't explicitly differentiate from its sibling 'search-channels', which might handle single queries or have different behavior.
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 'search-channels' or other search-related siblings. It mentions parallel execution but doesn't specify scenarios where this is beneficial or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for channels on a social platform
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Cursor for pagination | |
| includeChannels | No | Whether to include channel information in results | |
| limit | No | Maximum number of results to return | |
| platform | Yes | The platform to search on (e.g., 'farcaster') | |
| query | Yes | The search query |
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 mentions 'search' but doesn't specify whether this is a read-only operation, what permissions might be needed, rate limits, or what the response format looks like. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 states the core purpose without unnecessary words. It's appropriately sized for a search tool and front-loaded with essential information, making it easy 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 a search tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, or how results are structured. For a tool that likely returns paginated data with channel information, more context is needed to use it effectively.
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 description adds no parameter-specific information beyond what's already in the schema (which has 100% coverage). It doesn't explain how parameters interact (e.g., how 'platform' affects 'query') or provide usage examples. With high schema coverage, the baseline is 3, but the description doesn't compensate with additional semantic context.
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 ('Search for') and resource ('channels on a social platform'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'search-bulk-channels' or 'search-content', which would require more specificity about what makes this search unique.
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 'search-bulk-channels' or 'search-content'. There's no mention of prerequisites, context, 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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| platform | Yes | Social platform (farcaster, twitter, telegram) | |
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.
v1.0.0get-threadget-trending-feedget-trending-topicsget-user-balanceget-user-contentget-user-profileget-wallet-profilesearch-bulk-channelssearch-channelssearch-contentScored across 10 tools
Most tools have distinct purposes targeting different resources like threads, feeds, topics, user data, and search functions. However, get-user-content and search-content could potentially overlap in purpose if content retrieval is involved, creating minor ambiguity.
All tool names follow a consistent kebab-case pattern with a verb-noun structure, primarily using 'get-' or 'search-' prefixes. This uniformity makes the tool set predictable and easy to parse for an agent.
With 10 tools, the count is well-scoped for a social platform server, covering user interactions, content discovery, and search functionalities. Each tool appears to serve a specific role without redundancy.
The tool set focuses heavily on retrieval and search operations, with no clear tools for creating, updating, or deleting content, users, or channels. This leaves significant gaps in CRUD coverage for a social platform domain, though retrieval functions are well-represented.
A Model Context Protocol server for Wix AI tools
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Model Context Protocol server for Studex tools, notifications, and profile integrations
