Which integrations are available for this server?

Provides LinkedIn professional profile and activity data to GitHub Copilot, enabling AI assistants to read profile sections, activity, and recent changes.

How do I use Unlinked?

1. Click on "Install 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., "@Unlinked show me my LinkedIn profile" 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.

Unlinked

by larsbaunwall

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Unlinked

Bring your LinkedIn professional profile into AI assistants — without copy-pasting, scraping, or guessing.

Unlinked is a TypeScript MCP server that connects your LinkedIn professional profile and experience to any Model Context Protocol client — Claude Desktop, GitHub Copilot, and others. It reads your data directly from LinkedIn's official Member Data Portability API, so your assistant always has accurate, up-to-date context about who you are professionally.

:eu: EEA / Switzerland only. LinkedIn's Member Data Portability API is currently available exclusively to members located in the European Economic Area and Switzerland. Thank you, Digital Markets Act (DMA)!

What it does

Once connected, your AI assistant can:

Read your full professional profile — positions, education, skills, certifications, projects, languages, honours, publications, patents, and more
Fetch any specific LinkedIn data domain by name
Poll for recent profile changes via the LinkedIn changelog API
Diagnose authorization status so you can quickly identify consent or permission issues

All data access is read-only. Your access token is used only to talk to LinkedIn and is never stored, logged, or echoed back.

Related MCP server: linkedit-mcp

Prerequisites

Node.js 22+
A LinkedIn Developer app with the Member Data Portability API (Member) product enabled (follow this guide)
A member access token from the LinkedIn OAuth Token Generator (requires EEA/Switzerland membership)

Setup

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "unlinked": {
      "command": "npx",
      "args": ["-y", "@larsbaunwall/unlinked"],
      "env": {
        "LINKEDIN_TOKEN": "<your_access_token>"
      }
    }
  }
}

The config file is typically at:

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

GitHub Copilot (VS Code)

Add to your user-level MCP config (File → Preferences → MCP Servers) or a workspace .vscode/mcp.json:

{
  "servers": {
    "unlinked": {
      "command": "npx",
      "args": ["-y", "@larsbaunwall/unlinked"],
      "env": {
        "LINKEDIN_TOKEN": "<your_access_token>"
      }
    }
  }
}

Tools

Tool	Description
`linkedin_get_profile`	Get the user's LinkedIn résumé: bio, work history, education, skills, certifications, projects, etc.
`linkedin_get_activity`	Get the user's LinkedIn activity: connections, posts, articles, comments, likes, job applications
`linkedin_get_section`	Get raw data for one specific LinkedIn section by exact name
`linkedin_get_recent_changes`	Get recent changes to the user's LinkedIn data (past 28 days), with cursor-based polling
`linkedin_check_access`	Check whether the user has granted LinkedIn data access — useful for diagnosing missing data

Configuration

Environment variable	Required	Description
`LINKEDIN_TOKEN`	Yes	LinkedIn access token. Accepts `Bearer <token>` or a bare token.
`LINKEDIN_API_VERSION`	No	API version in `YYYYMM` format. Defaults to `202312`.

Development

npm install
npm run build
npm run dev        # run directly from source with .env
npm run inspect    # test with MCP Inspector

See AGENTS.md for implementation guidance.

License

MIT

Available Tools

5 tools

linkedin_check_accessCheck LinkedIn accessA

Read-onlyIdempotent

Check whether the user has granted LinkedIn data access to this app. Use to diagnose missing data or 403 errors before retrying other tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description reinforces these by stating it checks access without mutation, and adds context about error diagnosis, which is valuable beyond annotations.

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?

Two short sentences, front-loaded with purpose, no waste. Each sentence earns its place.

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

Completeness5/5

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

For a simple no-parameter tool, the description covers purpose and use case completely, even without an output schema.

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 tool has 0 parameters and schema coverage is 100%, so the description adds no parameter details, which is acceptable. Baseline for 0 params is 4.

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 'Check whether the user has granted LinkedIn data access to this app.' This is a specific verb+resource, and it distinguishes from siblings (which retrieve data) by focusing on access diagnosis.

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

