MCP Server for LinkedIn

by bartest5

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v4.17.0
Disambiguation5/5
Each tool targets a distinct resource and action: messaging (get_inbox, search_conversations, get_conversation, send_message), profiles (get_my_profile, get_person_profile, get_sidebar_profiles), companies (get_company_profile, get_company_posts, search_companies, get_company_employees), jobs (search_jobs, get_job_details), and general actions (search_people, connect_with_person, get_feed, close_session). Even similarly named tools like get_inbox and get_conversation have clear boundaries.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case: get_, search_, connect_, send_, close_. The verbs are simple and the nouns clearly indicate the target resource, making the pattern predictable and easy to learn.
Tool Count4/5
With 17 tools, this is slightly above the typical 'sweet spot' of 3-15, but the count is justified by the broad scope of LinkedIn (profiles, companies, jobs, messaging, feed). Each tool serves a distinct function and none feel redundant, so the size is reasonable though a bit heavy.
Completeness4/5
The tool surface covers core LinkedIn workflows: searching and viewing profiles, companies, jobs, messaging, and feed. However, some common actions are missing, such as updating a profile, posting content, liking/sharing posts, or managing connections beyond sending requests. These gaps are workable but notable.
Average 3.8/5 across 17 of 17 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The main description is minimal, and annotations declare readOnlyHint=true, suggesting a safe read-only operation. However, the limit parameter's schema description states that each enumeration 'may mark it as read', which is a side effect that contradicts the readOnlyHint annotation. This is a serious inconsistency.
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 short sentence with no redundant wording. It is efficiently concise, though it could be slightly more informative without becoming verbose.
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 description is adequate for a simple search tool, and the schema plus output schema fill in some details. However, it lacks usage guidance and does not mention what the returned conversation references represent, leaving the overall picture incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters, including range, default, and a behavioral warning for limit. The main description adds no additional parameter meaning, so the baseline score of 3 applies given 100% schema coverage.
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 a clear action ('Search') and resource ('messages'), which aligns with the tool name. It does not explicitly distinguish from sibling search tools, but the resource is obvious enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives like get_conversation or search_people. The usage is implied by the name and description, but no when-to-use or when-not-to-use context is provided.
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 declare readOnlyHint and openWorldHint, but the description adds no extra behavioral context such as live scraping, rate limits, or what the profile includes. It merely restates what the tool does without depth.
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, clear sentence with no wasted words. It is appropriately concise 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?
While the schema and annotations cover parameters and safety, the description lacks usage guidance and does not clarify what 'profile' encompasses beyond the about page. The output schema likely covers return structure, but the description leaves behavioral gaps.
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 clear descriptions for company_name and sections. The description adds no parameter-specific meaning, but the schema already provides sufficient detail, so baseline 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 clearly states the action (get) and resource (specific company's LinkedIn profile). It distinguishes from siblings like get_company_posts by focusing on the full profile, but it doesn't explicitly name alternatives.
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 siblings such as get_company_posts or search_companies. It does not mention prerequisites or preferred use cases.
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 annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds no behavioral context beyond the basic action—it does not mention result limits, pagination, search scope, or any side effects. With no additional disclosure, it contributes minimal value 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?
The description is a single, clear sentence that states the tool's purpose with zero unnecessary words. It is front-loaded and appropriately sized for a simple search tool, ensuring every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with a fully documented schema, an output schema, and read-only annotations, the description is minimally sufficient. However, it lacks contextual guidance on how search results are scoped or when to prefer this tool over siblings like get_company_profile, leaving some ambiguity about its exact role.
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 parameter 'keywords' with a clear description and examples, achieving 100% schema coverage. The tool description adds no extra parameter meaning, but since the schema covers everything, a 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 clearly states the tool searches for companies on LinkedIn, using a specific verb (search) and resource (companies). It distinguishes from sibling search tools like search_people and search_jobs by explicitly naming the target entity, 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 Guidelines1/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. There is no mention of appropriate scenarios, exclusions, or comparisons with sibling tools such as get_company_profile or search_people, leaving the agent to infer usage context.
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 readOnlyHint and openWorldHint annotations. It does not mention that the tool performs live scraping, rate limits, or the impact of sections/max_scrolls parameters, which are only described in the schema. The description is consistent with annotations but contributes no extra 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?
The description is a single, clear sentence with no unnecessary words. It is efficiently front-loaded and conveys the core function without 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 complexity, the comprehensive input schema, output schema, and annotations compensate for the brief description. The description is sufficient for basic use, though additional context about live scraping or the meaning of 'specific person' could be helpful.
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 linkedin_username, sections, and max_scrolls. The description itself adds no additional parameter context, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a specific person's LinkedIn profile, which is a specific verb-resource pair. It does not explicitly differentiate from get_my_profile or get_company_profile, but the phrase 'specific person' implies a third-party profile, distinguishing it from those siblings.
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 connect_with_person. There is no mention of prerequisites, exclusions, or context that would help decide between this tool and siblings.
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 repeats the destructiveHint annotation without adding new behavioral context, such as what state changes occur or whether actions are reversible. It does mention the ability to accept incoming requests, which adds some clarity, but overall relies heavily on the annotation.
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 concise, with the main purpose in the first sentence and a brief note about the annotation in the second. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the essential purpose. It could mention any prerequisites or side effects, but the annotation handles the destructive warning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters well described in the schema itself. The description adds no additional parameter semantics beyond what the schema 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 clearly states the tool sends or accepts LinkedIn connection requests, using a specific verb and resource. This distinguishes it from sibling tools like send_message and search_people.
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 the tool is for connection requests but does not provide explicit guidance on when to use it versus alternatives, nor does it mention 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to restate those. It does add the context that the feed belongs to the authenticated user, which is useful. However, it offers no additional behavioral details like rate limits or pagination behavior, beyond what the schema's parameter description already provides.
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 clear sentence with no filler words. It directly states the purpose without redundant information, making it concise and well-structured.
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 read-only feed-fetching tool with strong annotations and a complete schema, the description covers the essential scope. The openWorldHint annotation and output schema handle dynamic content and return format. It could be more explicit about the absence of filters, but given the tool's simplicity, it is adequately 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?
The input schema fully documents the single parameter num_posts with range, default, and batching caveat, achieving 100% description coverage. The tool description adds no parameter-level meaning, so the baseline 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 clearly identifies the action (get), the resource (posts), and the scope (the authenticated user's LinkedIn feed). This distinguishes it from sibling tools like get_inbox or get_company_posts, which target different content types.
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 over alternatives, such as get_company_posts or get_sidebar_profiles. There are no usage scenarios, exclusions, or references to sibling tools, leaving the agent without selection criteria.
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, so the safety profile is covered. The description contributes the temporal scoping 'recent' but does not elaborate on how recent is defined, whether results are paginated, or any other behavioral nuances beyond what annotations 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 a single, well-structured sentence with no redundant information, making it highly concise and easy to parse. It front-loads the action and resource without 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?
Given the tool's simplicity, the presence of an output schema, and annotations for safety, the description provides the necessary essentials. It does not need to explain return values or elaborate on every use case, though it could be slightly more explicit about the list's ordering or recency definition.
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 only parameter 'limit' with clear constraints (1-50, default 20), and schema description coverage is 100%. The description itself does not need to add further parameter details, 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 uses a specific verb 'list' and identifies the resource as 'recent conversations' within the 'LinkedIn messaging inbox', clearly distinguishing it from sibling tools like get_conversation or search_conversations. This fully states 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?
There is no explicit guidance on when to use this tool versus alternatives such as search_conversations or get_conversation. The description only states the primary function, leaving the agent to infer appropriate use cases.
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 provide readOnlyHint=true and openWorldHint=true, which already indicate a safe read operation and potentially incomplete results. The description adds no additional behavioral context such as pagination, rate limits, or authentication requirements. It does not contradict the annotations, and the simple statement is consistent with the expected 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 a single, concise sentence: 'Search for people on LinkedIn.' It is front-loaded with the verb and resource, contains no unnecessary words, and perfectly communicates the tool's core purpose.
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 tool includes a comprehensive input schema with parameter descriptions and an output schema, so the description does not need to explain return values or parameter syntax. The description is complete for a fully specified search tool, and the annotations cover safety and open-world semantics.
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%, and each parameter has a detailed description in the input schema. The tool description adds no parameter-specific meaning, so it neither enhances nor detracts from the schema. Given the high coverage, a 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 clearly states the tool's function: 'Search for people on LinkedIn.' It uses a specific verb ('search') and resource ('people'), and distinguishes from sibling tools like search_companies and search_jobs by indicating the entity type.
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 any exclusions or alternative tools, leaving the agent to infer from the tool name and sibling list. The only alternative reference is in the current_company parameter description, but not in the main description.
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. The description adds a 'recent' scoping constraint but does not disclose recency limits, pagination, or authentication requirements. This is acceptable given the annotation coverage.
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 with no redundant content. It immediately conveys the tool's purpose and contains no filler.
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 one-parameter read-only tool with an output schema present, the description is nearly complete. It covers the core action and scope. Minor gaps like how 'recent' is defined or pagination behavior are not critical given the output schema and simple interface.
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 100% coverage for company_name with descriptive examples. The description adds no further parameter semantics beyond what the schema already includes, so a 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 retrieves recent posts from a company's LinkedIn feed, using a specific verb ('get') and resource ('company's LinkedIn feed'). It distinguishes itself from sibling tools like get_company_profile and get_feed by targeting company-specific posts.
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 the use case (retrieving company posts) but provides no explicit guidance on when to use this tool versus alternatives or any exclusions. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a side effect: 'Each visit selects the row in the LinkedIn UI and may mark it as read.' This directly contradicts the annotation readOnlyHint=true, which claims the tool performs no modifications. Per the scoring rules, a contradiction with annotations yields a score of 1, despite the description being otherwise transparent.
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 well-structured and front-loaded with the main purpose. The additional details about enumeration and click-visits are necessary for proper usage, but the paragraph is a bit dense. Every sentence earns its place, though it could be slightly more streamlined.
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 three optional params and a complex fallback mechanism, the description is thorough. It covers the enumeration fallback, the side effect of marking as read, the index selector behavior, and points to search_conversations for thread ID enumeration. It provides sufficient context even without needing to describe the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds significant meaning beyond the schema. It explains the relationship between linkedin_username and thread_id, clarifies that index is ignored when thread_id is provided, and describes the enumeration behavior. This enriches all three parameters beyond their basic schema 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 starts with 'Read a specific messaging conversation', which uses a specific verb and resource. It clearly distinguishes from sibling tools like get_inbox (list all conversations) and search_conversations (enumerate thread IDs), and explains the two identification paths.
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 states when to use the tool and how to choose between linkedin_username and thread_id. It also directs users to call search_conversations to enumerate thread IDs first, and explains when to pass thread_id directly, providing clear context and an explicit alternative.
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, which covers the safety profile. The description adds no extra behavioral context beyond the read-only nature, such as rate limits, scope, or return handling, but the output schema likely covers return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose. It is front-loaded with the main action and contains zero unnecessary words, making it highly concise and well-structured.
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 get-by-ID tool, the description is complete: the purpose is clear, the sole parameter is fully documented in the schema, annotations cover safety, and an output schema exists to define the return structure. Nothing essential is missing.
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 fully describes job_id with example LinkedIn IDs, achieving 100% coverage. The description's phrase 'specific job posting' adds little semantic value beyond what the schema already communicates, so the baseline score 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 retrieves details for a specific LinkedIn job posting, which is a specific verb+resource. It distinguishes from search-focused siblings like search_jobs by emphasizing 'specific job posting' rather than discovery.
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 usage when you have a specific job_id, and the schema's required parameter reinforces this. However, it does not explicitly name alternatives like search_jobs for finding jobs, leaving room for clearer guidance on when not to use this tool.
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 discloses it follows 'Show all' links to return full lists and skips sections redirecting to linkedin.com/premium, adding behavioral context beyond the given readOnlyHint and openWorldHint annotations. No contradiction.
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?
Three sentences, front-loaded with a clear summary, followed by relevant behavioral details. No redundant or unnecessary 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?
A single-parameter tool with an output schema and safety annotations. The description covers source sections, the expand behavior, and the skip rule, providing sufficient context for the tool's operation.
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 the single parameter linkedin_username fully documented including examples. The description adds no additional parameter semantics, so baseline 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 clearly states it retrieves profile links from specific sidebar recommendation sections on LinkedIn profile pages, naming three section types. This specific verb+resource combination distinguishes it from sibling tools like get_person_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?
No explicit when-to-use or alternative tool guidance is provided. Usage is implied by the description of the function, but it does not tell the agent when to choose this over get_person_profile or other siblings.
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 declare readOnlyHint and openWorldHint, but the description adds meaningful behavioral detail: it navigates to /in/me/, resolves redirects, and ensures the url field contains the real profile URL rather than a placeholder. This is valuable context beyond the annotations, though it doesn't cover every possible 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 two sentences: the first states the purpose clearly, and the second adds a crucial implementation detail. Every word earns its place, with no fluff or repetition.
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 presence of an output schema, 100% parameter coverage, and annotations, the description is sufficiently complete. It explains the one non-obvious behavior (URL resolution) that users need to know, and the schema covers 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?
The input schema already provides 100% coverage, with detailed descriptions for both sections and max_scrolls, including examples and defaults. The description adds no parameter-specific semantics beyond what the schema provides, so a 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 clearly states a specific verb and resource: 'Get the authenticated user's own LinkedIn profile.' It differentiates from sibling tools like get_person_profile by emphasizing 'own,' making the tool's scope 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 clearly indicates this is for the authenticated user's own profile, which implies when it should be used versus get_person_profile. However, it doesn't explicitly name an alternative or state when not to use it, stopping 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description adds valuable behavior: it returns job_ids rather than full details, and mentions these can be passed to get_job_details. This goes beyond the 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, front-loaded with the main action and followed by a useful note about output. Every word earns its place, with no filler or 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 rich input schema, output schema, and annotations, the description captures the essential purpose and output. It could mention pagination or result limits, but those are already in the schema, so the description remains sufficiently complete for an agent to select and invoke the tool.
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% description coverage for all 9 parameters, so the description need not repeat parameter details. The description adds no parameter-specific semantics, aligning with 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 clearly states 'Search for jobs on LinkedIn' with a specific verb and resource, distinguishing it from sibling tools like search_people and search_companies. It also notes the tool returns job_ids, further clarifying its role.
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 for when to use the tool (when searching for jobs) and implicitly directs to get_job_details for full job information. However, it does not explicitly state when not to use it or compare it to alternatives beyond the sibling names.
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 destructiveHint and openWorldHint, which already signal caution. The description adds value by specifying the write operation is conditional on confirm_send and highlighting the messageability prerequisite, giving the agent a clearer behavioral model 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?
The description is two sentences, front-loaded with the main purpose and containing only essential constraints. No filler or redundancy, making it easy for an agent to parse quickly.
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 presence of annotations, a detailed input schema, and an output schema, the description provides the key contextual constraint (direct messageability) and the conditional mutation behavior. It could mention what happens if confirm_send is False or the recipient is not messageable, but overall it is sufficiently complete for this 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%, and all parameters have meaningful descriptions. The tool description itself does not add parameter-level details, but since the schema fully documents each parameter, 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 action ('Send a message') and the target ('a LinkedIn user'), which distinguishes it from sibling tools like get_inbox or search_conversations. It is specific, concise, and immediately understandable.
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 an important usage condition ('recipient must be directly messageable from the profile page') and clarifies that sending only occurs when confirm_send is True. It does not explicitly name alternatives, but no sibling tool fulfills the same sending role, so this is adequate.
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 destructiveHint: true, and the description adds 'clean up resources,' which hints at side effects beyond just closing. It does not contradict the annotation and provides additional context about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded, with no wasted words. Every element ('Close', 'current browser session', 'clean up resources') contributes meaning.
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 tool is simple with no parameters and an output schema present (though not shown in the prompt). The description fully covers the purpose and basic behavior, and given the sibling context, no additional information is needed.
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, so the schema is complete. The description appropriately avoids adding unnecessary parameter details, and the baseline for no-parameter tools is a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Close') and resource ('current browser session') and adds 'clean up resources,' making the purpose unmistakable. It clearly distinguishes from all sibling tools, which are read/search/connect operations, none of which involve 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the action and scope ('current browser session') clearly, implying it is used when done with the session. There are no explicit alternatives or exclusions, but no sibling tool fulfills this role, so 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses the data source (/people/ page), the unique demographics view, and a behavioral limitation compared to search_people ('That path also returns more result pages'). It also warns about exact slug requirements with a concrete example, adding context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, with the core purpose in the first sentence. Each subsequent paragraph earns its place: alternatives, filter semantics, and a critical slug caveat. There is no redundant or filler 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 tool's complexity (exact slug requirement, optional filter, unique demographics) and the presence of an output schema, the description fully covers what the tool returns, when to use it, and pitfalls. It is complete for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already describes both parameters at 100% coverage, the description adds significant practical meaning: the company_name must be the exact LinkedIn URL slug, not the display name, and provides the Anthropic/anthropicresearch mismatch example. It also elaborates on the keywords filter scope.
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 'List employees at a company from the LinkedIn /people/ page' and highlights the unique demographics aggregate. It explicitly differentiates from sibling search_people by noting when to prefer the alternative.
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' and 'If you are unsure of the slug, call search_companies first'. This tells the agent exactly when to use alternative tools.
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:

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

Score Badge

Copy to your README.md:

[![stickerdaniel_linkedin-mcp-server MCP server](https://glama.ai/mcp/servers/bartest5/stickerdaniel_linkedin-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/bartest5/stickerdaniel_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/bartest5/stickerdaniel_linkedin-mcp-server'

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