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 "Deploy 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 Source Related Servers Discussions Admin

TypeScript

Remote

Unlinked

Your LinkedIn profile, up to date, in one call. From your terminal or from your AI assistant.

Unlinked reads your own data from LinkedIn's official Member Data Portability API and hands it over as tidy JSON. It works two ways:

CLI: unlinked profile prints your profile as JSON.
MCP server: unlinked --mcp gives Model Context Protocol clients such as Claude Desktop and GitHub Copilot four read-only tools.

LinkedIn's data export can lag behind what you just did. Unlinked also reads your recent changes (the last 28 days) and merges them in, so a headline you edited yesterday or a comment you wrote last week is already there.

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

:warning: Use at your own risk. You use Unlinked entirely on your own responsibility. See the Disclaimer.

Quickstart

You need Node.js 22+ and a member access token from the LinkedIn OAuth Token Generator (it requires a LinkedIn Developer app with the Member Data Portability API (Member) product).

LINKEDIN_TOKEN=<your_access_token> npx -y @larsbaunwall/unlinked profile

unlinked profile                          # résumé: intro, experience, education, skills, certifications, projects
unlinked profile --sections skills,languages
unlinked profile --all                    # every résumé section
unlinked section reactions --limit 20     # one section, a page at a time, newest first
unlinked section posts --all-items        # everything in a section, for exports
unlinked activity --since 7d              # what changed recently
unlinked status                           # is LinkedIn sharing recent changes with this app?
unlinked cache clear

Results are JSON on stdout (use --compact for one line). Errors are JSON on stderr, with exit code 1 for LinkedIn or token problems and 2 for usage mistakes such as an unknown section.

Related MCP server: LinkedIn MCP Server

Use it from an AI assistant