Usage Guidelines5/5

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

The description explicitly tells when to use: 'Use to diagnose missing data or 403 errors before retrying other tools.' This provides clear context and exclusions.

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

linkedin_get_activityGet LinkedIn activityA

Read-onlyIdempotent

Get the user's LinkedIn social activity: connections, posts, articles, comments, likes, job applications, saved jobs, and job-search preferences. Use for questions about their network, content, or job search. Prefer specific sections — these can be large.

ParametersJSON Schema

Name	Required	Description	Default
`domains`	No	Sections to include. CONNECTIONS (network), MEMBER_SHARE_INFO (posts), ARTICLES (published articles), ALL_COMMENTS, ALL_LIKES, JOB_APPLICATIONS, JOB_POSTINGS (jobs they posted), SAVED_JOBS, JOB_SEEKER_PREFERENCES.
`maxPagesPerDomain`	No	Max pages of results to fetch (1–25). Each page holds ~10 records. Lower this to keep responses small.

Output Schema

ParametersJSON Schema

Name	Required	Description
`domains`	Yes	Records grouped by section name (e.g. POSITIONS, EDUCATION). Each value is the list of items in that section.
`metadata`	Yes	Per-section fetch stats. Check truncated to detect partial results.
`apiVersion`	Yes	LinkedIn API version used for the request.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate read-only, open-world, idempotent, non-destructive. The description adds that the response can be large and suggests limiting scope via specific sections. 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.

Conciseness5/5

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

Two concise sentences: first states purpose and enumerates activity types, second provides usage guidance and a caveat. No filler, front-loaded, every sentence 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?

Covers purpose, usage, and a size warning. Output schema handles return value descriptions. Lacks mention of authentication or rate limits, but annotations cover safety. Very complete for an activity tool with rich schema.

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% with detailed explanations for each parameter (e.g., enum values for domains, range for maxPagesPerDomain). The description does not repeat schema but adds a meta-hint to prefer specific sections. Baseline 3 is appropriate.

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 gets the user's LinkedIn social activity, enumerating specific categories (connections, posts, etc.) and usage context ('Use for questions about their network, content, or job search'). It distinguishes from siblings like linkedin_get_profile and linkedin_get_section by focusing on aggregate activity.

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?

Provides clear usage context: 'Use for questions about their network, content, or job search.' Advises to 'prefer specific sections — these can be large,' guiding the agent to request only needed domains. Lacks explicit when-not-to-use or alternatives but is sufficient.

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

linkedin_get_profileGet LinkedIn résuméA

Read-onlyIdempotent

Get the user's LinkedIn résumé: bio, work history, education, skills, certifications, projects, languages, awards, publications, and more. Use for questions about who they are professionally, their background, or qualifications.

ParametersJSON Schema

Name	Required	Description	Default
`domains`	No	Sections to include. Defaults cover the core résumé: bio, work history, education, skills, certifications, projects. Add more for fuller picture: PROFILE (bio), POSITIONS (work history), EDUCATION, SKILLS, CERTIFICATIONS, PROJECTS, LANGUAGES, HONORS (awards), COURSES, PUBLICATIONS, PATENTS, ORGANIZATIONS (memberships), VOLUNTEERING_EXPERIENCES, RECOMMENDATIONS, PROFILE_SUMMARY.
`maxPagesPerDomain`	No	Max pages of results to fetch (1–25). Each page holds ~10 records. Lower this to keep responses small.

Output Schema

ParametersJSON Schema

Name	Required	Description
`domains`	Yes	Records grouped by section name (e.g. POSITIONS, EDUCATION). Each value is the list of items in that section.
`metadata`	Yes	Per-section fetch stats. Check truncated to detect partial results.
`apiVersion`	Yes	LinkedIn API version used for the request.

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds no further behavioral details (e.g., rate limits, data freshness). It lists sections but that's more about parameters.

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?

Single sentence, front-loaded with the tool's purpose. All listed sections are relevant. Could be slightly more structured, but concise overall.

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?

