LinkedIn MCP Server: Live LinkedIn Data for Hermes

Hermes speaks MCP, so you add LinkedIn data by pointing it at a LinkedIn MCP server, not by writing a scraper. AnyAPI is one HTTP MCP endpoint that exposes LinkedIn profiles, companies, employees, jobs, and email lookup behind one key, with no LinkedIn account, priced in USD per 1k. It's one mcp_servers block in config.yaml plus a /reload-mcp.
You gave your Hermes agent web search, and it still can't answer "who's the head of eng at Stripe, and what's their background." Generic web tools hand back pages, not structured LinkedIn records.
There are three ways to get that data, and in 2026 two of them are shut to a normal builder: the official LinkedIn API is partner-gated, DIY scraping is a maintenance treadmill that 401s, and the API most people reached for is gone.
So here's the fix. An MCP server turns LinkedIn into a tool your agent calls, with nothing to keep alive.
What Hermes can and can't do out of the box
Hermes ships with a set of built-in tools, and none of them return a typed LinkedIn record. The default set is generic: web search, a browser, vision, and text-to-speech. It can read a LinkedIn page it's allowed to load. It can't hand you a company or a person as structured fields.
That gap matters for the job you're actually doing. A web search returns a ranked list of pages. Your agent then has to open each one, guess which is the right person, and parse whatever HTML LinkedIn served that day. That's brittle, and it burns tokens on the parts a structured record already solved.
The distinction is between reading a page and getting data. A structured record hands you the name, the location, the follower count, and the profile text as fields you can branch on. A page is a blob you hope contains them. Hermes ships the blob-reading tools; it doesn't ship the record.
The supported way to add the record is MCP. Hermes is MCP-native by design: you connect it to external tool servers to reach "internal APIs without writing native Hermes tools," per the Hermes docs. You don't fork Hermes or write a plugin. You point it at a server.
So the question isn't "can Hermes scrape LinkedIn." It's which LinkedIn MCP server you plug in.
What happened to the LinkedIn API
There are three ways to get LinkedIn data, and by 2026 two of them are closed to a normal builder. Here's each one, and why it fails for the job you're doing.
The official LinkedIn API is partner-gated. There's no self-serve endpoint that returns a profile or a company on demand. You apply to a program (Marketing, Talent, or Sales), wait for approval, and even then you get campaign and account data scoped to that program, not arbitrary profile lookups. For an agent that needs to read any public profile, the developer portal is a dead end before you write a line of code.
DIY scraping is a treadmill. You point a script at a profile URL, and it works for a handful of calls. Then LinkedIn serves an auth wall, a checkpoint, or a login redirect, and your script stops and returns a 401. Now you're rotating accounts, buying proxies just to read public pages, and re-patching the parser every time the markup shifts. That's ongoing work, not a one-time integration, and it's work you own forever.
Proxycurl, the LinkedIn data API most people reached for, shut down in July 2025 after LinkedIn sued it. The company ran at roughly $10M ARR. LinkedIn filed suit in January 2025 over fake accounts scraping non-public data, and the founder closed the business rather than fight a multi-billion-dollar company, per Social Media Today and the founder's goodbye post.
That's why people came looking for a LinkedIn MCP server and a Proxycurl alternative. The tool a lot of people built on vanished, and their agents need a maintained replacement they can call the same way.
- 2021Public API tightening: profile/company data pulled behind partner programs
- Apr 2022hiQ v LinkedIn: scraping public data ruled not a CFAA violation
- Jan 2025LinkedIn sues Proxycurl over fake accounts scraping non-public data
- Jul 2025Proxycurl shuts down rather than fight
How to connect a LinkedIn MCP server to Hermes in 3 steps
One HTTP endpoint, one config block, one reload. Here's the exact thing I run to give a Hermes agent live LinkedIn data.
Step 1. Get a key. Sign up at getanyapi.com and grab an API key. You pay per request in USD with no subscription, so a profile lookup costs what it costs and nothing sits on a monthly bill. If the agent needs to provision its own key with no human in the loop, agent self-signup does that too.
Step 2. Add the MCP server to Hermes. Drop this block into ~/.hermes/config.yaml:
mcp_servers:
anyapi:
url: "https://api.getanyapi.com/mcp"
headers:
Authorization: "Bearer ${ANYAPI_KEY}"
tools:
include: [search_apis, run_api]Then run /reload-mcp in the Hermes chat to load it. That's it: it's one config block and a reload, not a scraper you maintain. This is HTTP transport, so there's no local process to babysit, unlike the stdio OSS servers that make you keep an npx command or a Docker container alive in the background. The Hermes MCP guide covers the same steps if you want their reference.
Same connection, three clients:
# ~/.hermes/config.yaml
mcp_servers:
anyapi:
url: "https://api.getanyapi.com/mcp"
headers:
Authorization: "Bearer ${ANYAPI_KEY}"
tools:
include: [search_apis, run_api]claude mcp add anyapi --transport http https://api.getanyapi.com/mcp --header "Authorization: Bearer $ANYAPI_KEY"{
"mcpServers": {
"anyapi": {
"url": "https://api.getanyapi.com/mcp"
}
}
}Step 3. Ask in natural language. Now you just talk to the agent. Point Hermes at a LinkedIn profile URL and it calls mcp_anyapi_search_apis to find the right endpoint, then mcp_anyapi_run_api with linkedin.profile to fetch it. Hermes prefixes MCP tools as mcp_<server>_<tool>, so your anyapi server's tools show up under that name. I pointed an agent at my own profile to try it, and here's the trimmed record that came back:
{
"found": true,
"data": {
"name": "Kevin Wang",
"location": "New York City Metropolitan Area",
"followers": 340,
"about": null,
"avatarUrl": "https://media.licdn.com/..."
}
}Your agent gets fields it can reason over, not a page it has to read. No LinkedIn login, no session to warm up, no captcha to clear.

