MCP server for the Influencers Club API - creator enrichment, discovery, and batch operations
Server has 14 tools with basic schemas and descriptions, but significant gaps limit production readiness. Most tools have descriptions (10 - 50 chars, below the 50 - 200 char baseline for LLM optimization), and input schemas are present but sparse. Parameters lack type constraints (enums, ranges); error handling is minimal; no tool annotations (readOnlyHint, destructiveHint, idempotentHint). Naming is verb-forward (discover_, get_, create_, enrich_) but some tools conflate multiple concerns (discover_creators_to_file mixes discovery + file I/O). Output schemas are not documented in the source. Security: API keys are injected server-side (good), but no audit logging visible. Composition: tools are reasonably single-purpose, but batch operations (create_batch_enrichment, wait_for_upload) are stdio-only and stateful, breaking the stateless request model.
Start a batch enrichment job on uploaded CSV (stdio-only, local tool). First call returns mode menu; second call with chosen mode starts the job
Discover creators matching semantic search, hashtags, keywords, and audience filters across Instagram, YouTube, TikTok, Twitch, Twitter, and OnlyFans
Save discovery results to a CSV file on disk (stdio-only, local tool)
Download the enriched CSV results from a completed batch job (stdio-only, local tool)
Enrich an email address with creator profile data (basic enrichment)
Enrich a creator handle with detailed profile data (raw or full enrichment)
Descriptions are too short (avg 35 - 45 chars vs. baseline 50 - 200 chars). LLMs cannot distinguish between similar tools (discover_creators vs find_similar_creators) or understand when to call each. Add context: 'Discover creators matching semantic search, hashtags, keywords, and audience filters across Instagram, YouTube, TikTok, Twitch, Twitter, and OnlyFans' is good; 'Discover creators' alone is insufficient.
Input schemas lack type constraints (enums, ranges, patterns). 'platform' accepts free-form strings instead of enum(instagram|youtube|tiktok|twitch|twitter|onlyfans). 'sort_by' accepts free-form instead of enum(relevancy|engagement_rate|number_of_followers|growth_rate). LLMs hallucinate invalid values; enums prevent this.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Find creators similar to a given handle on Instagram, YouTube, TikTok, Twitch, or OnlyFans
Get the status and progress of a batch enrichment job (stdio-only, local tool)
Get all connected social media accounts for a creator across 11 platforms
Find creators with overlapping audiences across multiple handles on Instagram, TikTok, or YouTube
Get recent posts/content from a creator on Instagram, TikTok, or YouTube
Get detailed analytics for a specific post (likes, comments, views, engagement rate)
Get the upload page URL for batch CSV file uploads (stdio-only, local tool)
Block until a CSV file is uploaded via the batch upload page (stdio-only, local tool)
No output schemas documented. Tools return data but LLMs cannot plan downstream calls without knowing what fields to expect. E.g., discover_creators returns creators with what fields? (handle, follower_count, engagement_rate, platform, etc.). Document return types for all tools.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Clients cannot determine which tools are safe to retry or which modify state. Mark all read-only tools with readOnlyHint=true; mark write tools (discover_creators_to_file, create_batch_enrichment, download_batch_results) with destructiveHint or idempotentHint as appropriate.
Batch operations (wait_for_upload, create_batch_enrichment, get_batch_status, download_batch_results) are stateful and stdio-only. They rely on local file I/O and blocking waits, breaking the stateless request model. In HTTP mode, these tools cannot work reliably. Redesign: accept file uploads via tool parameters or resource URIs; return job IDs immediately; poll status via separate stateless calls.