How do I use linkedit-mcp?

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., "@linkedit-mcp Update my LinkedIn headline to Founder at SimbioLabs" 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.

linkedit-mcp

by SimbioLabs

Overview Schema Related Servers Score Discussions

TypeScript

Local

linkedit-mcp

A Model Context Protocol server that lets AI assistants read and edit your LinkedIn profile — headline, about section, work experience, education, and skills.

Built by SimbioLabs.

Tools

Tool	Description
`authenticate`	Start OAuth 2.0 flow — opens LinkedIn in your browser
`logout`	Clear stored session tokens
`get_profile`	Read name, headline, about, email, and vanity URL
`update_headline`	Update your LinkedIn headline (max 220 chars)
`update_about`	Update your About / summary section (max 2600 chars)
`get_experience`	List all work experience entries
`add_experience`	Add a new position
`update_experience`	Edit an existing position
`delete_experience`	Remove a position
`get_education`	List all education entries
`add_education`	Add a new education entry
`update_education`	Edit an existing education entry
`delete_education`	Remove an education entry
`get_skills`	List all skills
`add_skill`	Add a skill
`remove_skill`	Remove a skill

Related MCP server: LinkedIn MCP Server

Setup

1. Create a LinkedIn Developer App

Go to LinkedIn Developer Portal and create a new app.
Under Auth, add http://localhost:3000/callback as an OAuth 2.0 redirect URL.
Under Products, request access to Sign In with LinkedIn using OpenID Connect (provides r_liteprofile, r_emailaddress).
Copy your Client ID and Client Secret.

Note on profile write access: The update_headline, update_about, add_experience, add_education, and skill tools use LinkedIn's profile write API, which requires your app to have the LinkedIn Partner Program permissions (w_member_social is open, but full profile write requires partner approval). Check LinkedIn API access levels for details.

2. Configure environment

cp .env.example .env

Edit .env with your credentials:

LINKEDIN_CLIENT_ID=your_client_id_here
LINKEDIN_CLIENT_SECRET=your_client_secret_here
LINKEDIN_REDIRECT_URI=http://localhost:3000/callback

3. Install and build

npm install
npm run build

4. Add to Cursor / Claude Desktop

In your MCP config (e.g. ~/.cursor/mcp.json or claude_desktop_config.json):

{
  "mcpServers": {
    "linkedit": {
      "command": "node",
      "args": ["/absolute/path/to/linkedit-mcp/dist/index.js"],
      "env": {
        "LINKEDIN_CLIENT_ID": "your_client_id",
        "LINKEDIN_CLIENT_SECRET": "your_client_secret",
        "LINKEDIN_REDIRECT_URI": "http://localhost:3000/callback"
      }
    }
  }
}

5. Authenticate

In your AI assistant, run:

authenticate

A browser window will open. Approve the LinkedIn permissions, then return to your assistant — you're ready.

Example usage

Update my LinkedIn headline to "Founder @ SimbioLabs | Building AI-native products"

Add a new job: Software Engineer at Acme Corp, Jan 2022 to Mar 2024, describe it as leading backend infrastructure for a B2B SaaS platform

Add my MBA from Stanford Graduate School of Business, 2019–2021

Token storage

Tokens are stored locally at ~/.linkedit-mcp/tokens.json. They are never sent anywhere other than LinkedIn's OAuth endpoints. Use logout to clear them at any time.

Development

npm run dev   # watch mode
npm start     # run compiled server

License

MIT — SimbioLabs

Available Tools

10 tools

add_experienceB

Add a new work experience entry to the authenticated user's LinkedIn profile.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Job title
`end_year`	No	End year (omit if this is your current role)
`location`	No	Work location
`end_month`	No	End month (omit if this is your current role)
`is_current`	No	Set to true if this is your current role
`start_year`	Yes	Start year
`description`	No	Role description
`start_month`	Yes	Start month (1–12)
`company_name`	Yes	Company name

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only says 'Add' but fails to mention whether duplicate entries are allowed, handling of current roles, or any side effects.

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 a single concise sentence that directly conveys the tool's purpose with no unnecessary words.

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