What LinkedIn data can you pull?
The catalog exposes LinkedIn as typed endpoints your agent calls by name. Here's the set and what each one returns:
| Endpoint | What it returns | USD / 1k |
|---|---|---|
linkedin.profile | Profile summary: name, location, followers, about, avatar | $16.25 |
linkedin.company | Company overview | $2.00 |
linkedin.company_employees | Employees at a company | $100 |
linkedin.search_profiles | People search by title, company, or keyword | $206 |
linkedin.jobs | Job listings | $8.80 |
linkedin.post / linkedin.search_posts | A single post and post search | $2.00 |
linkedin.email | Work-email finder from a profile | $0.70 |
linkedin.ads | LinkedIn ad library | $30.05 |
One key, one bill, all in USD. The schema is normalized across providers, and where a SKU has more than one provider the gateway fails over automatically, so the record shape your agent parses stays the same. A linkedin.profile call returns the same fields today and next month, which means the code that reads data.followers doesn't break under you.
Live pricing sits on /catalog, so check there for the current numbers and the full input schema per endpoint.

Beyond LinkedIn: one MCP server, 200+ APIs
The LinkedIn endpoints aren't a one-off. The same config block and the same two tools, mcp_anyapi_search_apis and mcp_anyapi_run_api, give your Hermes agent the rest of the catalog: Reddit, TikTok, YouTube, plus company and people enrichment. You don't add a new server per platform or juggle a second key. The agent asks what's available, picks the endpoint, and runs it, and every result comes back as a normalized record in USD.
That's the point of pointing an agent at one MCP endpoint instead of a pile of scrapers: it grows without you rewiring anything. Browse the full set on /catalog, or read the MCP server reference for the tool details.
LinkedIn MCP server options, compared
Search "linkedin mcp server" and you'll find three kinds of results. None of them is a maintained, read-only data source you can point at any profile or company at scale. Here's what each one actually is, stated plainly.
The first kind is community OSS servers, like stickerdaniel/linkedin-mcp-server. These are single-purpose and free. You clone the repo, run it yourself, and patch it when LinkedIn changes its markup or auth and the server stops returning data. That maintenance is now yours.
The second kind is connector platforms like Composio. These OAuth into your own LinkedIn account so your agent can act as you: post, comment, read your own feed and activity. That's a different job from pulling structured records across many profiles you don't own. It needs your account, and it's built for account actions, not bulk data.
The third kind is the official LinkedIn API. It's partner-gated. You apply to a program, wait for approval, and even then you don't get on-demand profile and company data for arbitrary people.
| Option | Maintained for you? | Read-only data at scale? | No LinkedIn account? | USD per request? | Many endpoints, one key? | Any MCP client? |
|---|---|---|---|---|---|---|
| Community OSS LinkedIn MCP | No, you patch it | Breaks under load | Yes | Free | One endpoint | Any client |
| Composio (account actions) | Yes | No, account actions | Needs your account | Subscription | Many apps | Any client |
| Official LinkedIn API | Yes | Partner-gated | Needs approved app | No public price | Limited | n/a |
| AnyAPI | Yes | Yes | Yes | Yes | Yes | Yes |
I'll name the tradeoff instead of pretending there isn't one. AnyAPI is paid per request. If all you do is read your own single account now and then, a free OSS server or Composio may be enough, and you don't need to pay anyone.
It changes once you need scale. If you need reliable structured data across many profiles or companies without watching a scraper fall over, that's the case AnyAPI is for. The OSS servers are free until LinkedIn changes something and they break; a maintained endpoint is the one thing on this list you don't have to fix yourself.
Frequently asked questions
Does LinkedIn have an API?
Yes, but it's partner-gated. You apply to the Marketing, Talent, or Sales programs and wait for approval, and even then you don't get on-demand profile or company data for arbitrary people.
Is the LinkedIn API free?
The official partner APIs have no public self-serve free tier; you need an approved application. Data-API access like this one is pay-per-use in USD, with no subscription.
What happened to Proxycurl?
It shut down in July 2025 after LinkedIn's lawsuit. Existing integrations had to migrate to another LinkedIn data source, which is why people started hunting for a Proxycurl alternative.
What's the best Proxycurl alternative?
A maintained LinkedIn data API you can call over MCP. It should cover profile, company, employee, and job data without asking you to run and patch a scraper. That's the gap AnyAPI fills.
Is there a free LinkedIn MCP server?
Yes, community OSS ones exist. They're single-purpose and free, and you maintain them yourself when LinkedIn changes and they stop returning data. That's the tradeoff for the zero price.
Can I use this LinkedIn MCP server with Claude or Cursor too?
Yes. It's the same HTTP MCP endpoint, so it's one mcp add line in Claude Code or Cursor. The config section above has the exact command for each client.
Do I need a LinkedIn account or login?
No. You call the endpoint with an AnyAPI key, not LinkedIn credentials. There's no account to connect and no session to keep alive.
How much does LinkedIn data cost?
Per request, in USD. A profile lookup runs about $0.016 each; other endpoints vary by type. See the catalog for live pricing on every endpoint.
Can my Hermes agent get LinkedIn data autonomously?
Yes. It runs unattended and calls the tools on its own, and a key with a spend cap bounds what it can cost. No human has to paste anything mid-run.
What LinkedIn data can I get?
Profiles, companies, employees, people search, jobs, posts, work-email lookup, and the ad library. Each is a typed endpoint your agent calls by name.
Will this break like a scraper?
It's maintained upstream, with schema normalization and automatic fallback. If a source shifts, the fix happens behind the endpoint, so your agent config and your parser don't change.
AnyAPI handles compliance routing, and you're responsible for lawful use of the data you pull (acceptable use).