What can you do with this server?

The SocialRouter MCP Server enables LLM agents to extract social media data and run query-driven searches through a unified API, along with account management. * Extract social media data (extract): Pull data from supported platforms (LinkedIn, Instagram, X, Reddit, Facebook, TikTok, YouTube, Pinterest, Bluesky, Snapchat, Google Maps) via single or batch URLs, with configurable result limits and explicit provider selection or automatic routing. Supported extraction types include: * post.likes – Users who liked a post * post.comments – Comments on a post * profile.info – Profile information * profile.posts – Posts from a profile * profile.followers – Followers of a profile * Perform query-driven searches: Conduct searches (e.g., Google Maps place searches) with per-query record limits and optional provider fallback. * List available providers (list_providers): View all data extraction providers and their operational status. * Get provider details: Access detailed information and pricing for a specific provider. * Retrieve past results (get_extraction): Fetch results of a previously performed extraction or search by its unique ID. * Check credit balance (get_balance): Monitor your SocialRouter account's current credit balance. * View usage summary: Get a breakdown of data usage by provider and platform.

Which integrations are available for this server?

Extracts social media data from Instagram, including likes, comments, profile info, posts, and followers via the SocialRouter API. Extracts social media data from Reddit, including likes, comments, profile info, posts, and followers via the SocialRouter API.

How do I use SocialRouter MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SocialRouter MCP Server extract profile info for https://linkedin.com/in/janedoe" 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.

de en es ja ko ru zh

SocialRouter MCP Server

Official

by socialrouter

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

An MCP server that exposes the SocialRouter API to LLM agents. Plug it into Claude Desktop, Claude Code, Cursor, or any MCP-compatible client to let the agent fetch social media data through a single unified API.

Supported platforms include LinkedIn, Instagram, X, Reddit, Facebook, TikTok, YouTube, Pinterest, Bluesky, Snapchat, and Google Maps.

Configuration

Get an API key at socialrouter.io, then wire the server into your client. Step-by-step guides, with the config paths and the verification step for each host:

Client	Guide
Claude Code	docs.socialrouter.io/mcp/claude-code
Claude Desktop	docs.socialrouter.io/mcp/claude-desktop
Cursor	docs.socialrouter.io/mcp/cursor
Codex CLI	docs.socialrouter.io/mcp/codex
VS Code	docs.socialrouter.io/mcp/vscode
Gemini CLI	docs.socialrouter.io/mcp/gemini-cli
Anything else	docs.socialrouter.io/mcp/other-clients

Claude Code

claude mcp add socialrouter --scope user \
  --env SOCIALROUTER_API_KEY=sr_live_xxxxxxxxxxxxx \
  -- npx -y @socialrouter/mcp

Claude Desktop

Open the Claude menu in the system menu bar → Settings… → Developer → Edit Config. That opens (or creates) claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "socialrouter": {
      "command": "npx",
      "args": ["-y", "@socialrouter/mcp"],
      "env": {
        "SOCIALROUTER_API_KEY": "sr_live_xxxxxxxxxxxxx"
      }
    }
  }
}

Quit Claude Desktop completely and reopen it, then check the + button in the chat box → Connectors → Manage connectors.

Cursor

Add the same mcpServers block to ~/.cursor/mcp.json (or .cursor/mcp.json in a project), then enable the server from Cursor's MCP settings.

Related MCP server: @b2b-saas-inc/olli-mcp-server

How it works

The server is a thin, stateless wrapper over the API, built around services of the form <platform>/<service> (e.g. linkedin/profile.info, reddit/subreddit.posts). The agent discovers what exists with list_services, then calls run with the chosen service and its inputs. The MCP does no URL detection and no routing — picking the right service is the agent's job, and the catalog gives it everything it needs: the input kind (URLs or free-text queries), the accepted URL shapes with concrete examples, the typed options, and the offers behind the service with their price and batch cap.

Which offer serves a run (apify/harshmaur, brightdata/reddit…) is the router's call: it walks the failover chain, cheapest first, and the response's served_by says which one answered. An agent can pin one with provider, but pinning disables failover — omitting it is the better default.

Every call is validated against the live catalog (GET /v1/services) before the request is sent:

