ソーシャルプラットフォームデータとオンチェーンデータへの標準化されたアクセスを提供する、拡張可能なモデルコンテキストプロトコルサーバーです。現在、Twitter統合用のプレースホルダーを備えたFarcaster（Neynar API経由）をサポートしています。Telegramなどのオンチェーンデータを含む他のプラットフォームにも近日中に追加される予定です。
MCP準拠: モデルコンテキストプロトコル仕様を完全に実装
マルチプラットフォーム: 複数のソーシャルメディアプラットフォームをサポートするように設計されています
拡張可能: 新しいプラットフォームプロバイダーを簡単に追加できます
適切にフォーマット: LLM の使用に最適化されたコンテキスト フォーマット
柔軟なトランスポート: stdio と SSE/HTTP トランスポートの両方をサポート
Related MCP server: MCP URL Fetcher
Farcaster : Neynar API を介した完全な実装
Twitter : プレースホルダー（実装されていません）
Node.js 16以上
Neynar API キー (Farcaster アクセス用) https://neynar.com/
リポジトリをクローンする
git clone https://github.com/yourusername/beyond-mcp-server.git
cd beyond-mcp-server依存関係をインストールする
npm installテンプレートから.envファイルを作成する
cp .env.example .env
# Edit .env with your API keys環境変数を設定する
必須: .env ファイルにNEYNAR_API_KEYを設定する
Neynar APIキーはhttps://neynar.com/から取得できます。
有効なAPIキーがないと、Farcasterの機能は動作しません
サーバーを構築して起動する
npm run build
npm start # For stdio mode (default)
# OR
npm run start:http # For HTTP/SSE modeサーバーを構築する
npm run build.env ファイルが API キーで適切に設定されていることを確認してください
サーバーは次の場所で .env を検索します。
現在の作業ディレクトリ
プロジェクトのルートディレクトリ
親ディレクトリ（最大3レベル）
システム内で直接環境変数を設定することもできます
次の場所で、Claude Desktop 構成にサーバーを追加します。
macOS: ~/ライブラリ/アプリケーションサポート/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"
]
}
}
}あるいは、API キーとその他の環境変数を Claude Desktop 構成で直接渡すこともできます (推奨)。
{
"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 (1h、6h、12h、24h、7d、30d)、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:fixマサチューセッツ工科大学
貢献を歓迎します！お気軽にプルリクエストを送信してください。
このプロジェクトに対するすべての注目すべき変更はこのファイルに記録されます。
初回リリース
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
