Skip to main content
Glama
greg0r1

linkedin-mcp-server

by greg0r1
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

LinkedIn MCP Server

A Model Context Protocol (MCP) server that enables Claude Desktop to interact with your LinkedIn profile and company pages. Connect your LinkedIn account to Claude AI and manage your professional presence directly through conversations.

🎯 Features

✅ Fully Supported (Standard API Access)

Personal Profile

  • Fetch your profile information

  • Create and publish posts

  • Read your posts

  • Delete posts

Company Pages

  • Publish posts on behalf of your company page

  • Read company page information

  • Get company posts

⚠️ Limited or Requires Special Access

Company Analytics

  • ⚠️ Requires Marketing Developer Platform access

  • Not available with standard API permissions

Job Search

  • ❌ LinkedIn deprecated the public job search API

  • Feature code exists but is not functional

Messaging

  • ❌ Requires additional LinkedIn API permissions

  • Not available with standard API access

  • Feature code exists but is not functional

Related MCP server: LinkedIn Intelligence MCP Server

🚀 Quick Start

Prerequisites

  1. Node.js 18+ installed on your system

  2. A LinkedIn application - Create one here

  3. Claude Desktop - Download here

Installation Steps

1. Clone and install dependencies

git clone <your-repo-url>
cd linkedin-mcp-server
npm install

2. Create a LinkedIn Application

  1. Go to LinkedIn Developers

  2. Create a new app with these settings:

    • App name: Choose any name (e.g., "My LinkedIn MCP Server")

    • LinkedIn Page: Select your company page or create one

    • App logo: Optional

  3. In the Auth tab:

    • Add redirect URL: http://localhost:3000/auth/callback

    • Copy your Client ID and Client Secret

  4. In the Products tab, request access to:

    • "Sign In with LinkedIn using OpenID Connect"

    • "Share on LinkedIn"

3. Configure environment variables

cp .env.example .env

Edit .env and add your credentials:

LINKEDIN_CLIENT_ID=your_client_id_here
LINKEDIN_CLIENT_SECRET=your_client_secret_here
LINKEDIN_REDIRECT_URI=http://localhost:3000/auth/callback
LINKEDIN_COMPANY_ID=your_company_id_here  # Optional, for company page features

4. Build the project

npm run build

5. Authenticate with LinkedIn (one-time setup)

npm start

This step is only needed once to obtain your LinkedIn OAuth token:

  • Starts a temporary HTTP server on port 3000

  • Opens your browser to LinkedIn authentication

  • Saves your access tokens to ~/.linkedin-mcp-tokens.json (in your home directory)

  • The server will automatically close after authentication

Note: After this initial authentication, you don't need to run npm start again. Claude Desktop will use the saved token automatically.

🔧 Claude Desktop Configuration

After building and authenticating, configure Claude Desktop to use your MCP server:

Add this configuration to your Claude Desktop config file:

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

{
  "mcpServers": {
    "linkedin": {
      "command": "node",
      "args": [
        "/ABSOLUTE/PATH/TO/linkedin-mcp-server/dist/index.js"
      ]
    }
  }
}

Important: Replace /ABSOLUTE/PATH/TO/linkedin-mcp-server with the actual path to your project directory.

To get the absolute path:

# On macOS/Linux
pwd

# On Windows (PowerShell)
Get-Location

Then restart Claude Desktop completely (quit and reopen).

How it works: Claude Desktop will automatically launch the MCP server (via dist/index.js) when needed. You don't need to run npm start - that was only for the initial OAuth authentication.

🎯 Usage

Once configured, you can ask Claude Desktop:

Personal Profile

"Get my LinkedIn profile information"
"Show me my LinkedIn profile"

Publishing Posts

"Post on LinkedIn: Just learned about MCP servers, amazing technology!"
"Show me my last 5 LinkedIn posts"
"Delete my last LinkedIn post"

Company Page (if configured)

"Post on my company page: We're hiring a Senior Developer!"
"Show posts from my company page"
"Get information about my company page"

Note: Job search and messaging features are not available with standard LinkedIn API access. See the Features section for details.

🏢 Getting Your Company ID (Optional)

To publish on your company page, you need to find your Company ID:

Method 1: Use the provided script

npm run get-company-id

This will authenticate and show all company pages you administrate.

