linkedin-mcp-server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v4.20.1
Disambiguation5/5
Every tool targets a distinct resource and action, from profiles (get_my_profile, get_person_profile) to companies (get_company_profile, get_company_posts) to messaging (get_inbox, send_message). Even potentially overlapping tools like get_feed, get_company_posts, and search_posts are clearly separated by their descriptions, and naming follows a predictable resource-oriented pattern.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case convention: connect_, get_, search_, send_, close_. There is no mixing of camelCase, hyphenation, or inconsistent verb styles. The pattern is immediately understandable and memorable.
Tool Count3/5
At 19 tools, this server sits in the 16-25 range described as heavy. While each tool has a distinct purpose and covers a broad set of LinkedIn features (profiles, companies, jobs, messaging, posts), the count is at the upper edge and feels somewhat overcrowded compared to a typical well-scoped server. Some consolidation, such as folding sidebar profiles into a more general search, could reduce cognitive load.
Completeness4/5
The server covers a wide range of LinkedIn operations including read access to profiles, companies, jobs, messaging, and feed content, plus write actions like connecting and sending messages. Obvious gaps include the lack of content creation (e.g., posting, commenting) and profile updates, but these are not core to the apparent outreach/job-hunting use case and can be worked around with external tools.
Average 3.9/5 across 19 of 19 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits beyond the openWorldHint annotation. It does not mention that results may mark conversations as read (as noted in the limit parameter description) or any other side effects, so the description adds no relevant context.
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 directly states the core function. It is front-loaded and free of fluff, though it could include more useful information without becoming verbose.
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 search tool with a limit parameter that can mark items as read and with several sibling tools, the description is incomplete. It lacks information about result format, usage context, and alternatives, making it minimally viable at best.
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 descriptions for both 'keywords' and 'limit'. The tool description adds nothing beyond the schema, so the baseline of 3 applies.
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 'Search messages by keyword' clearly identifies the action (search) and resource (messages/conversations). It distinguishes from 'search_posts' by targeting messages, but doesn't explicitly differentiate from 'get_inbox' or 'get_conversation'.
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 offers no guidance on when to use this tool versus sibling tools like get_inbox, get_conversation, or search_posts. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety and open-world nature of the tool. However, the description adds no behavioral context beyond that, such as pagination behavior, rate limits, or the critical current_company URN caveat (which appears only in the schema). It fails to disclose any additional behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and thus concise, but it adds nearly no information beyond the title 'Search People'. It is not verbose, but it is under-specified to the point of being almost a tautology, failing to earn its place with new content.
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 presence of a rich schema (100% coverage) and annotations reduces the burden on the description. However, the description lacks any usage guidance or mention of result handling, and the tool's openWorldHint and sibling tools suggest more contextual cues would help. It is minimally viable but not fully 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 description coverage is 100%, with rich parameter details including the current_company URN gotcha and network filter format. The description itself adds no parameter-level meaning, so the baseline of 3 applies as the schema already 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 'Search for people on LinkedIn' uses a specific verb ('Search') and resource ('people on LinkedIn'), clearly distinguishing this tool from sibling tools like search_companies, search_jobs, and search_posts. It communicates the core function unambiguously, even though it does not mention return format.
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 such as get_person_profile or search_companies. There are no stated exclusions, prerequisites, or explicit mention of alternative tools, making it purely the agent's responsibility to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds no behavioral context beyond the platform 'LinkedIn' and does not disclose any additional traits such as pagination, result limits, or filtering behavior. Since it adds no extra value over annotations, the score is low.
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, direct sentence that states the tool's action without any fluff or repetition. It is appropriately sized and front-loaded, earning full marks for conciseness.
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 read-only search tool with an output schema and annotations, the description is adequate. It provides the essential purpose and platform, while schema and annotations cover parameters, safety, and return format. However, it lacks any guidance on when to use this tool over siblings, which slightly reduces 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 fully documents the sole 'keywords' parameter with a clear description and example. Since schema coverage is 100%, the description does not need to add parameter details, and it doesn't. Baseline 3 is appropriate as the schema carries the semantic weight.
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 tool searches for companies on LinkedIn, which directly matches the tool name and title. However, it does not distinguish this from sibling search tools (e.g., search_people, search_jobs) beyond the resource type, which is already evident from the name.
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 like search_people or search_jobs. It simply restates the function without mentioning contexts, exclusions, or comparative use cases, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the tool's basic function. Annotations already indicate readOnlyHint=true and openWorldHint=true, but the description does not mention that the tool scrapes LinkedIn, may return variable data, or what happens with invalid company names.
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 with no filler. It is appropriately sized for the tool's simple purpose.
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 has a well-documented schema and an output schema, and annotations provide safety hints. However, the description omits how the optional 'sections' parameter relates to the sibling get_company_posts tool, and it doesn't state that the about page is always included, which is only in the schema. This creates some ambiguity for tool selection, but overall the structured data covers most essential information.
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 has detailed descriptions for both company_name and sections, achieving 100% coverage. The description itself does not add any parameter semantics beyond the schema, so it meets the baseline for high 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 'Get a specific company's LinkedIn profile' uses a clear verb (get) and resource (company's LinkedIn profile). It is distinct from siblings like get_company_posts or search_companies, which target different resources.
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 gives no guidance on when to use this tool versus alternatives such as get_company_posts or search_companies. It does not mention the sections parameter or any exclusions, leaving the agent to infer usage from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and non-exhaustiveness. The description adds the behavioral notion of 'recent' conversations but does not detail pagination, ordering guarantees, or any other operational behaviors beyond what annotations imply.
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 front-loads the verb and resource. Every word earns its place, with zero redundancy.
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's simplicity (one optional parameter, output schema present, read-only annotation), the description is sufficiently complete for an agent to understand its core function. It could be slightly more explicit about the 'recent' qualifier, but the context signals cover the rest.
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%, so the single parameter 'limit' is fully documented. The description adds no parameter-level meaning beyond the schema.
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 a specific verb and resource: 'List recent conversations from the LinkedIn messaging inbox.' It conveys the tool's primary function without ambiguity. However, it does not explicitly distinguish itself from sibling tools like search_conversations, which also deals with conversations.
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 such as get_conversation or search_conversations. The description only states what it does, not the appropriate context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds no additional behavioral context (e.g., scraping behavior, rate limits, or optional sections). It neither contradicts annotations nor provides extra useful transparency.
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 states the core purpose without redundancy. Every word is informative and there is no wasted content.
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 the simple read-only nature, full schema descriptions, and presence of an output schema, the description is sufficient for an agent to select and invoke the tool. It does not need to explain parameters or return values since those are documented in the 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 coverage is 100%, with all three parameters fully described including defaults and examples. The description adds no parameter-level information beyond the target being a specific person's profile, which is already implicit in the tool name and 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 uses a specific verb ('Get') and a resource ('specific person's LinkedIn profile') that clearly distinguishes it from sibling tools like get_my_profile (self) and get_company_profile (company). The phrase 'specific person' implies a target username, making the tool's purpose unambiguous.
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 such as get_sidebar_profiles or search_people. There are no explicit exclusions, prerequisites, or context cues beyond the basic function of fetching a profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint: true and openWorldHint: true, which already signal a safe, potentially dynamic operation. The description adds minimal context (details for a specific posting) but doesn't contradict annotations. Given the bar is lower with annotations present and the description aligns without adding much extra, a 4 is appropriate for not contradicting and providing a basic scope.
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, front-loaded with the verb and resource, and contains no wasted words. It is appropriately sized for a simple one-parameter tool.
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 single-parameter tool with full schema coverage and an output schema present, the description is adequate. It states the resource and scope but doesn't elaborate on what 'details' include; however, the output schema would presumably cover that, and the sibling context is clear enough. A 4 is justified as it's complete enough for the tool's simplicity.
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 clear description for job_id including examples. The description adds no extra parameter semantics beyond the schema, but with full schema coverage the baseline is 3. It doesn't compensate with additional usage hints, but the schema is self-sufficient.
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 states it retrieves job details for a specific LinkedIn job posting, using the clear verb 'Get' plus the resource 'job details' and scope 'for a specific job posting on LinkedIn.' It is clear but does not explicitly differentiate itself from sibling tools like search_jobs or get_saved_jobs, though the focus on a single job posting is implied.
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 a use case: when you have a specific job ID and need full details. However, it does not explicitly state when to use this versus search_jobs or get_saved_jobs, nor does it mention any exclusions or prerequisites beyond the job_id parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by explicitly stating that MCP clients will prompt for user confirmation due to the destructiveHint. This helps the agent anticipate the user interaction. No contradiction with 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 brief and front-loaded with the core action in the first sentence, followed by a relevant note about the destructive annotation. Every sentence contributes value, with no fluff.
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 is simple, the schema documents all parameters, and annotations cover safety. The description provides purpose and the confirmation behavior. It lacks mention of how the tool decides between sending and accepting, but that may be determined by context (e.g., presence of an incoming request). Overall adequate.
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 both parameters (linkedin_username and note), so the description does not need to add parameter details. It adds no extra meaning beyond what the schema already provides, which is acceptable given the high 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's function: sending a LinkedIn connection request or accepting an incoming one. It uses a specific verb and resource, distinguishing it from sibling tools like send_message or get_inbox.
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?
Usage is implied by the description: use this tool to connect with someone on LinkedIn. However, there is no explicit guidance on when to prefer this over alternatives or exclusions (e.g., when to use send_message instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds 'recent' and company scope but does not disclose pagination or the meaning of 'recent', which would be useful behavioral 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?
A single sentence that directly states the purpose with no filler. It is front-loaded and every word 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?
This is a simple one-parameter tool with an output schema and read-only annotations. The description covers the essential behavior; missing disambiguation against siblings is more of a usage guideline concern.
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 only parameter, company_name, is fully described in the schema with examples. The description adds little beyond that, but with 100% schema coverage, the baseline of 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 identifies the action (get), resource (recent posts), and scope (company's LinkedIn feed). It distinguishes from siblings like get_feed or search_posts by specifying the company feed.
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 use when a company's recent posts are needed. It does not explicitly contrast with alternatives like search_posts or get_feed, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by explaining the redirect resolution and that the returned URL is the real profile URL rather than /in/me/. This discloses a non-obvious behavior about how the tool works.
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 two sentences long, front-loaded with the primary purpose, and includes only the necessary detail about the redirect behavior. 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?
The description covers the key behavioral nuance (redirect resolution) and the schema covers parameters. With an output schema present, the description does not need to detail return values, making it complete for the tool's complexity.
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 both parameters (sections and max_scrolls) having detailed descriptions. The tool description does not add parameter information, but the baseline of 3 is appropriate since 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 action ('Get') and the specific resource ('authenticated user's own LinkedIn profile'), which distinguishes it from sibling tools like get_person_profile. The phrasing 'own' and 'authenticated user' unambiguously identifies the target.
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 word 'own' implies the tool is for the authenticated user's profile, while get_person_profile is likely for others, but there is no explicit when-to-use or exclusion. The description provides context but leaves the comparison to siblings implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds that only job_ids are returned, which is useful, but it does not discuss pagination, result limits, or the open-world nature of results beyond what annotations imply.
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 two concise sentences, front-loaded with the action ('Search for jobs') and immediately providing the key return behavior. No filler or redundant content.
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 rich input schema, output schema, and strong annotations, the description is sufficient for an agent to understand the tool's role. The link to get_job_details is valuable; a minor gap is the lack of explicit pagination guidance, but the max_pages parameter covers 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?
All 9 parameters are fully documented in the input schema (100% coverage), so the description does not need to compensate. It adds no additional parameter context beyond what the schema already provides.
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 states 'Search for jobs on LinkedIn' with a specific verb and resource, and clarifies that it returns job_ids for get_job_details. This distinguishes it from sibling tools like search_companies and get_job_details, which serve different purposes.
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 points to get_job_details as the follow-up for full info, implying search_jobs is for discovery and initial listing. However, it does not mention when not to use it or alternatives like search_companies, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already declares destructiveHint=true, and the description adds the behavioral detail that it 'cleans up resources,' which goes slightly beyond the annotation. However, it does not disclose what specific resources are cleaned or that the session becomes invalid after this call. This is adequate but not rich given the destructive nature.
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, well-structured sentence of ten words. It is front-loaded with the primary action and resource, and every word adds meaning. No filler or redundancy exists.
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 zero-parameter tool with a destructive annotation and an output schema, the description covers the essential purpose (closing the session) and behavioral detail (cleaning up). The output schema can handle return values, and the annotation covers destructiveness. The description is complete for this simple tool.
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 the input schema is empty, so schema coverage is trivially 100%. With no parameters to describe, the description does not need to add parameter semantics, and the baseline of 4 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 action ('Close') and the resource ('the current browser session'), plus an additional consequence ('clean up resources'). This unambiguously distinguishes it from all sibling tools, which are about profiles, searches, messaging, and feeds, not session management.
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 (close the session when done), but does not explicitly state when to call this tool versus alternatives, nor does it provide any exclusions or prerequisites. Since there are no sibling tools for session management, the intended use is obvious, but the guidance is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description is consistent. The description adds the 'authenticated user' scope but does not disclose additional behaviors like batching, which is covered by the schema. It contributes minimal behavioral context beyond the 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?
One sentence, front-loaded with the 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 simple read tool with one optional parameter, an output schema, and read-only annotations, the single-sentence description is sufficient. It names the exact feed and leaves parameter details to the 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?
The single parameter num_posts is fully documented in the input schema, including default, range, and batching behavior, so the description adds no additional semantics. The description doesn't mention the parameter at all, but schema coverage is 100%, so 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 uses a specific verb 'Get' and identifies the resource as 'posts from the authenticated user's LinkedIn feed', clearly distinguishing it from sibling tools like get_company_posts or search_posts.
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 clearly establishes the context (authenticated user's feed) but does not explicitly discuss when to avoid this tool or mention alternatives. It implies that company or search posts are different use cases, but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint, openWorldHint), the description adds the specific constraint that the recipient must be directly messageable, which is a key behavioral limitation. It also reiterates the write condition tied to confirm_send, giving the agent a clearer picture of side effects. This adds value beyond the structured 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 two sentences, with the primary action front-loaded. Every sentence serves a purpose: the first states what the tool does, and the second provides essential conditions. There is no redundancy or filler, making it highly efficient.
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 output schema, full parameter descriptions, and annotations, the description provides sufficient context. The key limitation (messageability) is explicitly stated, and the write condition is clarified. While it could have elaborated on failure modes or alternative tools, the overall tool definition is adequately complete with the schema and annotations covering the rest.
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%, so the baseline is 3. The description does not add information about parameters beyond what the schema already explains (e.g., confirm_send's role is fully documented). While the main description mentions confirm_send, it adds no new semantic detail, so no bonus is warranted.
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: 'Send a message to a LinkedIn user.' This uses a specific verb ('send') and resource ('message to a LinkedIn user'), distinguishing it from sibling tools like get_inbox or search_conversations. No other tool in the sibling list performs a send action, making the purpose unambiguous.
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 provides clear context by stating that the recipient 'must be directly messageable from the profile page,' which indicates a precondition for use. It also clarifies that the operation is a write only when confirm_send is True. However, it does not explicitly name alternatives or when to prefer another tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior, and the description complements this by specifying the authenticated user scope and the output type (job_ids). It adds practical context about how the return value is used, going beyond the bare annotations without contradicting them.
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 two sentences with no filler. The main purpose is front-loaded in the first sentence, and the second sentence provides useful follow-up usage guidance. Every word 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 list tool with an output schema (per context), the description sufficiently explains what it returns and how to proceed. It is complete for the tool's complexity, and the sibling tool list does not introduce ambiguity that needs addressing.
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 provides a fully descriptive parameter (max_pages) with range and default, so schema coverage is 100%. The description does not add any semantic detail beyond the schema, but also does not need to, making a baseline score of 3 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 action ('List'), the resource ('job postings saved by the authenticated LinkedIn user'), and the scope (authenticated user's saved jobs). It distinguishes itself from siblings like search_jobs and get_job_details by specifying the 'saved' aspect.
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 provides clear usage context by noting that it returns job_ids for use with get_job_details, implying a workflow. However, it does not explicitly state when not to use this tool compared to search_jobs or get_job_details, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly=true and openWorld=true, lowering the bar. The description adds meaningful behavioral details: it follows 'Show all' links to return full lists and skips sections that redirect to linkedin.com/premium. These are non-obvious behaviors that help an agent predict the tool's output and limitations.
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 compact and front-loaded: the first sentence gives the core purpose, and the second sentence adds necessary behavioral details. Every word serves a purpose, with no redundancy or fluff.
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 tool with a single parameter and an output schema (available but not shown), the description is remarkably complete. It explains exactly what sections are targeted, how 'Show all' is handled, and that premium-redirecting sections are skipped. Given the tool's simplicity, no further context is needed.
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 single parameter (linkedin_username) with examples, achieving 100% coverage. The description does not add any additional semantic meaning about parameters beyond what the schema provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Get profile links from sidebar recommendation sections on a LinkedIn profile page.' It names the specific sections ('More profiles for you', 'Explore premium profiles', 'People you may know'), making the resource highly specific and distinct from sibling tools like get_person_profile which focuses on the main 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 clearly implies when to use the tool (when sidebar recommendations are needed) but does not explicitly state alternatives or exclusions. It lacks phrases like 'use this instead of X' or 'do not use when Y', so it only provides implied usage context rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds behavioral context by explaining global search scope and contrast with feed/company posts. It does not contradict annotations and provides useful contextual behavior beyond the structured hints.
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 three sentences long, front-loaded with the core purpose, then usage guidance, and finally sibling differentiation. Every sentence earns its place with no redundancy or filler.
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 the presence of an output schema, the description does not need to explain return values. It covers the core function, typical use case, and sibling tool distinctions, making it complete for a search tool with strong schema support.
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 has 100% coverage with detailed descriptions for all parameters, including the infinite scroll semantics of max_pages and accepted spellings for date_posted. The description itself adds no additional parameter information, so the baseline of 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's function: 'Search LinkedIn posts/content globally by keyword' and identifies the specific resource ('Posts' tab). It also distinguishes itself from sibling tools like get_feed and get_company_posts, making its purpose unambiguous.
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 provides a use case ('catch informal hiring posts... before a formal job listing exists') and names alternatives ('distinct from get_feed and get_company_posts'), giving the agent clear guidance on when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations readOnlyHint=true and openWorldHint=true, the description adds valuable context beyond them: the demographics expose locations, education, and function breakdowns; the keywords filter behavior; and the critical caveat that company_name must be the exact URL slug, not the display name (with Anthropic example). This enriches the agent's understanding of tool behavior.
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 well-structured and front-loaded: first the purpose, then usage alternatives, then parameter specifics. Every sentence carries essential information, with no fluff. The slug example is concise but effective. It is appropriately sized for the tool's complexity.
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 the presence of an output schema and annotations, the description is complete enough. It covers purpose, when to use alternatives, parameter semantics, and a critical edge case (slug mismatch). Nothing essential is missing for the agent to select and invoke the tool correctly.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that company_name must be the exact LinkedIn URL slug with a concrete example ('anthropicresearch' not 'anthropic'), and clarifies that keywords filters by name/title/skill. This goes beyond the schema's simple field descriptions.
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 states a specific action ('List employees at a company') and a specific resource (the LinkedIn /people/ page), and further distinguishes itself from siblings by noting the demographics aggregate is 'unique to this tool.' This clearly differentiates it from search_people and other sibling tools.
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?
Explicit guidance is provided: 'For filtered search by network degree (1st/2nd/3rd) or location, prefer search_people with current_company set to the company URN id.' It also recommends calling search_companies when the slug is uncertain. This gives clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only include openWorldHint: true, which is a minimal signal. The description goes beyond this by disclosing that looking up by username involves click-visiting matching rows and 'may mark it as read.' It also explains why this is necessary (no hrefs in LinkedIn's sidebar). This is a significant behavioral disclosure that the annotation alone does not provide.
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 appropriately sized for the complexity of the tool. It is front-loaded with the core purpose, then explains the two lookup paths and their trade-offs. Every sentence earns its place, and the structure is logical and easy to follow.
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?
The description fully covers the tool's behavior given its complexity: both lookup methods, side effects, and the alternative search tool. It has an output schema, so return values need not be described. The only minor omission is the lack of an explicit conflict rule when both parameters are provided, but the phrase 'Provide either' implies exclusivity and the schema does not list both as required.
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?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the resolution process for linkedin_username and clarifying that index is a selector when multiple threads exist, tied to the username lookup. It also connects thread_id and linkedin_username as alternative identifiers, which goes beyond the individual parameter descriptions.
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 function: 'Read a specific messaging conversation.' It distinguishes itself from siblings by specifying the two lookup methods (linkedin_username or thread_id) and by differentiating from search_conversations, which is for enumerating thread IDs. The verb 'read' and the resource 'specific messaging conversation' are concrete and unambiguous.
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 gives explicit usage guidance: provide either linkedin_username or thread_id. It names the alternative tool for enumerating thread IDs ('To enumerate thread IDs first, call search_conversations') and advises using thread_id directly to avoid the side-effect-prone username lookup. This clearly tells the agent when to use this tool and when to use a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![linkedin-mcp-server MCP server](https://glama.ai/mcp/servers/Jrudani21/linkedin-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Jrudani21/linkedin-mcp-server)

Score Badge

Copy to your README.md:

[![linkedin-mcp-server MCP server](https://glama.ai/mcp/servers/Jrudani21/linkedin-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Jrudani21/linkedin-mcp-server)

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

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