Un servidor extensible de Protocolo de Contexto de Modelo (MPP) que proporciona acceso estandarizado a datos de plataformas sociales y datos en cadena. Actualmente es compatible con Farcaster (mediante la API de Neynar) con un marcador de posición para la integración con Twitter. Próximamente se añadirán más plataformas como Telegram que incluyen datos en cadena.
Compatible con MCP : implementa completamente la especificación del Protocolo de contexto de modelo
Multiplataforma : diseñado para admitir múltiples plataformas de redes sociales.
Extensible : Fácil de agregar nuevos proveedores de plataforma
Bien formateado : formato de contexto optimizado para el consumo de LLM
Transporte flexible : admite transportes stdio y SSE/HTTP
Related MCP server: MCP URL Fetcher
Farcaster : implementación completa a través de la API de Neynar
Twitter : Marcador de posición (no implementado)
Node.js 16+
Clave API de Neynar (para acceso a Farcaster) https://neynar.com/
Clonar el repositorio
git clone https://github.com/yourusername/beyond-mcp-server.git
cd beyond-mcp-serverInstalar dependencias
npm installCrea un archivo .env a partir de la plantilla
cp .env.example .env
# Edit .env with your API keysConfigurar sus variables de entorno
Obligatorio : Establezca NEYNAR_API_KEY en su archivo .env
Puede obtener una clave API de Neynar en https://neynar.com/
Sin una clave API válida, la funcionalidad de Farcaster no funcionará
Construir e iniciar el servidor
npm run build
npm start # For stdio mode (default)
# OR
npm run start:http # For HTTP/SSE modeConstruir el servidor
npm run buildAsegúrese de que su archivo .env esté configurado correctamente con sus claves API
El servidor buscará .env en las siguientes ubicaciones:
Directorio de trabajo actual
Directorio raíz del proyecto
Directorios principales (hasta 3 niveles)
También puede configurar variables de entorno directamente en su sistema
Agregue el servidor a su configuración de Claude Desktop en:
macOS: ~/Biblioteca/Soporte de aplicaciones/Claude/claude_desktop_config.json
Ventanas: %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"
]
}
}
}Alternativamente, puede pasar la clave API y otras variables de entorno directamente en la configuración de Claude Desktop ( recomendado ):
{
"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"
}
}
}
}Reiniciar Claude para escritorio
social://{platform}/{query}/search - Buscar contenido en una plataforma
social://{platform}/user/{userId}/profile - Obtener el perfil del usuario
social://{platform}/wallet/{walletAddress}/profile - Obtener el perfil del usuario por dirección de billetera (solo Farcaster)
social://{platform}/user/{userId}/balance - Obtener el saldo de la billetera del usuario (solo Farcaster)
Acepta FID (numérico) o nombre de usuario
Si se proporciona el nombre de usuario, se convierte automáticamente a FID antes de obtener el saldo
social://{platform}/wallet/{walletAddress}/profile - Obtener el perfil del usuario por dirección de billetera
social://{platform}/user/{userId}/content - Obtener contenido del usuario
social://{platform}/thread/{threadId} - Obtener el hilo de conversación
social://{platform}/trending - Obtenga temas de tendencia
social://{platform}/trending-feed - Obtén contenido de feed de tendencias con soporte para múltiples proveedores (solo Farcaster)
Proveedores compatibles: neynar (predeterminado), openrank, mbd
Parámetros: timeWindow (1h, 6h, 12h, 24h, 7d, 30d), límite
search-content - Busca contenido en una plataforma social
get-user-profile - Obtener la información del perfil de un usuario
get-user-profile-by-wallet : obtiene el perfil del usuario usando la dirección de la billetera (solo Farcaster)
get-user-balance : obtiene el saldo de la billetera del usuario (solo Farcaster)
Acepta FID (numérico) o nombre de usuario
Maneja automáticamente la conversión de nombre de usuario a FID
get-user-content - Obtener contenido de un usuario específico
get-thread - Obtener un hilo de conversación
get-trending-topics - Obtenga información sobre temas de tendencia actuales
getTrendingFeed : obtén noticias de tendencias con soporte para múltiples proveedores (solo Farcaster)
get-wallet-profile - Obtener perfil según la dirección de la billetera
analyze-thread - Analizar un hilo de redes sociales
summarize-user-activity - Resumir la actividad de un usuario
explore-trending-topics : explora temas de tendencia en una plataforma
analyze-search-results : analizar los resultados de búsqueda de una consulta
explore-trending-feed : analiza el contenido de tendencias de diferentes proveedores
get-wallet-profile : obtiene y analiza el perfil del usuario por dirección de billetera
check-user-balance : analiza el saldo y las tenencias de la billetera del usuario
Funciona con entradas de FID y nombre de usuario
Maneja la resolución automática de FID para nombres de usuario
Para agregar un nuevo proveedor de plataforma social:
Crea un nuevo directorio en src/providers/
Implementar la interfaz ContentProvider
Registrar al proveedor en el registro
Ejemplo:
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:fixInstituto Tecnológico de Massachusetts (MIT)
¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.
Todos los cambios notables en este proyecto se documentarán en este archivo.
Lanzamiento inicial
Integración de Farcaster a través de la API de Neynar
Implementación de servidor compatible con MCP
Compatibilidad con los modos stdio y HTTP
Se agregaron nuevas herramientas y recursos para obtener el perfil del usuario con la dirección de la billetera.
Se agregaron nuevas pruebas
Se agregó funcionalidad para recuperar los saldos de la billetera de los usuarios de Farcaster mediante ID o nombre de usuario
Se implementó la compatibilidad con múltiples proveedores para el contenido de tendencias del feed.
Actualización mejorada de UserProfile con detalles de usuario adicionales
Se agregaron pruebas integrales para garantizar la confiabilidad y el rendimiento.
| 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