Method 2: From LinkedIn URL

  1. Go to your company page on LinkedIn

  2. Look at the URL: linkedin.com/company/your-company-name/

  3. Use browser developer tools to find the numeric ID in the page source

Add the Company ID to your .env file:

LINKEDIN_COMPANY_ID=123456789

Note: You must be an administrator of the company page to post on its behalf.

📁 Project Architecture

Built with Clean Architecture principles:

src/
├── domain/              # Business entities
│   ├── entities/       # LinkedIn entities
│   └── interfaces/     # Contracts & interfaces
├── application/        # Use cases
│   └── use-cases/     # Business logic
├── infrastructure/     # External services
│   ├── linkedin/      # LinkedIn API client
│   └── storage/       # Token storage
├── presentation/       # MCP layer
│   └── tools/         # Exposed MCP tools
└── index.ts           # Entry point

🔐 Security

  • ⚠️ NEVER commit your .env file

  • ⚠️ OAuth tokens are stored locally in ~/.linkedin-mcp-tokens.json (in your home directory)

  • ⚠️ Keep .env in .gitignore

  • ⚠️ Tokens are automatically refreshed when needed

  • ⚠️ You can customize the token storage path with the TOKEN_STORAGE_PATH environment variable

🛠️ Development

# Build TypeScript (required before using with Claude Desktop)
npm run build

# Development mode with auto-reload (for testing changes)
npm run dev

# Authenticate with LinkedIn (one-time setup only)
npm start

# Get your company ID (for posting on company pages)
npm run get-company-id

Important:

  • npm run build is required before using the MCP server with Claude Desktop

  • npm start is only needed once for OAuth authentication

  • After authentication, Claude Desktop launches the server automatically via the config file

📚 Resources

🐛 Troubleshooting

"Invalid environment variables"

Check that your .env file contains valid values (not placeholders like your_client_id_here)

"Authentication failed"

  1. Verify your Redirect URI matches exactly: http://localhost:3000/auth/callback

  2. Check that you've requested access to required Products in LinkedIn Developer Portal

  3. Delete ~/.linkedin-mcp-tokens.json and try authenticating again

MCP server not starting in Claude Desktop

  1. Verify the path in claude_desktop_config.json is absolute and correct

  2. Ensure npm run build completed successfully

  3. Check Claude Desktop logs:

    • macOS: ~/Library/Logs/Claude/mcp*.log

    • Windows: %APPDATA%\Claude\logs\mcp*.log

"Company not found"

Make sure you're an administrator of the company page on LinkedIn

"Failed to retrieve LinkedIn posts" or rate limit errors

LinkedIn API has strict rate limits and restrictions:

  • Personal posts (get_my_posts): May be limited or require additional permissions

  • Company posts (get_company_posts): May require Marketing Developer Platform access

  • Try reducing the number of posts requested (use a smaller limit)

  • Check your LinkedIn app's permissions and products in the Developer Portal

  • Some endpoints may not be available with standard API access

MCP protocol errors or "broken pipe"

If you see errors in Claude Desktop logs about the MCP protocol:

  • This has been fixed in recent versions - ensure you have the latest code

  • All logging now goes to stderr (not stdout) to avoid interfering with the MCP protocol

  • Restart Claude Desktop after updating

📝 License

MIT

👤 Author

Created with ❤️ by Grégory Dernaucourt

🤝 Contributing

Contributions, issues, and feature requests are welcome!

⭐ Show your support

Give a ⭐️ if this project helped you connect your LinkedIn to Claude AI!

Available Tools

7 tools
linkedin_create_company_postA

Create and publish a post on behalf of a company page

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesThe text content of the post (max 3000 characters)
companyIdYesThe LinkedIn company ID
visibilityNoPost visibility setting (default: PUBLIC)

TDQS

A3.7/5.0
Behavior2/5

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

With no annotations, the description carries the full transparency burden. It only states the core action and omits any additional behavioral context such as authentication requirements, whether the post is immediately published, what the response looks like, or side effects. This matches the gap seen in similar mutation tools.

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 communicates the essential purpose without any wasted words. It is front-loaded with the verb and resource, making it immediately scannable.

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?

