The Beyond MCP Server provides standardized access to social platform data through an MCP-compliant interface. It currently fully supports Farcaster via Neynar, with placeholder support for Twitter and Telegram.
Key capabilities:
Search content across supported platforms using queries with optional limits
Get user profiles by ID or username on specified platforms
Get user profiles by wallet address (specifically for Farcaster)
Retrieve user content from specified users with customizable limits
Fetch conversation threads using thread IDs
Access trending topics on supported platforms
Get wallet balance for Farcaster users by their FID or username
Fetch trending feed content using multiple providers (for Farcaster)
The server supports multiple transport methods (stdio and HTTP/SSE), formats context for LLM consumption, and can be extended by adding new social platform providers.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Beyond MCP Server search for recent posts about AI on Farcaster"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An extensible Model Context Protocol server that provides standardized access to social platform data and onchain data. Currently supports Farcaster (via Neynar API) with placeholder for Twitter integration. More platforms like Telegram including onchain data will be added soon.
MCP Compliant: Fully implements the Model Context Protocol specification
Multi-Platform: Designed to support multiple social media platforms
Extensible: Easy to add new platform providers
Well-Formatted: Optimized context formatting for LLM consumption
Flexible Transport: Supports both stdio and SSE/HTTP transports
Related MCP server: MCP URL Fetcher
Farcaster: Full implementation via Neynar API
Twitter: Placeholder (not implemented)
Node.js 16+
Neynar API key (for Farcaster access) https://neynar.com/
Clone the repository
git clone https://github.com/yourusername/beyond-mcp-server.git
cd beyond-mcp-serverInstall dependencies
npm installCreate a .env file from the template
cp .env.example .env
# Edit .env with your API keysConfigure your environment variables
Required: Set NEYNAR_API_KEY in your .env file
You can obtain a Neynar API key from https://neynar.com/
Without a valid API key, Farcaster functionality will not work
Build and start the server
npm run build
npm start # For stdio mode (default)
# OR
npm run start:http # For HTTP/SSE modeBuild the server
npm run buildMake sure your .env file is properly configured with your API keys
The server will look for .env in the following locations:
Current working directory
Project root directory
Parent directories (up to 3 levels)
You can also set environment variables directly in your system
Add the server to your Claude Desktop configuration at:
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"
]
}
}
}Alternatively, you can pass the API key and other environment variables directly in the Claude Desktop configuration (recommended):
{
"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"
}
}
}
}Restart Claude for Desktop
social://{platform}/{query}/search - Search content on a platform
social://{platform}/user/{userId}/profile - Get user profile
social://{platform}/wallet/{walletAddress}/profile - Get user profile by wallet address (Farcaster only)
social://{platform}/user/{userId}/balance - Get user's wallet balance (Farcaster only)
Accepts either FID (numeric) or username
If username is provided, automatically converts to FID before fetching balance
social://{platform}/wallet/{walletAddress}/profile - Get user profile by wallet address
social://{platform}/user/{userId}/content - Get user content
social://{platform}/thread/{threadId} - Get conversation thread
social://{platform}/trending - Get trending topics
social://{platform}/trending-feed - Get trending feed content with multi-provider support (Farcaster only)
Supports providers: neynar (default), openrank, mbd
Parameters: timeWindow (1h, 6h, 12h, 24h, 7d, 30d), limit
social://{platform}/channels/search - Search for channels on a platform (Farcaster only)
Parameters: query, limit, cursor
Returns channel details including name, description, follower count, and metadata
social://{platform}/channels/bulk-search - Search for multiple channels in parallel (Farcaster only)
Parameters: queries (array), limit, cursor
Returns results for each query with channel details and pagination info
search-content - Search for content on a social platform
get-user-profile - Get a user's profile information
get-user-profile-by-wallet - Get user profile using wallet address (Farcaster only)
get-user-balance - Get user's wallet balance (Farcaster only)
Accepts either FID (numeric) or username
Automatically handles username to FID conversion
get-user-content - Get content from a specific user
get-thread - Get a conversation thread
get-trending-topics - Get current trending topics
getTrendingFeed - Get trending feed with multi-provider support (Farcaster only)
get-wallet-profile - Get profile based on wallet address
search-channels - Search for channels on a platform (Farcaster only)
Parameters: query, limit, cursor
Returns detailed channel information including follower count and metadata
search-bulk-channels - Search for multiple channels in parallel (Farcaster only)
Parameters: queries (array), limit, cursor
Returns results for each query with channel details and pagination info
analyze-thread - Analyze a social media thread
summarize-user-activity - Summarize a user's activity
explore-trending-topics - Explore trending topics on a platform
analyze-search-results - Analyze search results for a query
explore-trending-feed - Analyze trending feed content across different providers
get-wallet-profile - Get and analyze user profile by wallet address
check-user-balance - Analyze user's wallet balance and holdings
Works with both FID and username inputs
Handles automatic FID resolution for usernames
explore-channels - Analyze and explore channels on a platform
Provides insights about channel popularity and content
Helps discover relevant channels based on search criteria
explore-bulk-channels - Analyze and compare multiple channels in parallel
Efficiently searches and compares multiple channels
Provides insights about channel relationships and trends
To add a new social platform provider:
Create a new directory in src/providers/
Implement the ContentProvider interface
Register the provider in the registry
Example:
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
Contributions are welcome! Please feel free to submit a Pull Request.
All notable changes to this project will be documented in this file.
Initial release
Farcaster integration via Neynar API
MCP compliant server implementation
Support for both stdio and HTTP modes
Added new tools and resource to fetch user profile with wallet address
Added new tests
Added functionality to retrieve wallet balances of Farcaster users via ID or username
Implemented multi-provider support for trending feed content
Enhanced updateUserProfile with additional user details
Added comprehensive tests to ensure reliability and performance
Add support to fetch Single and Bulk farcaster channel information
| 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. Dates show when Glama detected each change.
v1.0.0get-threadget-trending-feedget-trending-topicsget-user-balanceget-user-contentget-user-profileget-wallet-profilesearch-bulk-channelssearch-channelssearch-contentMost 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Beyond-Network-AI/beyond-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
