MCP Server for LinkedIn

by kaistenberg

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.20.1
Disambiguation5/5
Each tool targets a distinct resource and action: search_* tools are separated by entity (companies, jobs, people, conversations, posts), and get_* tools are separated by specific content (feed, company posts, job details, profiles, conversation). Even potentially similar tools like get_feed, get_company_posts, and search_posts have clear contextual differences described.
Naming Consistency5/5
All 19 tool names follow a consistent lowercase_with_underscores verb_noun pattern: get_*, search_*, send_*, connect_*, close_*. There is no mixing of styles or vague verbs, making the toolset predictable and easy to navigate.
Tool Count4/5
With 19 tools, the server is slightly above the typical 3-15 range but each tool addresses a real LinkedIn feature area (feed, jobs, messaging, people, companies, posts). No tools are redundant, and the count reflects the multi-domain scope of LinkedIn, so it feels reasonable rather than bloated.
Completeness4/5
The server covers core LinkedIn workflows: reading feed (own, company, global search), searching and retrieving profiles/companies/employees, job search and details, messaging (inbox, conversation, search, send), and connection requests. Minor gaps exist (e.g., no ability to post or like), but for a read/messaging/connection automation server, the surface is nearly complete.
Average 3.9/5 across 19 of 19 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 128 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds no additional behavioral context such as rate limits, data freshness, or how the sections parameter affects behavior, offering no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it highly concise and front-loaded. However, it is too terse to capture the full scope of the tool (e.g., sections), so it earns a high but not perfect score.
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?
With annotations, output schema, and complete parameter schema, the basic operation is clear. However, the description omits the fact that it can optionally scrape posts and jobs via the sections parameter, which could lead to confusion with get_company_posts. Thus it is adequate 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?
All parameter descriptions are provided in the input schema, including detailed explanations for the optional sections parameter. The description itself does not touch on parameters, but since schema coverage is 100%, the baseline of 3 applies without needing to compensate.
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 uses a specific verb 'Get' with a resource 'a specific company's LinkedIn profile', clearly indicating the primary function. However, it does not distinguish from sibling tools like get_company_posts or search_companies beyond the name, so it is clear but not explicitly differentiated.
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 get_company_posts or search_companies. There is no mention of scenarios or exclusions, leaving the agent to infer usage solely 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 indicate readOnlyHint and openWorldHint, and the description adds no additional behavioral context such as pagination, result limits, or authentication needs. It does not contradict annotations but fails to enhance them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action. It is efficient and free of fluff, though it borders on under-specification by omitting any additional useful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the existence of an output schema, the description is minimally adequate. It lacks context about limitations or distinctions from other search tools, making it sufficient but not thorough.
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 keywords parameter with an example, providing 100% coverage. The description adds no extra meaning about parameter usage or format, 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's function: searching for companies on LinkedIn, using a specific verb and resource. It distinguishes from sibling search tools like search_people and search_jobs by the resource type, though it lacks specificity about the search mechanism.
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, no exclusions, and no prerequisites. It simply states the action without context for selection.
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 description does not need to repeat read-only status. However, the description adds no behavioral context beyond the schema, such as how sections or max_scrolls affect scraping depth. With no extra context, it provides minimal additive 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, direct sentence with no filler or redundancy. It is front-loaded and easy to parse, ideal for quick scanning.
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 GET tool, the description combined with the rich schema and annotations covers the essentials. However, it doesn't mention the ability to scrape extra sections or control pagination, which are salient features; although these are fully documented in the schema, the description leaves the tool's full range hidden. It also lacks any mention of alternatives, making it slightly incomplete for contextual selection.
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% parameter coverage with detailed descriptions for linkedin_username, sections, and max_scrolls. The description itself adds no parameter semantics, but the schema carries the full burden, so a baseline 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 uses a specific verb ('Get') and resource ('a specific person's LinkedIn profile'), which is clear and distinguishes it from company/self/feed tools. It could be more explicit about using a LinkedIn username, but the schema clarifies that. It does not explicitly differentiate from search_people or get_sidebar_profiles, but the direct 'get' wording implies a targeted lookup.
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 about when to use this tool versus alternatives like search_people or get_my_profile. The one-sentence description implies basic usage but offers no exclusions, prerequisites, or alternative references, leaving the agent without context for selection.
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 discloses no behavioral traits beyond the openWorldHint annotation. The schema's limit parameter warns that enumerating rows may mark them as read, but the description omits this side effect, and no destructiveHint/readOnlyHint is present to compensate.
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 front-loaded sentence with no filler or redundancy. It is appropriately concise for a simple search 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?
Given the low complexity, 100% schema coverage, and presence of an output schema, the one-sentence description is minimally viable. It could be more complete by mentioning the read side effect or search scope, but the schema already covers parameter-level details.
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 limit's side effects and defaults well documented. The description adds only 'by keyword', which aligns with the keywords parameter, but no extra meaning beyond the schema is needed or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Search') and resource ('messages'), which distinguishes it from sibling tools like get_inbox or get_conversation. However, it doesn't explicitly mention 'conversations' as the output unit or contrast with search_posts, leaving slight ambiguity about scope.
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 guidance is provided. The name and sibling context imply it is the keyword search tool for messages/conversations, but the description does not say when to prefer it over get_inbox or get_conversation.
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 merely restates the purpose and adds no behavioral details beyond the annotations. Annotations declare readOnlyHint=true and openWorldHint=true, but the description does not mention result limits, pagination, or any search-specific caveats, so it fails to add informative value.
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 one-sentence description is immediate and free of extraneous words, effectively communicating the tool's core function in minimal space.
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, an output schema, and annotations indicating read-only and open-world behavior, the terse description is adequate to convey the tool's basic purpose. However, it omits any mention of search-specific behavior like result ordering or how to scope searches, though the schema covers filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, all four parameters (keywords, network, location, current_company) are already explained in detail. The description adds no additional semantic context, 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 clearly states the action (search) and the resource (people on LinkedIn), distinguishing it from sibling search tools like search_jobs and search_companies by specifying 'people'.
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_person_profile for direct profile lookups or search_companies for organizations. The only hint is the name, which implies people search.
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 the 'recent' qualifier and company focus, but doesn't disclose behaviors like time window limitation or pagination. This is consistent with annotations and adds modest context beyond 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 a single, well-structured sentence that front-loads the verb and resource. It contains no filler or redundant information, earning a top score for efficiency.
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 tool with one parameter and an output schema, the description is largely complete. It adequately communicates what the tool returns (company feed posts) and integrates with annotations. The only minor gap is the unspecified meaning of 'recent,' but this does not undermine overall 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 has 100% coverage—company_name is described with examples. The tool description offers no additional parameter detail beyond what the schema provides, so it meets the baseline but adds no extra semantic value.
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'), identifies the resource ('recent posts from a company's LinkedIn feed'), and clearly differentiates from sibling tools like get_feed (general feed) and search_posts (search-based retrieval). This is unambiguous and contextually distinct.
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 tool's purpose implies usage when company-specific posts are needed, but no explicit guidelines are given about when to prefer this over search_posts or get_feed. The description relies on inferred context from the name rather than stating exclusions or alternatives.
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 signal read-only and open-world behavior, so the description is not required to repeat that. It adds the 'recent' qualifier, which indicates ordering by recency, but does not provide further behavioral context like pagination, rate limits, or auth requirements. This is a modest addition beyond annotations, so a mid score is appropriate.
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, succinct sentence that immediately states the action and resource. It is front-loaded and contains no filler or redundant information, earning full marks for conciseness.
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?
This is a simple tool with one optional parameter, read-only/open-world annotations, and an output schema. The description clearly conveys the core purpose, and since an output schema exists, there is no need to detail return values. The combination of annotations, schema, and description provides a complete understanding for a straightforward listing 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?
The input schema fully describes the only parameter `limit` with a clear explanation including range and default (100% coverage). The description does not add any additional meaning about the parameter, so the baseline score of 3 is maintained.
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 the specific verb 'List' with the resource 'recent conversations from the LinkedIn messaging inbox.' This clearly defines the tool's scope and differentiates it from siblings like get_conversation (single conversation) or search_conversations (search-based). The mention of 'messaging inbox' distinguishes it from non-inbox tools like get_feed.
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 this is the tool for browsing recent inbox conversations, but it does not explicitly state when to use it versus alternatives such as search_conversations or get_conversation. There is no exclusion or mention of alternative tools, leaving the decision to the agent's inference from the sibling list.
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, so the description does not need to restate safety. However, the description adds no extra behavioral context (e.g., return format, live data implications, potential errors) beyond the purpose. It does not contradict 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, front-loaded sentence that directly states purpose. Every word earns its place, and there is 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?
With an output schema present and a single well-documented parameter, the description is sufficient for a simple get-by-id operation. The scope is clear, and the presence of an output schema means the description does not need to explain return values.
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%, and the description does not add meaning beyond the schema. The job_id parameter is well-documented in the schema with examples, so the description's mention of 'specific job posting' aligns but provides no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'job details' for a specific job posting, distinguishing it from search_jobs or get_saved_jobs. The use of 'specific' and the job_id parameter make 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving details when you already have a specific job ID, but it does not explicitly mention when to use it versus alternatives like search_jobs or get_saved_jobs. No exclusions or alternative references are provided.
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 destructiveHint and openWorldHint. The description adds valuable specificity by clarifying that the write operation only executes when confirm_send is True, and it highlights a real-world constraint (recipient must be directly messageable). This goes beyond the raw annotation 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?
Two clear sentences with no fluff. The first sentence states the action, the second gives the critical prerequisite and write condition. 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?
Given the tool's complexity (4 params, all documented) and the presence of an output schema, the description adequately covers the core behavior. It leaves typical implementation details to the output schema. A bit more about potential side effects or post-send behavior would make it perfect, but it is sufficient.
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 baseline is 3. The description itself does not add parameter-level semantics, but the schema already fully documents each parameter, including the profile_urn bypass behavior and the confirm_send requirement. No further explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a message to a LinkedIn user' with a specific verb and resource. This unambiguously identifies the tool's purpose and naturally distinguishes it from sibling tools like connect_with_person (connection requests) and get_inbox (reading messages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a prerequisite ('The recipient must be directly messageable from the profile page') and notes the write condition (confirm_send=True), but it does not explicitly contrast with alternatives or state when not to use it. The usage context is implied rather than fully spelled out.
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 destructiveHint annotation already flags the tool as destructive. The description adds 'clean up resources,' which gives some context about side effects, but it does not specify what resources are cleaned up (e.g., cookies, cache, local state) or whether the action is reversible. With the annotation covering the destructive nature, the added context is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word carries meaning, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no nested objects, output schema present, and a clear destructive annotation), the description is fully complete. It tells the agent what the tool does and the annotation covers the safety profile, leaving no critical gaps.
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 description does not need to explain parameter meanings. Per the rubric, a baseline of 4 is appropriate when no parameters are present, and the description adds nothing necessary beyond what the empty schema already conveys.
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 the current browser session') and the resource affected ('browser session'), with a specific verb and resource. It is unambiguous and distinguishes itself from all sibling tools, which are all read/social operations and none 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—you would call this when you are done with the browser session—but it does not explicitly state when to use it or mention alternatives. No exclusion or conditional guidance is provided, so the usage context is implied rather than explicit.
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, so the description doesn't need to repeat safety traits. The description itself adds no behavioral context beyond the purpose; the parameter schema mentions batch loading behavior, but that is not part of the description. Thus, the description provides minimal value 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 a single, front-loaded sentence that precisely states the tool's function. No unnecessary words or repetition, making it highly concise and effectively 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?
Given the tool's simplicity, existing output schema, and rich annotations, the one-sentence description is sufficient. The read-only annotation covers safety, the schema covers parameters, and the output schema covers return values, so the description fills the remaining purpose gap completely.
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% parameter description coverage, including default, min, max, and batch loading behavior. The tool description adds no extra parameter meaning. With full schema coverage, 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 a specific verb and resource: 'Get posts from the authenticated user's LinkedIn feed.' It distinguishes itself from siblings like get_company_posts (company feed) and search_posts (search), making the tool's purpose explicit.
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: it is for the authenticated user's own LinkedIn feed, not for company posts or search results. While it doesn't explicitly name alternatives or exclusions, the context is unambiguous enough for an agent to decide when to use it.
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 cover readOnlyHint=true, which is reinforced by the description's 'Search' action. The description adds behavioral context by explicitly stating that results contain only job_ids and that full details require a separate call, which helps set expectations about the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main purpose and a valuable cross-reference to get_job_details. No filler, 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?
Given the rich schema (100% parameter coverage) and presence of an output schema, the description provides sufficient context. It could mention pagination via max_pages, but the schema already covers that, so the description remains complete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 9 parameters having clear descriptions in the schema. The tool description itself adds no parameter-specific semantics, 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?
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 specifies the output format (job_ids) and points to get_job_details for full info, which further clarifies the tool's 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 implies when to use this tool (job searching) and guides the agent to get_job_details for full job information. However, it does not explicitly name alternative tools or state when not to use it, though the sibling names and context make this reasonably clear.
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, so the safety profile is covered. The description adds useful context about global search scope and purpose, but does not disclose behaviors like pagination/scroll depth or rate limits beyond what's in the schema. This is adequate but not exceptional.
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 the action, then targeted usage guidance. Every sentence earns its place with no fluff or repetition of schema details.
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 purpose, usage, and sibling differentiation. An output schema exists, so return value details are handled. It could mention the infinite-scroll behavior or open-world limitations (though the schema parameter notes it), but overall it is quite complete for a search 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?
Schema description coverage is 100%, so the structured fields already explain all three parameters. The description adds example search keywords, but does not add new semantic meaning beyond what the schema provides. 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 opens with a specific verb+resource+scope: 'Search LinkedIn posts/content globally by keyword'. It explicitly distinguishes from sibling tools get_feed and get_company_posts, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete when-to-use guidance: 'Use this to catch informal hiring posts' with example keywords. It also names exclusions by contrasting with get_feed and get_company_posts, telling the agent 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 explicitly references the destructiveHint annotation and explains that MCP clients will prompt for user confirmation before execution. This adds behavioral context beyond the annotation itself, though it does not discuss other side effects like notifications or rate limits.
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 core action, and every sentence earns its place. It is appropriately concise and easy to scan.
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 two-parameter tool with an output schema, the description covers the essential behavior and the important confirmation side effect. The schema handles parameter details, so no further explanation 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 has 100% description coverage, including examples for linkedin_username and a clear explanation of the optional note parameter. The tool description itself adds no parameter-level semantics, but the schema already carries that weight.
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 opens with a specific verb and resource: 'Send a LinkedIn connection request or accept an incoming one.' It clearly states the tool's action and target, and the dual send/accept behavior distinguishes it from sibling tools like send_message or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to send a new connection request or accept an incoming one. It does not explicitly name alternatives or exclusions, but the usage scenario is unambiguous.
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 provide readOnlyHint=true, and the description adds valuable behavioral context: it navigates to /in/me/, resolves the redirect, and ensures the url field is the real profile URL. This goes beyond the annotation by explaining the scraping process and expected URL 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 two sentences: a concise purpose statement followed by a relevant behavioral detail. No wasted words, and the key info is front-loaded.
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 simplicity, the presence of an output schema, and thorough schema param descriptions, the description fully covers the essential behavioral nuance (redirect resolution) without needing to explain return values or parameter details. It is complete for its complexity tier.
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 has 100% description coverage for both optional parameters, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema, but the schema itself is thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the authenticated user's own LinkedIn profile, using a specific verb and resource. It also distinguishes itself from sibling get_person_profile by emphasizing 'own profile' and the /in/me/ redirect behavior.
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 makes evident when to use it (for the current user's profile) without explicitly naming alternatives. It does not say 'use get_person_profile for others', but the context of sibling tools and the 'authenticated user's own' phrasing provides clear usage context.
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=true, so the read-only nature is known. The description adds behavioral context by explaining that the tool returns job_ids intended for use with get_job_details, which clarifies the output's role. This goes beyond what annotations provide, so a 4 is appropriate.
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 consists of two short, purposeful sentences. The first sentence states the primary function, the second adds a chaining hint. No redundant wording 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?
For a simple read-only list tool with one optional parameter and an output schema, the description fully covers what the tool does and how its result can be used. The annotations and output schema fill the remaining details, so no significant gaps exist.
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%, and the max_pages parameter is fully described in the schema. The description does not add extra parameter semantics, matching the baseline of 3 when the schema carries the load.
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 the specific verb 'List' with the resource 'job postings saved by the authenticated LinkedIn user', clearly defining the tool's scope. It distinguishes itself from sibling tools like search_jobs and get_job_details by focusing on saved postings specifically.
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 these are the user's saved jobs and explicitly mentions that returned job_ids can be passed to get_job_details. While it doesn't explicitly describe when not to use this tool, the connection to a sibling tool offers practical usage 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 and openWorldHint; description adds concrete behaviors: following 'Show all' links to return full lists, and skipping sections that redirect to linkedin.com/premium. 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?
Two-sentence description is front-loaded with purpose and includes only relevant behavioral details (section names, Show all behavior, premium skip). No 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?
For a simple one-parameter read tool with output schema, the description covers what, where, and edge-case behavior (premium redirects), making it self-sufficient.
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% and the lone parameter linkedin_username is clearly described in the schema. Description adds no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get profile links' and names exact sections ('More profiles for you', 'Explore premium profiles', 'People you may know'), clearly distinguishing it from sibling tools like get_person_profile or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the context: scraping sidebar recommendation sections from a LinkedIn profile page. It does not explicitly list when not to use or name alternative tools, but context is unambiguous.
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=true, and the description adds context that the /people/ page exposes a demographics aggregate unique to this tool. It also implies pagination differences vs search_people, though it does not disclose specific rate limits or pagination parameters. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured, with purpose first, followed by alternatives, then parameter-specific guidance. Every sentence adds value, though a bit dense; no 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?
Given an output schema exists and annotations cover safety, the description provides all necessary operational context: what it returns (employees + demographics), how to get the correct company identifier, when to choose an alternative, and keyword behavior. Fully complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description enriches the schema significantly by explaining that company_name must be the exact LinkedIn URL slug, provides an example, and warns that display names often differ. It also tells how to resolve ambiguity via search_companies. The keyword filter meaning is confirmed, adding practical nuance.
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 lists employees from the LinkedIn /people/ page, including unique demographics (location, school, function). It distinguishes itself from search_people by noting the demographics are unique to this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: prefer search_people for filtered search by network degree or location, notes that path returns more pages, and instructs to call search_companies if uncertain about the exact slug. 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 description discloses the non-obvious behavior of click-visiting rows and potential read-marking: 'Each visit selects the row in the LinkedIn UI and may mark it as read.' This goes well beyond the sparse openWorldHint 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 compact with three sentences, front-loading the purpose and delivering essential caveats without redundancy.
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 (two lookup paths and side effects), the description covers usage, rationale, and risks, making it self-sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema already covers all parameters (100% coverage), the description adds meaningful context about when to use each identifier and the index selector's role, enriching the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a specific messaging conversation' with a specific verb and resource, and distinguishes between username and thread_id lookup modes, setting it apart from siblings like search_conversations and 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on parameter selection: 'Provide either linkedin_username or thread_id' and 'Pass thread_id directly to skip this enumeration.' However, it doesn't explicitly name alternatives or exclusion criteria, relying on schema for cross-reference.
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:

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

Score Badge

Copy to your README.md:

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

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/kaistenberg/MCP-Linkedin'

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