一个可扩展的模型上下文协议服务器，提供对社交平台数据和链上数据的标准化访问。目前支持 Farcaster（通过 Neynar API），并带有用于 Twitter 集成的占位符。更多类似 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
您可以从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 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"
]
}
}
}或者，您可以直接在 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 - 获取具有多提供商支持的热门 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 - 分析不同提供商的热门 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麻省理工学院
欢迎贡献代码！欢迎提交 Pull 请求。
该项目的所有显著变化都将记录在此文件中。
初始版本
通过 Neynar API 集成 Farcaster
符合 MCP 的服务器实现
支持 stdio 和 HTTP 模式
添加了新的工具和资源来获取带有钱包地址的用户资料
添加了新测试
增加了通过 ID 或用户名检索 Farcaster 用户钱包余额的功能
实现对热门 feed 内容的多提供商支持
增强了 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