The tool has 2 optional parameters and an output schema (not shown). The description covers the main return content well. Given the tool's simplicity, it is sufficiently complete.

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 coverage is 100%, with both parameters well-documented. The description adds minimal extra meaning beyond what's in the schema (e.g., implicit listing of sections).

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 retrieves the user's LinkedIn résumé and lists many sections (bio, work history, education, etc.). It distinguishes from siblings (get_activity, get_section, etc.) by focusing on the full professional profile.

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?

The description says 'Use for questions about who they are professionally, their background, or qualifications,' which gives clear use context. However, it does not explicitly exclude use cases or mention when to prefer sibling tools like get_activity.

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

linkedin_get_recent_changesGet recent LinkedIn changesA

Read-onlyIdempotent

Get the user's LinkedIn data changes from the past 28 days (profile edits, new connections, etc.). Poll incrementally by passing the previous response's nextStartTime. If empty, run linkedin_check_access to verify consent.

ParametersJSON Schema

Name	Required	Description
`count`	No	Events per page (1–50).
`maxPages`	No	Max pages of results to fetch (1–25). Each page holds ~10 records. Lower this to keep responses small.
`startTime`	No	Only return changes at or after this Unix timestamp in milliseconds. Omit for the most recent changes. For polling, pass the previous response's nextStartTime.

Output Schema

ParametersJSON Schema

Name	Required	Description
`events`	Yes	Recent change events on the member's LinkedIn data.
`pageCount`	Yes	Pages fetched.
`truncated`	Yes	True if more results exist beyond the page limit.
`apiVersion`	Yes	LinkedIn API version used for the request.
`nextStartTime`	No	Pass this back as startTime on the next call to continue polling without duplicates.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds context about the 28-day window and polling mechanism, which is complementary and does not contradict annotations.

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?

Two concise sentences with clear front-loading of purpose. No unnecessary words, every sentence adds value.

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

Completeness5/5

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

With 3 parameters, no required, and an output schema, the description is complete. It explains the 28-day window, polling, and fallback action, leaving no critical gaps for agent invocation.

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?

All three parameters have schema descriptions (100% coverage). Description adds value by explaining the polling usage of startTime and the meaning of the time window, enhancing understanding beyond schema.

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?

Description clearly states it retrieves user LinkedIn data changes from the past 28 days, with specific examples (profile edits, new connections). It distinguishes itself from sibling tools like linkedin_get_profile or linkedin_get_activity.

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?

Explicitly mentions incremental polling via nextStartTime and suggests running linkedin_check_access if empty. However, it does not explicitly state when not to use this tool or compare to alternatives beyond the polling hint.

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

linkedin_get_sectionGet one LinkedIn sectionA

Read-onlyIdempotent

Get raw data for a single LinkedIn section by exact name. Use when you need one specific section or the raw API response. Section names are case-sensitive.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Section name (case-sensitive). Résumé: PROFILE, PROFILE_SUMMARY, POSITIONS, EDUCATION, SKILLS, CERTIFICATIONS, PROJECTS, ORGANIZATIONS, LANGUAGES, HONORS, COURSES, PUBLICATIONS, PATENTS, VOLUNTEERING_EXPERIENCES, RECOMMENDATIONS. Activity: CONNECTIONS, MEMBER_SHARE_INFO, ARTICLES, ALL_COMMENTS, ALL_LIKES, JOB_APPLICATIONS, JOB_POSTINGS, SAVED_JOBS, JOB_SEEKER_PREFERENCES.
`maxPages`	No	Max pages of results to fetch (1–25). Each page holds ~10 records. Lower this to keep responses small.

Output Schema

ParametersJSON Schema

Name	Required	Description
`domain`	Yes	The section that was fetched.
`pageCount`	Yes	Pages fetched.
`truncated`	Yes	True if more results exist beyond the page limit.
`apiVersion`	Yes	LinkedIn API version used for the request.
`rawElements`	Yes	Raw LinkedIn API elements (with metadata) for advanced use.
`snapshotData`	Yes	List of records for this section.

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds that section names are case-sensitive and returns raw data, which is useful but minimal beyond annotations.

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?