The tool is simple and the schema thoroughly documents all parameters, but there is no output schema and no mention of return values, prerequisites, or potential limitations. The description is adequate for a basic create operation but leaves gaps for an agent to infer.

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?

The input schema already provides 100% coverage with descriptions for all three parameters. The description adds no extra parameter-specific meaning beyond the schema, so it meets the baseline but does not elevate 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 action (create and publish), the resource (a post), and the context (on behalf of a company page). This distinguishes it from the sibling tool linkedin_create_post, which likely targets personal posts, and from company page tools.

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 implies a clear use case: when the post should be associated with a company page rather than a personal profile. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions.

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

linkedin_create_postB

Create and publish a post on your LinkedIn profile

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesThe text content of the post (max 3000 characters)
visibilityNoPost visibility setting (default: PUBLIC)

TDQS

B3.4/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 carry the behavioral burden. It only states the post is 'published,' implying visibility, but omits authentication needs, irreversibility, or other side effects. The description is essentially a restatement of the tool's purpose.

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, focused sentence with no wasted words. It is front-loaded with the primary action and clearly understandable.

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?

For a create operation with no output schema and no annotations, the description is too brief. It does not mention default visibility, what happens after publishing, or what the API returns, leaving the agent with insufficient context for confident invocation.

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?

The input schema fully documents both parameters (text and visibility) with clear descriptions and a default for visibility, so the description adds no additional parameter context. The schema provides 100% coverage, establishing a baseline of 3.

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 specifies the action (create and publish) and the resource (a post on your LinkedIn profile), effectively distinguishing it from sibling tools like create_company_post by scoping to the personal profile.

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 for personal-profile posts but does not explicitly contrast with create_company_post or provide when-to-use guidance. It leaves the comparison to sibling tools implicit.

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

linkedin_delete_postB

Delete one of your LinkedIn posts

ParametersJSON Schema
NameRequiredDescriptionDefault
postIdYesThe ID of the post to delete

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not mention that deletion is irreversible, requires ownership or authentication, or that any associated data (e.g., comments) would be affected. The terse description lacks essential transparency for a destructive operation.

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, efficient sentence that immediately communicates the tool's purpose. No filler or redundant 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?

For a simple one-parameter delete tool, the description covers the basic purpose and parameter. However, it lacks usage context and behavioral transparency (e.g., irreversibility), making it only minimally complete for an agent that must decide when and how to use it safely.

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 a single parameter. The postId description 'The ID of the post to delete' is clear and sufficient. The tool description adds no extra parameter semantics beyond what the schema provides, so the baseline 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 'Delete one of your LinkedIn posts' clearly states the action (delete) and the target resource (a LinkedIn post), distinguishing it from sibling tools that create or retrieve posts. It leaves no ambiguity about what the tool does.

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, nor any exclusions. It simply states the action, leaving the agent to infer usage context from the tool name and siblings.

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

linkedin_get_company_pageB

Get information about a LinkedIn company page (e.g., GD Dev Solutions)

ParametersJSON Schema
NameRequiredDescriptionDefault
companyIdYesThe LinkedIn company ID

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get information,' which implies a read operation, but does not disclose any potential side effects, authentication requirements, rate limits, or return format peculiarities. This is minimal beyond what the tool name already conveys.

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, front-loaded sentence. It is appropriately brief, includes a practical example, and contains no unnecessary words. It does not repeat schema information or add fluff.

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 getter with one parameter and no output schema, the description is minimal but adequate. However, it does not hint at the shape of the returned data (e.g., name, URL, description), leaving the agent uncertain about what information will be provided. Given the absence of an output schema, slightly more detail would improve completeness.

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?

The input schema already fully describes the only parameter (companyId: 'The LinkedIn company ID'), achieving 100% schema description coverage. The description adds no extra semantic detail about the parameter; the example 'GD Dev Solutions' is an instance rather than a parameter nuance. Baseline 3 applies as the schema does the heavy lifting.

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's action ('Get information about a LinkedIn company page') with a concrete resource type. It distinguishes itself from sibling tools like linkedin_get_profile (personal profile) and linkedin_get_company_posts (posts) by focusing on the company page object itself.

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 provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or scenarios where other tools would be more appropriate. The example company name is illustrative but does not replace explicit usage direction.

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

linkedin_get_company_postsA