Completeness2/5

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

Given 9 parameters and no output schema, the description lacks information about return values, error handling, or authentication context, making it incomplete.

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%, so the baseline is 3. The description does not add extra meaning beyond the parameter descriptions in the 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?

The description clearly states the verb 'Add' and the resource 'new work experience entry to the authenticated user's LinkedIn profile,' distinguishing it from sibling tools like delete_experience or get_experience.

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

Usage Guidelines2/5

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

No usage guidelines are provided; the description does not indicate when to use this tool versus alternatives or mention prerequisites like having an active session.

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

authenticateA

Authenticate with LinkedIn via OAuth 2.0. Opens a browser window for authorization. Must be called before using any other tool.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

Despite no annotations, the description discloses 'Opens a browser window for authorization,' a key behavioral trait. Could mention session management but is adequate.

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 terse sentences, front-loaded with action and resource, no wasted words.

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 parameterless authentication tool with no output schema, the description fully covers purpose and prerequisite.

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?

Input schema has zero parameters; baseline is 4 as per rules. No additional parameter info needed.

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 specifies 'Authenticate with LinkedIn via OAuth 2.0' (specific verb and resource) and distinguishes from siblings as the only authentication tool.

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?

Explicitly states 'Must be called before using any other tool,' providing clear usage context and precedence.

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

delete_experienceB

Delete a work experience entry from the authenticated user's LinkedIn profile.

ParametersJSON Schema

Name	Required	Description	Default
`position_id`	Yes	The position ID to delete (get it from get_experience)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only indicates a destructive delete operation and implies authentication. It does not discuss irreversibility, error handling, rate limits, or consequences of invalid position IDs, leaving significant gaps for a mutation tool.

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 a single 13-word sentence, front-loaded with the action, and contains no unnecessary words. Every word earns its place.

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

Completeness3/5

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

For a simple delete tool with one parameter and no output schema, the description is somewhat complete but lacks behavioral transparency and usage guidance. It adequately states what it does but not enough context for safe invocation without additional hints.

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 the parameter description already stating 'The position ID to delete (get it from get_experience).' The main description adds no extra parameter meaning beyond the schema. 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 'Delete a work experience entry from the authenticated user's LinkedIn profile.' It specifies the verb (delete), resource (work experience entry), and scope (authenticated user's LinkedIn profile), effectively distinguishing it from sibling tools like add_experience and get_experience.

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

Usage Guidelines2/5

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

The description does not provide when to use this tool versus alternatives. It only states the action. The parameter description hints at using get_experience first to obtain the position_id, but the main description lacks explicit guidance on prerequisites or scenarios for deletion.

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

get_experienceA

Retrieve all work experience entries from the authenticated user's LinkedIn profile.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. States read-only behavior ('Retrieve') but does not disclose potential error cases, rate limits, or authentication prerequisites beyond implied user context.

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?

Single sentence with no wasted words. Front-loaded with key information: action, resource, scope.

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?

For a simple retrieval tool with no parameters or output schema, the description adequately covers purpose and scope. Could mention return format but is sufficient for selection.

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?

No parameters in schema, so baseline is 4. Description adds no parameter details as none exist.

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 the verb 'Retrieve', resource 'all work experience entries', and scope 'authenticated user's LinkedIn profile'. Distinguishes from siblings like add_experience and delete_experience.

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

Usage Guidelines3/5

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

Provides clear context (retrieve work experience for authenticated user) but does not offer explicit guidance on when to use versus alternatives like get_profile, nor when not to use.

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

get_profileA

Retrieve the authenticated user's LinkedIn profile: name, headline, about/summary, vanity URL, and email.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It explicitly states it retrieves a profile and lists the fields, implying a read-only operation with no side effects. No additional behavioral traits (e.g., authentication requirements) are mentioned, but for a simple read-only tool this is sufficient.

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 a single sentence that front-loads the action and resource, then lists specific return fields. It is concise and structured effectively with no unnecessary information.

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?

