Social Media Monitoring MCP Server - BrandWatch Alternative. Provides keyword-based monitoring across Twitter, Reddit, and Meta platforms with sentiment analysis and analytics.
This server has critical gaps in schema documentation, parameter descriptions, and error handling. While tool names follow verb_noun convention (monitor_keywords, get_analytics, export_data, setup_scheduled_monitoring), the actual implementation details are not visible in the provided source code, only configuration files and a chart script are shown. The tool descriptions are present but generic (10-50 chars), and parameter schemas lack detail. Most parameters have descriptions but no explicit type constraints or validation guidance. No output schemas are documented. Error handling is not evident. The server is STDIO-only, which is a hard cap at 50 for protocol readiness but does not directly impact definition quality scoring.
Output schemas are completely undocumented. No tool declares what fields it returns, field types, or structure. LLMs cannot plan downstream calls or parse responses reliably.
Parameter descriptions are generic and under-specified. 'keywords' described as 'Comma-separated list of keywords to monitor' lacks guidance on max length, format, special chars, or examples. 'interval_minutes' in setup_scheduled_monitoring has no min/max bounds stated, could accept -1 or 999999.
No enum constraints for platforms parameter. 'Comma-separated platforms (twitter,reddit,meta)' is a comment in parentheses, not a formal enum. LLMs will hallucinate invalid platforms like 'facebook', 'tiktok', 'linkedin'.
Convert parameter descriptions to formal constraints. For 'keywords': describe as 'Comma-separated list of 1-10 keywords, 3-50 chars each, alphanumeric + spaces/hyphens only'. For 'interval_minutes': add 'Range: 5-1440 (5 min to 24 hours)'.
Define 'platforms' as an enum: {type: 'string', enum: ['twitter', 'reddit', 'meta']} in the input schema. Repeat the enum in the description: 'One or more platforms: twitter, reddit, meta (comma-separated).'
Expand tool descriptions to 100-150 chars. For get_analytics: 'Retrieve aggregated statistics and trends for monitored keywords over a specified period. Call this after monitor_keywords to analyze engagement, sentiment, and reach. Supports filtering by keyword or platform.'
Document setup_scheduled_monitoring as idempotent or provide a cancel_scheduled_monitoring tool. State: 'Creating a session with the same name and parameters overwrites the prior session (idempotent). Retrying a failed creation is safe.'
Add error handling examples in tool descriptions. For monitor_keywords: 'Returns 400 with list of invalid platforms if unknown platforms supplied. Returns 429 with retry-after header if rate-limited; wait before retrying.'
No error handling or recovery guidance documented. What happens if a social media API key is missing? If a keyword triggers rate limiting? If the database write fails? LLMs have no retry strategy.
setup_scheduled_monitoring is a state-mutating (WRITE) tool but description says nothing about side effects, idempotency, or confirmation. Agents cannot know if retrying a failed call will create duplicate sessions.
Tool descriptions are too brief (30-50 chars). 'Get analytics for monitored data' and 'Monitor social media platforms for specific keywords' lack context on WHEN to use each tool, WHAT the output means, or WHAT prerequisites exist (do keywords need to exist from monitor_keywords first?).
No tool provides pagination or result-limiting guidance. monitor_keywords accepts 'max_results' but no description of what happens if thousands of results match, response could blow the context window.
Parameter 'format_type' in export_data uses free-form string 'csv or json' instead of an enum. LLMs will try 'xlsx', 'parquet', 'yaml'.
export_data
Implement pagination for monitor_keywords. Accept 'limit' (default 50, max 100) and 'offset' params. Return {results: [...], total_count: 1234, next_offset: 50} so agents can loop safely without blowing context window.
Change 'format_type' parameter to enum: {type: 'string', enum: ['csv', 'json']}. Update description: 'Output format (csv or json). CSV includes headers; JSON returns array of objects.'
Document which tools are read-only vs write. Add to setup_scheduled_monitoring description: '[WRITE] Creates or overwrites a monitoring session. Intended to run once; retries are safe if the session name and parameters are unchanged.'
Add composition hints. For get_analytics description: 'Requires keywords to exist from a prior monitor_keywords call. Filtering by 'keyword' parameter is optional but recommended to avoid expensive cross-platform aggregations.'
Provide actionable defaults. For days parameter in get_analytics: 'Defaults to 7 days (last week). Accepted range: 1-365. Larger ranges may timeout on sparse data.'
Validate and document parameter relationships. If export_data with keyword='foo' requires that keyword to have been monitored first, state: 'The keyword must have been monitored in a prior monitor_keywords or setup_scheduled_monitoring call; unmonitored keywords will export empty results.'