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., "@remote-mcp-linkedin extract LinkedIn profile for Jane Smith"
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.
Read-only MCP server for collecting visible LinkedIn profile, post, and contact-network data and turning profile data into structured dossiers. It uses a local browser bridge, so the browser session stays on the user's machine.
Opens visible LinkedIn profile pages through a local browser bridge
Extracts basic public / visible profile data
Collects visible profile posts from /recent-activity/all/
Searches visible people/contact-network results, defaulting to 1st-degree contacts
Builds a structured dossier for AI agents
Exposes the result through MCP tools
Related MCP server: Real Browser MCP
linkedin_profile_get - returns normalized visible profile data
linkedin_profile_posts - returns visible posts from a profile activity page
linkedin_contact_network_search - returns visible people-search/contact results
linkedin_profile_dossier - returns a structured profile dossier with evidence, gaps, warnings, and confidence
Read-only by design
No messages, likes, comments, connection requests, or job actions
No cookies or browser session data are exported
The browser runs locally
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -e ".[dev]"
export REMOTE_MCP_LINKEDIN_BRIDGE_TOKEN="replace-with-a-long-random-token"
remote-mcp-linkedin-server
remote-mcp-linkedin-bridgeSmall prototype.
Working:
MCP server
local bridge
profile data tool
profile posts tool
contact network search tool
dossier tool
JSON result storage
Not ready:
robust LinkedIn parser
production extraction
advanced profile analysis
MIT
Build a deterministic structured dossier from visible profile sections.
| Name | Required | Description | Default |
|---|---|---|---|
| username | No | ||
| profile_url | No | ||
| include_posts | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and openWorldHint. Description adds 'deterministic structured dossier' which implies consistency beyond what annotations provide. No contradictions.
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?
Single sentence, front-loaded, but too brief. Leaves out critical parameter explanations and usage context. Appropriate length but incomplete.
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?
Three parameters with no schema coverage, one sibling tool. Description lacks details on dossier contents, parameter selection logic, and output structure despite having an output schema.
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 0%, but description adds no meaning to parameters. Does not explain the purpose of 'username', 'profile_url', or 'include_posts'.
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?
Clearly states it builds a structured dossier from visible profile sections. Specific verb and resource, but does not explicitly differentiate from sibling 'linkedin_profile_get'.
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 on when to use this tool vs alternatives. The description does not mention when to use it over 'linkedin_profile_get' or any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return normalized raw visible profile sections via the local bridge.
| Name | Required | Description | Default |
|---|---|---|---|
| sections | No | ||
| username | No | ||
| profile_url | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds context by mentioning 'via the local bridge' and 'normalized raw visible profile sections'. However, it does not explain what 'normalized raw' means or disclose any limitations like rate limits or privacy considerations.
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 concise sentence that front-loads the main action. It is efficient but slightly lacking in completeness. A score of 4 reflects good conciseness with minimal waste.
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 presence of an output schema and three parameters with zero description, the description is too brief to provide adequate context. It fails to explain how to invoke the tool, what the output schema contains, or how it relates to the sibling 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 input schema has zero description coverage for its three parameters, and the tool description does not mention or explain any of them. The agent receives no help understanding how to use 'sections', 'username', or 'profile_url' beyond their names and types.
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 'Return' and the resource 'normalized raw visible profile sections via the local bridge'. It distinguishes from the sibling tool 'linkedin_profile_dossier' by specifying that it returns sections rather than a full dossier.
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 the sibling 'linkedin_profile_dossier' or any other alternatives. There are no prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: one produces a structured dossier, the other returns raw profile sections. There is no ambiguity about which to use for a given task.
Both tools share the 'linkedin_profile_' prefix, but one uses a noun ('dossier') and the other a verb ('get'), which is inconsistent. A consistent verb-noun pattern would be clearer.
With only two tools, the server feels thin for a platform as broad as LinkedIn. However, the tools are well-focused on profile data, so the count is borderline reasonable for that narrow scope.
The server covers only profile retrieval in two formats, missing many common LinkedIn operations like searching, messaging, or managing connections. This is a significant gap for general LinkedIn usage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for LinkedIn: 31 tools for profiles, search, messaging, posts, enrichment.
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
Live LinkedIn data for AI agents: profiles, companies, jobs, posts, email finding. No account risk.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/alexanderskorokhodov/remote-mcp-linkedin'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
