Why your LinkedIn MCP server is slow
Short answer: it is driving a headless browser. Every question you ask becomes a real LinkedIn page load, rendered and scrolled and parsed, before anything can be answered. That is where the minute goes. A server built on an authenticated session API answers the same question in about a second.
Where the minute goes
Most LinkedIn MCP servers on GitHub work by automating a browser. Here is what happens when your agent asks one to read a profile.
- Start a headless browser, or wake the one that is idling.
- Load the session cookie and navigate to the profile URL.
- Wait for LinkedIn's application to boot and render. This is a heavy page.
- Scroll, because experience, skills, and recent activity load only when they scroll into view.
- Wait again for each of those sections.
- Parse the rendered HTML into fields.
Steps three through five are the cost, and none of them belong to the server. It is waiting on LinkedIn's front end, which was built for a person reading one profile rather than for a program reading forty.
What the numbers look like
| Operation | Browser-driven | Session API |
|---|---|---|
| Read one profile | 30 to 60 seconds | About 1 second |
| Search and return 10 people | Minutes | A few seconds |
| Draft one message from a profile | A minute or more | About 6 seconds |
| First call after idle | Add browser startup | No change |
The six seconds includes a model call, which is most of it. The LinkedIn read inside it is the fast part.
Why this breaks the agent loop
Latency compounds because agents chain calls. "Find ten founders in New York and draft a note for each" is not one call. It is a search, ten profile reads, ten post reads, and ten drafts.
At forty seconds a call that is over twenty minutes of waiting, and most MCP clients give up long before it finishes. What you see is a timeout, or a partial result, or a model that decides to work from what it already has and invents the rest. At six seconds the same request completes in a few minutes and stays a conversation.
There is a second cost that is easy to miss. Slow tools change how you use the agent. You stop asking follow-up questions. You batch things you would rather do one at a time. The tool trains you to want less from it.
Measure your own
- Ask your agent to read one specific profile URL. Time it from your Enter key to the first real fact appearing.
- Do it three times. The first call carries browser startup, so it is not representative.
- Now ask for ten profiles in one request. Note whether it finishes, times out, or comes back with fewer than ten and no explanation.
- Ask for something that needs a fresh read of a post from this week. Cached servers are fast until the answer has to be current.
Step three is the one that tells you the most. A server that is merely slow is annoying. A server that silently returns six of ten is a correctness problem.
Questions people ask next
Can a browser-driven server be made fast?
Not really. Keeping a browser warm saves startup and caching saves repeat reads. The page load is the floor and the server does not control it. Going faster means not loading a page, which means a different architecture.
Is caching a fix?
It trades the problem for a worse one. The reason to read LinkedIn from an agent is that the data is current. A cached profile makes a draft reference a job someone left, and that mistake is more expensive than waiting.
Does speed have anything to do with account safety?
They are separate. Safety is about how much you send and how repetitive it is, and both are set by your limits rather than by your latency. A fast server does not push you to send more, because sending still waits for your approval.
What makes a session API fast?
It asks LinkedIn's own backend for the data and gets structured fields back. There is no page, no rendering, no scrolling, and no HTML to parse. It is the difference between reading a database row and photographing a screen.
Why do so many servers use a browser anyway?
Because it is the only route that is free. A browser and a session cookie need no partnership and no provider. That is a reasonable trade for a weekend project. It stops being reasonable when the agent is doing daily work.
How Iridium does it
Iridium never loads a LinkedIn page. Connectivity is brokered by Unipile, which holds the authenticated session you create and exposes it as an API. Reads come back as structured fields.
A typical tool call returns in about six seconds, and most of that is the model writing the draft. Latency is recorded on every call, so the number comes from instrumentation rather than a guess. The practical effect is that you can ask a follow-up question and get an answer while you are still thinking about the first one.
Six seconds, not a minute
7-day free trial. No credit card. Cancel anytime.
Start free → Compare the access routes