Add --mcp so Unlinked runs as an MCP server.

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "unlinked": {
      "command": "npx",
      "args": ["-y", "@larsbaunwall/unlinked", "--mcp"],
      "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 or a workspace .vscode/mcp.json:

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

Tools

Tool	What it does
`linkedin_get_profile`	Your résumé in one call, with recent edits included. Larger sections come back as links.
`linkedin_get_section`	One section, a page at a time (`limit` 1-200, default 50, plus `cursor`).
`linkedin_get_recent_activity`	What changed in the last 28 days: profile edits, posts, comments, reactions.
`linkedin_check_access`	Whether LinkedIn is sharing recent changes with this app.

All four are read-only. Each returns structured JSON plus a one-line summary.

Sections

Sections use the names you see on LinkedIn. profile embeds the small ones; the big ones (marked paged) are fetched with section <id>.

Section id	On LinkedIn	Notes
`intro`	Intro + About	In the default profile
`experience`	Experience	In the default profile
`education`	Education	In the default profile
`skills`	Skills	In the default profile
`certifications`	Licenses & certifications	In the default profile
`projects`	Projects	In the default profile
`languages`, `volunteering`, `honors`, `courses`, `publications`, `patents`, `test-scores`, `organizations`, `causes`, `services`	Languages, Volunteering, Honors & awards, Courses, Publications, Patents, Test scores, Organizations, Causes, Services	With `profile --all`
`recommendations`	Recommendations	With `profile --all`. Received and given are mixed; LinkedIn does not say which is which
`posts`, `comments`, `reactions`, `reposts`, `articles`	Activity	Paged. Recent posts, comments and reactions are merged in
`connections`, `invitations`	My Network	Paged. Email addresses are removed
`followed-companies`, `followed-people`, `groups`	Interests	Paged
`saved-jobs`, `job-applications`, `job-preferences`, `job-postings`	Jobs	Paged. Contact details and addresses are removed
`endorsements-given`	Endorsements you gave	Paged
`learning`	LinkedIn Learning history	Paged

Sensitive data is never read: messages, login history, phone numbers, email addresses, contacts, ads, searches, receipts and similar. Private details inside the sections above (birth date, home address and so on) are removed.

Featured, your profile photo and banner, and contact info (beyond websites) are not in LinkedIn's API, so Unlinked cannot return them.

Freshness and cache

Every answer has a freshness block: when the data was fetched (asOf), how many recent changes were merged in, which sections have edits LinkedIn's export does not show yet (pendingEdits), and which came back empty.

An empty section has two possible meanings: you have no entries there, or LinkedIn has not prepared it yet (new data can take up to 24 hours after you first grant consent).

To be kind to LinkedIn's API, results are cached for up to 6 hours. The CLI keeps the cache in your OS cache folder (readable only by you, never containing your token); the MCP server keeps it in memory only.

unlinked profile --refresh     # fetch fresh data now
unlinked profile --no-cache    # do not read or write the cache
unlinked cache clear           # delete the cached files
UNLINKED_CACHE_TTL=30m         # change the lifetime (30m, 2h, 1d, or 0 for off)

Configuration

Environment variable	Required	Description
`LINKEDIN_TOKEN`	Yes	LinkedIn access token. Accepts `Bearer <token>` or a bare token.
`UNLINKED_CACHE_TTL`	No	Cache lifetime: `30m`, `2h`, `1d`, or `0` to turn it off. Defaults to `6h`.

LINKEDIN_API_VERSION is no longer used. LinkedIn accepts only version 202312 for this API, so Unlinked always sends that and warns on stderr if the variable is set to anything else.

Upgrading from 1.x

2.0 is a breaking release.

MCP configs need --mcp in args. Without it Unlinked runs as a CLI and exits.
Five tools became four: linkedin_get_profile, linkedin_get_section, linkedin_get_recent_activity and linkedin_check_access. linkedin_get_activity, linkedin_get_recent_changes and the domain/maxPages inputs are gone.
Sections use LinkedIn's UI names (experience, reactions) instead of internal ones (POSITIONS, ALL_LIKES), and rows use camelCase keys without empty values.
Recent changes are merged into the data for you; there is no startTime polling.
Sensitive sections are blocked, and private fields are removed.

Security

Treat tool output as untrusted data. Sections such as recommendations you received, invitation messages, and connection names and headlines contain text written by other people. An assistant should read it as data and never follow instructions found in it (prompt injection).
The disk cache is plaintext. The CLI cache (up to 6 hours, readable only by you) holds your profile plus connections, invitations and job-application data, unencrypted. Your token is never written to it. Run unlinked cache clear to remove it. The MCP server keeps its cache in memory only.

Development

npm install
npm run build
npm test
npm run typecheck
npm run dev -- profile   # run from source with .env
npm run inspect          # try the MCP server in MCP Inspector (build first)

See AGENTS.md for implementation guidance.

Disclaimer

Use of Unlinked is at your sole risk and responsibility.

Unlinked is provided "as is" and "as available", without warranty of any kind, express or implied. It is an independent, unofficial open-source project. It is not affiliated with, endorsed by, or sponsored by LinkedIn, GitHub, or Microsoft.

By installing or using Unlinked, you accept that:

You are solely responsible for how you use it and for everything that follows from that use. This includes your LinkedIn access token and its storage, the data you retrieve, the local cache on your machine, and the AI assistants, MCP clients, and third-party services you give that data to.
You are responsible for compliance with LinkedIn's terms, policies, and API product terms, with applicable laws (including data protection law such as the GDPR), and with the terms of any AI assistant or service you connect. Your LinkedIn account and API access may be limited, suspended, or terminated by LinkedIn.
You bear all risk of loss, damage, or harm of any kind, including loss or exposure of data, account restrictions, incorrect or outdated output, and actions taken by AI assistants based on that output.
The developer and contributors accept no liability and, to the fullest extent permitted by law, disclaim all liability for any claim, damage, or loss, whether direct, indirect, incidental, special, consequential, or otherwise, and whether in contract, tort, or otherwise, arising from or in connection with Unlinked or its use. You release them from any such claim and agree to indemnify and hold them harmless against any claim brought by a third party that arises from your use of Unlinked.

Nothing in this notice limits any liability that cannot be excluded under applicable law. This notice supplements the MIT License, which also applies.

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.

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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-07-28 19:35 across 5 tools

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

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

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
LinkFetch: LinkedIn MCP
io.linkfetch
LinkedIn jobs, companies and people for AI agents, plus messages and invites via your own account.
Social Media Search Communication
1
TopClozer LinkedIn MCP
com.topclozer
LinkedIn for AI agents: search people, read profiles, posts and connections via a connected account
Social Media Search
1
QuibblyOAuth
co.quibbly
Your LinkedIn inbox, connections and video views for AI. Works with any CRM. Drafts only.
Communication Social Media
1

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 7 months ago (2026-03-24 20:01 UTC)
MIT
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 3 months 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 2 months ago (2026-08-05 23:37 UTC)
MIT
LinkedIn MCP Server
Social Media Browser Automation Communication
abetoluwani
A
license
A
quality
B
maintenance
Enables AI assistants to read LinkedIn profiles, company pages, jobs, messages, and feed through a user's logged-in browser session.
Updated 2 months ago (2026-08-21 11:40 UTC)
19
Apache 2.0