SocialRouter MCP Server

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:

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

run parameters

Typical flow

1. list_services with platform: "linkedin" → see what LinkedIn data is available, in what shape, and at what price.

2. run with service: "linkedin/profile.info" and inputs: ["https://www.linkedin.com/in/..."].

3. Read served_by in the result to know which offer answered.

Environment Variables

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