the service parameter is an enum of the services live at startup, so the agent cannot invent one;
at call time the service is re-checked against the refreshed catalog (5-minute TTL), the batch size against the relevant cap (the pinned offer's, or the largest in the chain), and a pinned offer against the ones that actually serve that service;
validation failures return corrective errors listing the valid alternatives instead of a bare 4xx.

The catalog is fetched once at startup — if it cannot be loaded the server exits, since an unreachable catalog means the API itself is unreachable — and refreshed lazily afterwards; if a refresh fails, the last known catalog keeps being served.

Tools

Tool	Description
`list_services`	One row per live `<platform>/<service>`: input kind, accepted input shapes with examples, typed options, and the offers behind it (failover order, price per record, batch cap). Filter by `platform` and/or `service`.
`run`	Run a service over one or more inputs (URLs or queries, per the service's input kind).
`get_extraction`	Retrieve a past run by ID.
`get_account`	Credit balance + usage summary (by offer and platform) over the last N days.

`run` parameters

Param	Description
`service`	Required. `<platform>/<service>` slug from `list_services`, e.g. `reddit/subreddit.posts`.
`inputs`	Required. URLs (url-kind services) or search queries (query-kind services), all for the service's platform.
`provider`	Optional, advanced. Pin one offer, e.g. `apify/harshmaur`. Disables failover.
`limit`	Optional. Max records to return (default 100, max 250).
`options`	Optional. Typed options declared by the service (see `options` in `list_services`). Unknown keys are rejected with a corrective error.

Typical flow

list_services with platform: "linkedin" → see what LinkedIn data is available, in what shape, and at what price.
run with service: "linkedin/profile.info" and inputs: ["https://www.linkedin.com/in/..."].
Read served_by in the result to know which offer answered.

Environment Variables

Variable	Required	Default
`SOCIALROUTER_API_KEY`	yes	—
`SOCIALROUTER_BASE_URL`	no	`https://api.socialrouter.io`

Create a key at socialrouter.io/dashboard/keys. If the key is missing, invalid or revoked, the server says so and points there — at startup on stderr, and in the tool result if the key is rejected while running.

License

MIT

Available Tools

4 tools

extractExtract social dataA

Extract data from a social media URL (LinkedIn, Instagram, X, Reddit). Pick the extraction type matching the URL kind.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The full URL of the social media content
`type`	Yes	What to extract from the URL
`limit`	No	Maximum number of results to return (default 100)
`provider`	No	Optional provider override (e.g. 'lobstr', 'apify'). Omit to let SocialRouter route automatically.

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It briefly mentions extraction types and provider override but lacks disclosure of behavioral aspects like rate limits, authentication requirements, error handling, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence front-loaded with the tool's purpose. Every word is necessary; no redundancy. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description covers core action and parameter usage but omits details on error behavior, pagination, and rate limits. With no output schema and no annotations, more context would be beneficial for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all parameters. The description adds meaningful context beyond the schema: guiding selection of 'type' based on URL kind, and explaining the 'provider' parameter's automatic routing behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'extract', resource 'social media data from a social media URL', and lists supported platforms (LinkedIn, Instagram, X, Reddit). Distinct from sibling tools which handle balance, extraction status, and provider listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage by instructing to 'Pick the extraction type matching the URL kind' but does not provide explicit when-to-use or when-not-to-use guidance, nor contrasts with siblings. No exclusionary criteria are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_balanceGet balanceA

Check your SocialRouter credit balance

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description honestly indicates a read operation ('check'), but does not disclose return format or potential costs, though still adequate for a trivial tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no unnecessary words; highly concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple balance check with no parameters or output schema, the description provides sufficient context about the action and resource, though could hint at return format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%; baseline score of 3 applies as description adds no parameter info, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action ('check') and the resource ('SocialRouter credit balance'), and distinguishes from sibling tools which are about extraction and providers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs. alternatives, but the simple context and distinct sibling names imply its use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_extractionGet extractionA

Get the result of a previous extraction by its ID

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The extraction ID (e.g., ext_abc123)

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. States it is a read operation without side effects, but lacks details on potential states (e.g., extraction still processing), authentication needs, or rate limits. Adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence of 10 words with no redundant information. Front-loaded with verb and resource. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple retrieval tool with one parameter and no output schema, the description is sufficient. It explains what the tool does and what input is needed. Could mention the return value but is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the parameter. The description adds no new meaning beyond 'by its ID', which is redundant. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the verb 'get', the resource 'result of a previous extraction', and the method 'by its ID'. Distinguishes from siblings like 'extract' (which likely creates an extraction) and 'get_balance' (unrelated).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies the tool is used after an extraction has been created (by referencing 'previous extraction'). Provides clear context but does not explicitly state when not to use it or name alternatives like 'extract'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_providersList providersB

List all available data extraction providers and their status

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral traits. It implies a read-only listing but does not explicitly state safety, side effects, or limitations like rate limits. Minimal behavioral context is provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence. It is front-loaded but could provide slightly more detail about 'status' without adding verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations or output schema, the description adequately explains the tool's purpose. However, it lacks detail on output format and fails to guide the agent on how to interpret results, leaving some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage. The description adds no parameter information beyond the schema, which is sufficient. Baseline of 4 for zero parameters applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all available data extraction providers and their status, with a specific verb and resource. It distinguishes itself from sibling tools (extract, get_balance, get_extraction) by indicating it is a listing operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. The description does not mention context, prerequisites, or exclusions, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Apr 27, 2026
- First observedextract
- First observedget_balance
- First observedget_extraction
- First observedlist_providers

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-04-27 15:10 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: extract performs extraction, get_balance checks credits, get_extraction retrieves past results, and list_providers shows available providers. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores (extract, get_balance, get_extraction, list_providers). No mixing of conventions.

Tool Count5/5

Four tools are well-scoped for a focused data extraction service. The count is neither too few to be useful nor too many to manage, covering core operations efficiently.

Completeness4/5

The tool surface covers extraction, result retrieval, provider listing, and balance checking. Minor gaps exist (e.g., no cancellation or batch retrieval), but core workflows are supported.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

glim.sh A
sh.glim
Give your agent live data from Twitter, Reddit, the web and GitHub. No API keys, no scraping stack.
Browser Automation Social Media Version Control
1434
allOAuth
io.veezee
Real-time LinkedIn, X (Twitter) and Reddit data for AI agents. Free key, self-minted, no signup.
Social Media Search
2
ChirpieOAuth
io.github.Firefloco
Post, schedule, and track social posts on X, Bluesky, LinkedIn, Instagram and more from AI agents.
Social Media App Automation
1
Social Media Search API — Twitter, Instagram, Reddit, TikTok (XPOZ)AOAuth
ai.xpoz
Twitter/X, Instagram, Reddit & TikTok data for AI agents. Billions of posts. No API keys.
Research & Data Social Media Web Scraping
52412

Related MCP Servers

LinkedIn MCP Server
Social Media Communication
ahmedselimmansor-ctrl
F
license
A
quality
D
maintenance
Enables LLMs and agents to interact with LinkedIn's REST API for managing profiles, creating posts, viewing connections, and overseeing organizations.
Updated 4 months ago (2026-05-16 03:58 UTC)
5
2
-
@b2b-saas-inc/olli-mcp-server
Social Media Marketing
B2B-Saas-Inc
A
license
C
quality
D
maintenance
Lets LLMs manage social media presence via olli.social API, with tools for campaigns, drafts, analytics, and more.
Updated 5 months ago (2026-04-28 17:21 UTC)
100
8 npm
MIT
Publora MVP MCP Server
Social Media App Automation
paisabrazilfl-cpu
F
license
Not graded
quality
C
maintenance
Enables AI agents to create, schedule, and manage social media posts across 10 platforms via a unified API.
Updated 2 months ago (2026-06-30 21:19 UTC)
-
scraper-api-mcp
bitterdev
A
license
B
quality
B
maintenance
Enables AI assistants to access structured public web data (profiles, posts, videos, etc.) from social networks and directories via natural language, by forwarding tool calls to the scraper-api.com API.
Updated 2 months ago (2026-07-23 09:29 UTC)
84
6 npm
MIT

SocialRouter MCP Server

Configuration

Claude Code

Claude Desktop

Cursor

How it works

Tools

run parameters

Typical flow

Environment Variables

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`run` parameters