The SociaVault MCP Server enables AI assistants to query social media data across 7 major platforms using natural language commands and a single interface. It requires a SociaVault API key and works with Claude Desktop, Cline, and other MCP-compatible clients.
Platform Capabilities:
Instagram: Profile data (followers, bio, posts count, verification) and recent posts with engagement metrics
TikTok: Profile information (followers, likes, bio, videos count) and recent videos with views, likes, shares
Twitter/X: Profile data (followers, bio, tweets count) and recent tweets with engagement metrics
Threads: Profile information (followers, bio, posts count) and recent posts with likes, replies
YouTube: Channel data including subscribers, videos count, and description
Facebook: Profile/page data (followers, likes, about information) by providing the URL
Reddit: Subreddit posts with upvotes and comments
Key Benefits:
Access multiple platforms through a unified interface without manually interacting with individual platform APIs
Query data using simple natural language commands
Retrieve profile information, content, and engagement metrics across all supported platforms
Retrieves Facebook profile and page data including followers, likes, and about information
Fetches Instagram profile data (followers, bio, verification status) and recent posts with engagement metrics (likes, comments, media)
Retrieves Reddit subreddit posts with upvotes and comments data
Accesses Threads profile data (followers, bio, posts count) and recent posts with likes and replies
Fetches TikTok profile data (followers, likes, bio, videos count) and recent videos with views, likes, and shares
Retrieves YouTube channel data including subscribers, video count, and channel description
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., "@SociaVault MCP Server get the latest tweets from @OpenAI"
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.
Give your AI assistant live access to social media data. This Model Context Protocol server lets Claude, Cursor, Cline, VS Code, and any MCP-compatible client pull real-time data from 11 platforms — profiles, posts, comments, transcripts, search, trends, and ad libraries — through natural language.
Powered by SociaVault — a reliable social media data API for developers.
107 tools across TikTok, Instagram, YouTube, Twitter/X, LinkedIn, Facebook, Reddit, Threads, Pinterest, Twitch, and Google.
Ad library coverage — TikTok, Meta (Facebook/Instagram), Google, and LinkedIn ad libraries for competitor research.
Zero install — runs via npx, no global install needed.
Token-efficient — responses are trimmed by default to keep your context window lean.
Built on the modern MCP SDK (1.x) with typed inputs, structured output, and clear error messages.
Related MCP server: twitter-mcp
Sign up at sociavault.com — new accounts get free credits to start. Copy your key (format sk_live_…) from the dashboard.
The server runs with npx, so there's nothing to install. Just add the config below and set your API key.
Edit your config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"sociavault": {
"command": "npx",
"args": ["-y", "sociavault-mcp"],
"env": {
"SOCIAVAULT_API_KEY": "sk_live_your_key_here"
}
}
}
}Restart Claude Desktop.
Add to ~/.cursor/mcp.json (global) or .cursor/mcp.json (per-project):
{
"mcpServers": {
"sociavault": {
"command": "npx",
"args": ["-y", "sociavault-mcp"],
"env": { "SOCIAVAULT_API_KEY": "sk_live_your_key_here" }
}
}
}Add to .vscode/mcp.json:
{
"servers": {
"sociavault": {
"command": "npx",
"args": ["-y", "sociavault-mcp"],
"env": { "SOCIAVAULT_API_KEY": "sk_live_your_key_here" }
}
}
}Any client that supports stdio MCP servers works — point it at the command npx -y sociavault-mcp with SOCIAVAULT_API_KEY in the environment.
Environment variable | Required | Description |
| Yes | Your SociaVault API key ( |
| No | Override the API base URL. Defaults to |
Once configured, ask your assistant things like:
"Get the TikTok profile and last 20 videos for @charlidamelio."
"Search the Meta Ad Library for active ads from Nike in the US."
"Pull the transcript of this YouTube video: ."
"What's trending on TikTok in the US right now?"
"Find Instagram reels using this audio id and summarize the top performers."
"Search Reddit for mentions of my product in the last week."
"Get the comments on this tweet and summarize the sentiment."
All tools are read-only. Most accept a trim flag (default true) that returns a smaller, AI-friendly payload; set trim: false for the full raw response. List endpoints accept a pagination cursor returned in the previous response.
tiktok_profile, tiktok_demographics, tiktok_videos, tiktok_video_info, tiktok_transcript, tiktok_live, tiktok_comments, tiktok_comment_replies, tiktok_following, tiktok_followers, tiktok_search_users, tiktok_search_hashtag, tiktok_search_keyword, tiktok_search_music, tiktok_search_top, tiktok_music_popular, tiktok_music_details, tiktok_music_videos, tiktok_trending, tiktok_creators_popular, tiktok_videos_popular, tiktok_hashtags_popular
tiktok_shop_products, tiktok_shop_product_details, tiktok_shop_search, tiktok_shop_product_reviews
tiktok_ad_library_search, tiktok_ad_library_ad
instagram_profile, instagram_posts, instagram_post_info, instagram_transcript, instagram_comments, instagram_reels, instagram_highlights, instagram_highlight_detail, instagram_reels_by_song
youtube_channel, youtube_channel_videos, youtube_channel_shorts, youtube_video, youtube_video_transcript, youtube_search, youtube_search_hashtag, youtube_video_comments, youtube_video_comment_replies, youtube_shorts_trending, youtube_channel_playlists, youtube_channel_lives, youtube_channel_community_posts
twitter_profile, twitter_user_tweets, twitter_user_tweets_all, twitter_tweet, twitter_tweet_transcript, twitter_comments, twitter_quotes, twitter_retweets, twitter_search, twitter_followers, twitter_followings, twitter_community, twitter_community_tweets
linkedin_profile, linkedin_company, linkedin_post
linkedin_ad_library_search, linkedin_ad_library_ad_details
facebook_profile, facebook_profile_posts, facebook_comment_replies, facebook_profile_reels, facebook_group_posts, facebook_post, facebook_post_transcript, facebook_post_comments
facebook_ad_library_ad_details, facebook_ad_library_search, facebook_ad_library_company_ads, facebook_ad_library_search_companies
facebook_marketplace_location_search, facebook_marketplace_search, facebook_marketplace_item
google_search, google_ad_library_company_ads, google_ad_library_ad_details, google_ad_library_search_advertisers
reddit_subreddit_details, reddit_subreddit, reddit_subreddit_search, reddit_post_comments, reddit_post_transcript, reddit_search
threads_profile, threads_user_posts, threads_post, threads_search, threads_search_users
pinterest_search, pinterest_pin, pinterest_user_boards, pinterest_board
twitch_profile, twitch_user_videos, twitch_user_schedule, twitch_clip
check_credits — check your remaining credit balance.
The MCP server is free and open source. You only pay for the SociaVault API usage it makes, billed as credits (each API call costs credits depending on the endpoint).
Free — credits included on signup, no card required.
Credit packs — Starter ($29), Growth ($79), Pro ($199), and Enterprise ($399), each granting a larger bundle of credits.
Credits don't expire on a monthly cycle — you buy a pack and draw it down. See the current packs and credit amounts at sociavault.com/pricing, and check your balance any time with the check_credits tool.
"Missing SOCIAVAULT_API_KEY" — Add your key to the env block of the MCP config and restart the client.
"Authentication failed (401)" — Your key is wrong or expired, or it's not in the sk_live_… format. Generate a fresh one in the dashboard.
"Out of credits (402)" — Top up at sociavault.com/pricing.
"Not found (404)" — The handle/URL is wrong, or the account/content is private or deleted.
Server not showing up — Make sure Node.js 18+ is installed and on your PATH, confirm the JSON config is valid, and fully restart the client. Most clients have an MCP log panel that shows startup errors.
git clone https://github.com/olamide-olaniyan/sociavault-mcp.git
cd sociavault-mcp
npm install
npm run build
# Run locally
SOCIAVAULT_API_KEY=sk_live_your_key node dist/index.jsAdding a new endpoint is a single entry in src/endpoints.ts — the server registers every entry automatically.
Website: sociavault.com
API docs: docs.sociavault.com
Support: support@sociavault.com
MIT — see LICENSE.
Get Facebook profile/page data
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Facebook profile or page URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't describe traits like whether authentication is required, rate limits, error handling, or what the output format might be (e.g., JSON with specific fields). For a tool with no annotations, this is a significant gap in transparency.
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 extremely concise with a single sentence 'Get Facebook profile/page data'. It is front-loaded and wastes no words, making it easy to parse. Every word earns its place by specifying the action and target, though it could benefit from more detail.
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 tool's complexity (a data retrieval tool for a social media platform), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what data is returned, any limitations (e.g., public data only), or behavioral aspects. This leaves the agent with insufficient context to use the tool 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 input schema has 100% description coverage, with the single parameter 'url' documented as 'Facebook profile or page URL'. The description adds no additional meaning beyond this, such as URL format examples or validation rules. According to the rules, with high schema coverage, the baseline is 3 even without param info in the 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?
The description 'Get Facebook profile/page data' states a verb ('Get') and resource ('Facebook profile/page data'), making the purpose understandable. However, it's vague about what specific data is retrieved (e.g., basic info, posts, followers) and doesn't differentiate from sibling tools like 'get_instagram_profile' beyond the platform name. This is minimal but not specific enough for a higher score.
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. It doesn't mention any prerequisites, context for use (e.g., for social media analysis), or exclusions (e.g., not for private profiles). With multiple sibling tools for different platforms, this lack of differentiation leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Instagram posts from a user
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | Instagram username |
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 but offers minimal information. It states what the tool does ('Get Instagram posts') but doesn't describe how it behaves—e.g., whether it requires authentication, has rate limits, returns recent or all posts, includes metadata, or handles errors. This leaves significant gaps for a tool that likely interacts with an external API.
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 extremely concise and front-loaded with a single, clear sentence that directly states the tool's function. There is no wasted language or unnecessary elaboration, making it efficient and easy to parse, though this conciseness comes at the cost of completeness in other dimensions.
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 interacting with Instagram's API (implied by the tool's function) and the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like authentication needs, rate limits, or return format, which are critical for effective tool use. The description alone is insufficient for an agent to understand the full context of invoking this tool.
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 the input schema provides. Since schema description coverage is 100% (the 'handle' parameter is documented as 'Instagram username'), the baseline score of 3 applies. The description doesn't elaborate on parameter usage, such as format requirements or examples, but the schema adequately covers the essentials.
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 tool's purpose with a specific verb ('Get') and resource ('Instagram posts from a user'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_instagram_profile' or 'get_threads_posts', which would require mentioning it retrieves posts specifically rather than profile information or content from other platforms.
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. It doesn't mention sibling tools like 'get_instagram_profile' for profile data instead of posts, or 'get_threads_posts' for similar content from a different platform. There are no explicit when/when-not instructions or prerequisites, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Instagram profile data
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | Instagram username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Get Instagram profile data' implies a read-only operation but doesn't specify authentication requirements, rate limits, data freshness, or what happens with invalid handles. For a tool accessing external APIs with no annotation coverage, this leaves significant behavioral questions unanswered.
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 extremely concise at just four words, front-loading the essential purpose with zero wasted words. Every word earns its place, making it immediately scannable and understandable despite its brevity.
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 no annotations, no output schema, and accessing external social media data, the description is insufficiently complete. It doesn't explain what profile data is returned (basic info, statistics, media), authentication needs, rate limits, or error handling. The context signals show this is a simple single-parameter tool, but the external API nature requires more disclosure than provided.
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 input schema has 100% description coverage with 'handle' clearly documented as 'Instagram username'. The description doesn't add any parameter semantics beyond what the schema provides (no format examples, character limits, or validation rules). With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
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 'Get Instagram profile data' clearly states the verb ('Get') and resource ('Instagram profile data'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'get_instagram_posts' which also retrieves Instagram data, nor does it specify what aspects of a profile are retrieved (bio, followers, etc.).
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. With siblings like 'get_instagram_posts' and 'get_tiktok_profile' available, there's no indication whether this is for basic profile info versus posts, or how it differs from other social media profile tools. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Reddit subreddit posts
| Name | Required | Description | Default |
|---|---|---|---|
| subreddit | Yes | Subreddit name (without r/) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get' implies a read operation, but doesn't specify any behavioral traits such as rate limits, authentication needs, pagination, or what happens on errors. For a tool with no annotation coverage, this is a significant gap in transparency.
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 extremely concise with just three words, front-loading the key action and resource. There is no wasted language or redundancy, making it efficient and easy to parse, though this brevity contributes to gaps in other dimensions.
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 tool's complexity (a read operation with one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'posts' entails (e.g., format, limits, sorting) or any behavioral aspects, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.
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 input schema has 100% description coverage, with the parameter 'subreddit' documented as 'Subreddit name (without r/)'. The description adds no additional meaning beyond this, as it doesn't elaborate on parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
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 'Get Reddit subreddit posts' clearly states the verb ('Get') and resource ('Reddit subreddit posts'), making the purpose understandable. However, it lacks specificity about what 'posts' means (e.g., recent, top, all) and doesn't differentiate from sibling tools like 'get_twitter_tweets' beyond platform naming. This makes it vague in scope but not tautological or misleading.
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. It doesn't mention any context, prerequisites, or exclusions, and with sibling tools for other social media platforms, there's no indication of when Reddit-specific retrieval is appropriate. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get posts from a Threads user
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | Threads username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It states what the tool does but doesn't cover critical aspects like whether it's read-only, rate limits, authentication needs, pagination, error handling, or what format the posts are returned in. For a tool with zero annotation coverage, this is inadequate.
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 with zero wasted words. It's front-loaded with the core functionality ('Get posts from a Threads user'), making it immediately clear. Every word earns its place, achieving optimal conciseness.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'posts' entail (e.g., content, metadata, media), how many are returned, or any behavioral traits. For a tool that likely involves network calls and data retrieval, more context is needed to guide the agent 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%, with the single parameter 'handle' documented as 'Threads username'. The description adds no additional parameter semantics beyond what the schema provides (e.g., format examples, validation rules). The baseline score of 3 is appropriate since the schema does the heavy lifting.
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 verb ('Get') and resource ('posts from a Threads user'), making the purpose immediately understandable. It distinguishes from siblings like 'get_threads_profile' which retrieves profile information rather than posts. However, it doesn't specify scope (e.g., recent posts, all posts) which prevents a perfect score.
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?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, limitations, or comparisons to sibling tools like 'get_threads_profile' for profile data or 'get_instagram_posts' for similar functionality on another platform. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Threads profile data
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | Threads username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Get') without any details on permissions, rate limits, response format, or error handling. For a read operation with zero annotation coverage, this lacks critical behavioral context, though it doesn't contradict annotations.
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 extremely concise—a single phrase with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. This minimalism is efficient for a simple tool, though it may sacrifice detail.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what data is returned (e.g., profile fields, structure) or any behavioral traits. For a tool with one parameter but no structured output information, more context is needed to guide the agent 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 input schema has 100% description coverage, with the 'handle' parameter documented as 'Threads username'. The description adds no additional meaning beyond this, such as format examples or validation rules. With high schema coverage, the baseline score of 3 is appropriate, as the schema already provides adequate parameter semantics.
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 'Get Threads profile data' clearly states the action (get) and resource (Threads profile data), but it's vague about what specific data is retrieved. It distinguishes from siblings like get_threads_posts (which gets posts) but doesn't specify if it returns basic info, stats, or full profile details, leaving the purpose somewhat ambiguous.
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. It doesn't mention prerequisites (e.g., needing a valid handle), exclusions, or comparisons to siblings like get_facebook_profile or get_twitter_profile, leaving the agent to infer usage context 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.
Get TikTok profile data
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | TikTok username |
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 states it 'gets' data, implying a read-only operation, but doesn't specify authentication needs, rate limits, error conditions, or what the return data looks like (e.g., JSON structure). This is a significant gap for a tool with no annotation coverage.
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 with zero wasted words. It's front-loaded and appropriately sized for a simple tool, earning full marks for conciseness.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what profile data is returned (e.g., bio, follower count), potential errors, or behavioral traits. For a tool with no structured support, this leaves critical gaps for an AI agent.
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 input schema has 100% description coverage, with the 'handle' parameter documented as 'TikTok username'. The description adds no additional meaning beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.
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 'Get TikTok profile data' clearly states the action (get) and resource (TikTok profile data), but it's vague about what specific data is retrieved and doesn't distinguish it from sibling tools like get_tiktok_videos. It's a minimal but functional purpose statement.
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 get_tiktok_videos or other profile tools (e.g., get_instagram_profile). There's no mention of prerequisites, context, or exclusions, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get TikTok videos from a user
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | TikTok username |
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 states the action but doesn't describe traits like whether this is a read-only operation, rate limits, authentication needs, or what the output format might be. This leaves significant gaps for an agent to understand how to invoke it correctly.
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 with no wasted words. It is appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
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 lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like safety, performance, or return values, which are crucial for an agent to use this tool effectively in a social media context with potential complexities.
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 input schema has 100% description coverage, with the single parameter 'handle' documented as 'TikTok username'. The description adds no additional meaning beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.
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 verb 'Get' and the resource 'TikTok videos from a user', making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'get_tiktok_profile', which might retrieve user metadata instead of videos, leaving room for ambiguity.
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?
No guidance is provided on when to use this tool versus alternatives like 'get_tiktok_profile' or other social media tools. The description implies usage for TikTok videos but lacks context on prerequisites, limitations, or comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Twitter/X profile data
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | Twitter username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about authentication requirements, rate limits, error handling, response format, or whether it's a read-only operation. For a tool with zero annotation coverage, this is inadequate.
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 extremely concise at just three words, front-loading the essential information with zero wasted words. It efficiently communicates the core purpose without unnecessary elaboration.
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 no annotations and no output schema, the description is insufficiently complete. It doesn't explain what data is returned, authentication needs, rate limits, or error conditions. For a tool that presumably makes external API calls, this leaves critical operational context undocumented.
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%, with the single parameter 'handle' clearly documented as 'Twitter username' in the schema. The description adds no additional parameter information beyond what the schema provides, which is acceptable given the high schema coverage but doesn't enhance understanding.
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 verb ('Get') and resource ('Twitter/X profile data'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_twitter_tweets' or other social media profile tools, which would require more specificity for a perfect score.
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. With sibling tools like 'get_twitter_tweets' and other social media profile tools available, there's no indication of when this is the appropriate choice or what distinguishes it from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get tweets from a Twitter/X user
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | Twitter username |
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 but offers minimal insight. It implies a read operation ('Get') but doesn't specify whether it's safe, if it requires authentication, what the return format is, or any constraints like rate limits or data recency. This leaves significant gaps for an agent to understand how the tool behaves.
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, clear sentence with no wasted words, making it highly concise and front-loaded. It directly communicates the core function without unnecessary elaboration, which is efficient for an agent's quick understanding.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'tweets' are returned (e.g., count, format, or fields), any behavioral traits like pagination or errors, or how it integrates with sibling tools. Given the complexity of social media data retrieval, more context is needed for effective use.
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 input schema has 100% description coverage, with the 'handle' parameter documented as 'Twitter username'. The description adds no additional semantic context beyond this, such as format examples (e.g., '@username' or plain 'username') or usage notes. Given the high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
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 ('Get tweets') and target resource ('from a Twitter/X user'), making the purpose understandable. It distinguishes from sibling tools like 'get_twitter_profile' by focusing on tweets rather than profile data. However, it lacks specificity about what 'get' entails (e.g., recent tweets, all tweets, or a limited set).
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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), limitations (e.g., rate limits or data availability), or how it differs from similar tools like 'get_instagram_posts' or 'get_threads_posts' in terms of functionality or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get YouTube channel data
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | YouTube channel handle or @username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get YouTube channel data' implies a read-only operation but doesn't specify if it requires authentication, rate limits, error handling, or what the output format might be. This is a significant gap for a tool with no annotation coverage.
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 with no wasted words. It's front-loaded and to the point, though it could benefit from more detail to improve clarity and completeness.
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 retrieving YouTube channel data, the lack of annotations, and no output schema, the description is incomplete. It doesn't explain what data is returned, potential limitations, or behavioral aspects, making it inadequate for effective tool use.
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 input schema has 100% description coverage, with the parameter 'handle' documented as 'YouTube channel handle or @username'. The description adds no additional meaning beyond this, as it doesn't elaborate on parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate.
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 'Get YouTube channel data' states a clear verb ('Get') and resource ('YouTube channel data'), which is better than a tautology. However, it's vague about what specific data is retrieved (e.g., metadata, videos, statistics) and doesn't distinguish from sibling tools like get_facebook_profile or get_tiktok_profile beyond the platform name. This leaves the purpose somewhat ambiguous.
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. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools (e.g., for social media data retrieval). This lack of guidance makes it unclear when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose targeting specific social media platforms and data types (profiles vs. posts/videos). There is no ambiguity—get_facebook_profile, get_instagram_posts, get_reddit_subreddit, etc., are all uniquely scoped by platform and resource.
All tools follow a consistent verb_noun pattern with 'get_' prefix, platform name, and resource type (e.g., get_facebook_profile, get_instagram_posts). The naming is perfectly predictable and uniform across all 11 tools.
With 11 tools covering multiple social media platforms (Facebook, Instagram, Reddit, Threads, TikTok, Twitter/X, YouTube), the count is well-scoped and appropriate. Each tool earns its place by addressing a distinct data retrieval need without bloat.
The toolset provides comprehensive read-only coverage for profile and post/video data across major social platforms, with no obvious gaps for its retrieval-focused domain. A minor gap is the lack of tools for creating or updating content, but this aligns with a data-fetching server purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Get social media data from Instagram and TikTok: profiles, posts, videos, comments, and more.
Query your Minter.io social media analytics: Instagram, TikTok, X, Facebook, LinkedIn, Threads.
Social media data: 85 tools across 11 platforms (YouTube, TikTok, Instagram, X & more), one key.
Unified social-media data across 10 networks: profiles, posts, search, comments, cross-search.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/olamide-olaniyan/sociavault-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