Get recent posts from a company page

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of posts to retrieve (1-100, default: 10)
companyIdYesThe LinkedIn company ID

TDQS

A3.7/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 the burden. It indicates a read operation but lacks details on pagination, output format, or potential side effects. It is minimally transparent but not misleading.

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 is front-loaded and contains no unnecessary words. It is appropriately sized for a simple tool.

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?

The tool is simple with two parameters and no output schema, but the description does not explain the return structure or how 'recent' is defined. This leaves some gaps for an agent, but it is adequate for basic usage.

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?

The input schema already provides full descriptions for both parameters (companyId and limit), so the description adds no extra parameter semantics. A baseline score of 3 is appropriate given 100% schema coverage.

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 recent posts from a company page, using a specific verb and resource. It distinguishes itself from sibling tools like linkedin_get_my_posts (personal posts) and linkedin_get_company_page (page info).

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 does not explicitly mention when to use this tool versus alternatives, but the scope 'from a company page' implies it is for company-related posts. No exclusions or alternative tool references are provided.

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

linkedin_get_my_postsB

Get your recent LinkedIn posts

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of posts to retrieve (1-100, default: 10)

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description carries the full burden. It says 'Get' which implies read-only, but it adds no context beyond the tool name itself. There is no mention of pagination, authentication requirements, or any limitations on the returned data.

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 with no wasted words. It is front-loaded and directly states the purpose without unnecessary elaboration.

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 read operation with one well-documented parameter, the description is minimally adequate. However, it lacks any mention of response structure or usage guidance, and with no output schema the agent has limited expectations about what 'posts' entails.

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?

The schema provides 100% coverage with a clear description for the 'limit' parameter. The tool description adds no additional meaning beyond what the schema already documents, so the baseline score of 3 is appropriate.

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?

The description clearly states the action (get) and the resource (your recent LinkedIn posts), which distinguishes it from sibling tools that create or delete posts. However, it does not explicitly clarify the distinction from company posts, though 'your' implies personal posts.

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 guidance is provided. There is no mention of when to use this tool versus get_company_posts or other alternatives, nor any exclusions or prerequisites.

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

linkedin_get_profileA

Get your LinkedIn profile information (name, email, etc.)

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description must convey behavior. 'Get' implies a read-only operation, and 'your' clarifies that it operates on the authenticated user's profile. However, it does not disclose response structure, potential errors, or any access constraints beyond the implicit authorization.

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 delivers the essential purpose without redundancy. It is appropriately front-loaded and easy to parse.

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 zero-parameter profile retrieval tool, the description is largely sufficient. It names the resource and gives examples of expected data. It doesn't explain return format or edge cases, but the simplicity of the operation reduces the need for additional context.

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 input schema has no parameters, so there is nothing to explain. The baseline for zero parameters is 4, and the description does not need to add parameter-level details.

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 'Get' and identifies the resource as 'your LinkedIn profile information' with examples like name and email. This clearly differentiates it from sibling tools that focus on posts or company pages.

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 when retrieving one's own profile information, but provides no explicit guidance against alternative tools or mention of when not to use it. Sibling tools are about posts and company pages, so context is somewhat clear but not explicit.

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.

  1. 7 tool updatesv1.0.0
    • First observedlinkedin_create_company_post
    • First observedlinkedin_create_post
    • First observedlinkedin_delete_post
    • First observedlinkedin_get_company_page
    • First observedlinkedin_get_company_posts
    • First observedlinkedin_get_my_posts
    • First observedlinkedin_get_profile
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool targets a distinct resource and action: profile, user posts, and company posts are clearly separated. The verb+noun naming makes it impossible to confuse create_post with create_company_post or get_my_posts with get_company_posts.

Naming Consistency5/5

All tools follow the linkedin_<verb>_<target> pattern with consistent verbs (get, create, delete). Singular/plural usage matches the action (create one post, get multiple posts), and prefixes remain uniform.

Tool Count5/5

Seven tools is well-scoped for a LinkedIn server covering profiles, user posts, and company pages. Each tool serves a clear purpose with no redundancy.

Completeness4/5

Core workflows are covered: profile retrieval, post creation/listing/deletion for users, and company page info with post creation/listing. Missing update operations and company post deletion, but these are minor gaps for typical use.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

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/greg0r1/linkedin-mcp-server'

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