Given there are no parameters, no output schema, and the tool is simple, the description lists the return fields (name, headline, about/summary, vanity URL, email) which provides complete context for an agent to understand what the tool does and what it returns.

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 zero parameters, and schema description coverage is 100% (no parameters to describe). The description does not need to add parameter info. Baseline for 0 parameters 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 'Retrieve the authenticated user's LinkedIn profile' and lists specific fields (name, headline, about/summary, vanity URL, email). It uses a specific verb and resource, and it is distinct from sibling tools like get_experience and get_skills.

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

Usage Guidelines3/5

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

The description gives a clear context (authenticated user's profile) and lists the returned fields, but it does not provide explicit guidance on when to use this tool vs. alternatives, nor any exclusions. However, for a parameterless read-only tool, the implied usage is straightforward.

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

get_skillsA

Retrieve all skills listed on the authenticated user's LinkedIn profile.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden. It only states a read operation but fails to disclose behavioral traits such as authentication requirements, rate limits, or behavior when no skills exist.

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?

Single concise sentence that directly communicates the tool's purpose. No extraneous information.

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

Completeness3/5

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

Given the simplicity (no parameters, no output schema), the description is minimally adequate. However, it lacks details on return format, pagination, or error handling, which could be helpful.

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?

Input schema has zero parameters, and schema description coverage is 100%. The description adds no parameter details, but this is appropriate as there are no parameters to document.

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 the action ('Retrieve') and resource ('all skills on the authenticated user's LinkedIn profile'). It is specific and distinct from sibling tools like 'add_experience' or 'remove_skill'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., when to call 'get_skills' vs 'get_profile'). No explicit context or exclusionary criteria provided.

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

logoutB

Clear the stored LinkedIn session tokens.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided; description only states it clears tokens but does not disclose side effects, such as whether it requires prior authentication, if it invalidates sessions, or how it affects subsequent tool calls.

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?

A single, concise sentence that conveys the essence without extraneous words.

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

Completeness2/5

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

Lacks details on post-call behavior (e.g., return value, state changes) which are critical for a mutagenic tool with no output 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?

With no parameters and 100% schema coverage, the description does not add meaning beyond what the schema provides; it merely restates the function.

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 identifies the action ('Clear') and the resource ('stored LinkedIn session tokens'), making it distinct from sibling tools like authenticate which sets tokens.

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

Usage Guidelines2/5

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

No guidance on when to use logout versus alternatives (e.g., whether it's a prerequisite for re-authentication or if it can be called repeatedly).

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

remove_skillA

Remove a skill from the authenticated user's LinkedIn profile.

ParametersJSON Schema

Name	Required	Description	Default
`skill_id`	Yes	The skill ID to remove (get it from get_skills)

TDQS

A3.9/5.0

Behavior3/5

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

No annotations exist, so the description carries the transparency burden. It implies a destructive write operation but does not disclose permanence, side effects, or response behavior. Adequate for a simple action but lacks detail.

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?

A single sentence that is perfectly concise and to the point, with no wasted words.

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?

For a simple one-parameter tool with no output schema, the description covers the purpose and parameter well. It could mention the expected result (e.g., successful removal) but is otherwise sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole parameter 'skill_id' includes a helpful hint in the schema description to obtain it from get_skills. This adds value beyond the schema's type definition.

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 'Remove', the resource 'skill', and the context 'authenticated user's LinkedIn profile'. It is specific and distinguishes from sibling tools like add_experience or get_skills.

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

Usage Guidelines2/5

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 alternatives (e.g., get_skills to find skill IDs). The description does not mention prerequisites or exclusions.

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

update_aboutB

Update the authenticated user's LinkedIn About / summary section (max 2600 characters).

ParametersJSON Schema

Name	Required	Description	Default
`about`	Yes	The new About/summary text (max 2600 characters)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It only mentions the update action and max length, but doesn't clarify whether it replaces or appends content, nor any side effects, permissions, or error conditions.

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?

The description is a single concise sentence that front-loads the key information. While it could include more detail, it avoids unnecessary words.

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

Completeness3/5

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

For a simple 1-parameter update tool, the description covers the basic purpose and constraint. However, it lacks behavioral details like overwrite behavior, return values, and auth requirements, which reduces completeness given no output schema or annotations.

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% for the single parameter 'about', and the tool description reiterates the max length. No additional meaning is added beyond what the schema provides, warranting a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Update' and the resource 'authenticated user's LinkedIn About / summary section', with a character limit. However, it doesn't explicitly differentiate from sibling tools like update_headline, though the resource is distinct enough.

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

Usage Guidelines3/5

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

Implies usage when updating the About section, but lacks explicit guidance on when to use this tool versus alternatives or any prerequisites like authentication.

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

update_headlineA

Update the authenticated user's LinkedIn headline (max 220 characters).

ParametersJSON Schema

Name	Required	Description	Default
`headline`	Yes	The new headline text (max 220 characters)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It states the primary action (update) and a constraint (max 220 chars), but lacks details on side effects, authentication requirements beyond 'authenticated user', or error behavior. Adequate but basic.

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?

Single, clear sentence with no superfluous words. The critical information (action, target, constraint) is front-loaded.

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 low complexity (1 required parameter, no nested objects, no output schema), the description is functional. It tells the agent what the tool does. Could optionally mention return value or typical success/error signals, but the omission is not critical for such a simple mutation.

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% (the parameter 'headline' is described with maxLength and a brief description). The tool description adds minimal extra meaning beyond stating 'max 220 characters', which is already in the schema. Baseline score of 3 applies.

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 uses a specific verb ('Update') and explicitly names the resource ('authenticated user's LinkedIn headline') with a clear constraint (max 220 characters). It distinguishes from sibling tools like add_experience, get_skills, and update_about.

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

Usage Guidelines3/5

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

The description implies usage (update headline) but provides no explicit guidance on when to use this tool versus alternatives. Sibling tool names offer context, but the description itself does not mention when-not-to-use or prerequisites.

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.

10 tool updatesv0.1.0Jul 22, 2026
- First observedadd_experience
- First observedauthenticate
- First observeddelete_experience
- First observedget_experience
- First observedget_profile
- First observedget_skills
- First observedlogout
- First observedremove_skill
- First observedupdate_about
- First observedupdate_headline

Install Server

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

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: authentication, profile/skills retrieval, experience CRD, and specific profile updates. No two tools overlap in function.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern with underscores (e.g., add_experience). Two tools (authenticate, logout) are single verbs, but this deviation is minor and does not cause confusion.

Tool Count5/5

With 10 tools, the server is well-scoped for managing a LinkedIn profile. Each tool serves a necessary function without redundancy.

Completeness2/5

Significant gaps exist: there is no update_experience tool (only add and delete) and no add_skill tool (only remove). These omissions limit the ability to fully manage the profile.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

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
crispyOAuth
sh.crispy
Full LinkedIn access for AI agents: leads, messaging, and campaigns with safe limits built in.
Social Media CRM 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

Related MCP Servers

LinkedIn MCP Server
Social Media Communication
quinnjr
A
license
B
quality
C
maintenance
Enables AI agents to manage LinkedIn profiles, posts, connections, skills, education, and certifications through the LinkedIn API.
Updated a month ago (2026-08-03 15:06 UTC)
18
176
64
MIT
LinkedIn MCP Server
Social Media Marketing
himanshu31shr
A
license
B
quality
A
maintenance
Enables AI agents with read/write access to LinkedIn API, including profile, posts, media, organizations, comments, reactions, and analytics.
Updated 3 months ago (2026-06-21 19:15 UTC)
20
15
MIT
LinkedIn Agent MCP
Social Media Web Scraping
iushv
A
license
Not graded
quality
D
maintenance
Enables AI assistants to connect to LinkedIn, accessing profiles and companies, searching for jobs and people, managing saved jobs, updating job-search profile settings, and inspecting analytics.
Updated a month ago (2026-08-03 18:44 UTC)
1
Apache 2.0
LinkedIn MCP Server
Social Media Communication
ASISaga
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with LinkedIn using the official API for profile access, company management, and job postings.
Updated 5 months ago (2026-04-10 01:22 UTC)
Apache 2.0

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/SimbioLabs/linkedit-mcp'

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