The description is extremely concise with two sentences, front-loading the core purpose. Every sentence adds value: the first states the function, the second provides usage guidance and a key constraint (case-sensitivity). No extraneous information.

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?

Given the tool has 2 well-documented parameters, an output schema (present per context signals), and rich annotations, the description covers the essential purpose and use case. It mentions 'raw API response', which is helpful. It could be slightly more complete by hinting at output format, but the existing output schema handles that.

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?

With 100% schema description coverage, the schema already documents both parameters (domain enum with all values, maxPages with default/range). The tool description mentions 'exact name' and 'case-sensitive', reinforcing the schema but not adding new semantic meaning beyond it.

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 verb 'Get', the resource 'single LinkedIn section', and emphasizes 'by exact name', 'raw API response', and case-sensitivity, which distinguishes it from siblings like linkedin_get_profile and linkedin_get_activity.

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?

The description explicitly says 'Use when you need one specific section or the raw API response', providing clear context for when to use the tool. It does not explicitly state when not to use or name alternatives, but the sibling tools in the context help fill that gap.

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. Dates show when Glama detected each change.

5 tool updatesv1.0.4Jul 28, 2026
- First observedlinkedin_check_access
- First observedlinkedin_get_activity
- First observedlinkedin_get_profile
- First observedlinkedin_get_recent_changes
- First observedlinkedin_get_section

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool serves a distinct purpose: profile retrieval, activity, raw section data, access check, and recent changes. No overlaps or ambiguity.

Naming Consistency5/5

All tools follow the pattern 'linkedin_<verb>_<noun>', with verbs 'get' or 'check' and nouns indicating the resource. Consistent and clear.

Tool Count5/5

Five tools is an appropriate size for a LinkedIn data server, covering core read operations without being excessive or too few.

Completeness5/5

The tool set covers profile, activity, specific sections, access verification, and change tracking. Missing write operations but the server is read-only, making the coverage comprehensive.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

LinkedIn MCP (by TalkToHumans)OAuth
io.github.CoolSapiens
Let AI tools securely access your LinkedIn network and DMs
Social Media Communication
2
SalesTouchOAuth
io.salestouch
Give AI agents the LinkedIn tools to find, qualify, engage, and follow up with prospects.
Social Media CRM Autonomous Agents
22
ZOOQ - LinkedIn Data for AI Agents A
io.github.baldiga
Live LinkedIn data for AI agents: profiles, companies, jobs, posts, email finding. No account risk.
Social Media Search Research & Data
451
crispyOAuth
sh.crispy
Full LinkedIn access for AI agents: leads, messaging, and campaigns with safe limits built in.
Social Media CRM Communication
2

Related MCP Servers

kaushik-linkedin-mcp
Browser Automation Web Scraping Social Media
Secure-tree
A
license
Not graded
quality
D
maintenance
Enables Claude AI to interact with LinkedIn through browser automation, including profile reading, people and job search, company research, post publishing, and profile editing.
Updated 5 months ago (2026-03-24 20:01 UTC)
MIT
linkedit-mcp
Social Media
SimbioLabs
F
license
A
quality
D
maintenance
Enables AI assistants to read and edit LinkedIn profiles including headline, about section, work experience, education, and skills through OAuth 2.0 authentication.
Updated 5 months ago (2026-03-25 00:16 UTC)
16
-
LinkedIn MCP Server
Social Media Communication
jahnavi-yarramsetty
A
license
Not graded
quality
C
maintenance
Enables reading your own LinkedIn posts and articles inside Claude Desktop via LinkedIn's official OAuth 2.0 API.
Updated a month ago (2026-07-27 12:31 UTC)
MIT
LinkedIn Archive MCP
Social Media File Systems Search
nudavinci64
A
license
Not graded
quality
C
maintenance
Enables Claude to read your own LinkedIn profile directly from a local data export, with no API keys, OAuth, or scraping. Tools cover profile, positions, skills, posts, connections, and more, supporting editing drafts and cross-checking against résumés.
Updated a month ago (2026-08-05 23:37 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/larsbaunwall/Unlinked'

If you have feedback or need assistance with the MCP directory API, please join our Discord server