LinkedIn Automation MCP Server

by dzigi00

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.13.2
Disambiguation5/5
Each tool targets a distinct resource and action: profiles, searches, messaging, feed, session, etc. Even the messaging-related tools (search_conversations, get_inbox, get_conversation, send_message) have clear, non-overlapping purposes. No two tools appear to do the same thing.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (get_person_profile, search_jobs, send_message, close_session). The naming is predictable and easy to infer the function of each tool. Minor variations like 'connect_with_person' still fit the overall pattern.
Tool Count4/5
With 17 tools, the server is slightly above the ideal typical range of 3-15 but not excessive. Each tool covers a distinct aspect of LinkedIn automation, so the count is justified for the scope. It feels on the heavier side but still manageable.
Completeness4/5
The tools cover the primary LinkedIn automation domains: profiles (get, search), companies (search, profile, posts, employees), jobs (search, details), messaging (search, inbox, read, send), connections (send/accept), feed, and session management. Minor gaps exist such as no explicit 'reject connection' or 'create post', but these are not core for most automation workflows. Overall, the surface is well-rounded.
Average 3.8/5 across 17 of 17 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits beyond what annotations already state (readOnlyHint). It does not mention that the tool scrapes data, that the about page is always included, or that sections are optional. The schema provides this information, but the description itself adds no transparency.
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, front-loaded sentence with no redundant words. It is concise and communicates the core purpose efficiently, though it omits useful context that could enhance selection.
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 schema is rich with full parameter descriptions and an output schema exists, so the description does not need to explain returns. However, the description lacks usage context, exclusions, or any mention of optional sections, making it minimally complete for an agent's decision-making.
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 the schema already documents both parameters thoroughly, including examples for company_name and detailed format/default for sections. The description adds no extra parameter meaning, but the baseline of 3 applies because the schema does the heavy lifting.
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'), distinguishing it from siblings like get_company_posts or get_company_employees. However, it does not explicitly contrast with those siblings, relying on the tool name for differentiation.
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. There is no mention of prerequisites, use cases, or exclusions, and sibling tools are not referenced. The agent receives no selection help beyond the tool 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?
The description adds no behavioral context beyond what the readOnlyHint and openWorldHint annotations already convey. It does not disclose that the tool scrapes LinkedIn pages, how pagination works, or that extra sections can be requested. The annotation covers safety, but the description offers no additional behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. It earns its place by adding the 'specific person' scope, differentiating from other profile-related tools. It is appropriately sized for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a well-structured schema and an output schema, so the description need not explain return values. However, the one-line description lacks context about usage scenarios, such as when to request extra sections or adjust max_scrolls, leaving the agent to rely on schema details. It is minimally complete but misses higher-level guidance for selecting among siblings.
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 description itself says nothing about parameters, but the input schema has comprehensive descriptions for all three parameters, including examples for linkedin_username and detailed explanations of sections and max_scrolls. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'Get' and the resource 'specific person's LinkedIn profile', distinguishing it from sibling tools like search_people (search) and get_my_profile (own profile) by emphasizing a specific known person. Even without naming alternatives, the scope is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It does not mention prerequisites (e.g., needing a LinkedIn username), exclusions, or related tools like search_people for finding usernames or connect_with_person after viewing a profile.
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 traits beyond the annotations (readOnlyHint, openWorldHint). It does not mention return behavior, pagination, rate limits, or any search nuances. Since annotations already cover safety, the description contributes nothing extra.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It is front-loaded with the action and resource. This is efficient for a tool with a rich schema.
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 minimal but sufficient for a read-only search tool given the rich schema, annotations, and output schema. However, it lacks usage context or any mention of the tool's capabilities beyond basic searching, making it somewhat under-specified for a tool with this 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?
The description adds no parameter-level information, but the input schema has 100% coverage with detailed descriptions for all four parameters. The baseline of 3 is appropriate; the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for people on LinkedIn, using a specific verb ('search') and resource ('people'). It distinguishes from sibling tools like search_companies and search_jobs, though it lacks additional scope details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or the intended search scenarios. The description simply states the action without 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 annotations. It does not disclose result format, pagination, or any limitations. With readOnlyHint and openWorldHint already declared, the description contributes no additional transparency.
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, clear sentence with no unnecessary words. It is concise and front-loaded, 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?
Given the simple one-parameter schema, the presence of an output schema, and read-only/open-world annotations, the description is minimally adequate. The primary gap is the lack of usage guidance relative to sibling tools, which keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the keywords parameter is 100%, so the description does not need to explain it. The description adds no extra meaning beyond the schema, meeting the baseline for a well-documented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and resource ('companies'), which clearly distinguishes it from sibling tools like search_people and search_jobs. The phrase 'on LinkedIn' provides context, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios where a different search tool would be more appropriate.
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 declare readOnlyHint=true and openWorldHint=true, which already cover the safety profile. The description adds no additional behavioral context beyond the schema, and it does not contradict the annotations. However, the schema's parameter description for 'limit' mentions that enumeration may mark messages as read, a side effect not reflected in the description, which prevents a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or repetition. It conveys the core purpose efficiently and earns its place without unnecessary detail.
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 search tool with an output schema and full parameter descriptions, the minimal description is mostly adequate. However, it does not clarify the scope of the search (e.g., across all conversations or current inbox) and omits the side-effect warning found in the schema. These gaps are minor given the simplicity, but prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'keywords' and 'limit' fully documented. The description adds no extra meaning for parameters beyond what the schema already provides. This aligns with the baseline score for full 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 'Search messages by keyword' clearly states the tool's action (search) and resource (messages), which is sufficient and distinct from sibling tools like search_people or get_conversation. However, it does not explicitly differentiate from alternatives such as get_inbox or get_conversation, so it lacks the extra distinction that would earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There is no mention of use cases, exclusions, or context where other tools would be more appropriate. The existence of get_inbox and get_conversation suggests potential overlap, but the description does not address it.
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 description explicitly references the destructiveHint annotation and explains that MCP clients will prompt for confirmation, adding context beyond the raw annotation. However, it does not disclose other behavioral details such as rate limits or side effects on profile visibility.
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: one stating the action and one explaining the annotation behavior. 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?
For a simple two-parameter tool with an output schema, the description adequately covers the core purpose. It could optionally mention the acceptance flow or edge cases, but it is not incomplete enough to warrant a lower score.
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?
Both parameters are fully documented in the schema with examples (linkedin_username, note), and schema description coverage is 100%. The description adds no extra parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a LinkedIn connection request or accept an incoming one,' 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 conveys the general context (connection requests) but does not explicitly mention when to use it versus alternatives like send_message. It implies usage without defining exclusions or alternative scenarios.
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, establishing the tool's safe, read-only nature. The description adds the 'recent posts' scope but does not disclose behavioral details like result limits, ordering, pagination, or authentication needs. It aligns with annotations without 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?
The description is a single sentence of 10 words, front-loading the core action. It wastes no words and is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, read-only, output schema present), and the description covers the essential 'what'. The 'recent posts' wording is slightly vague about recency windows, but the output schema and annotations fill most gaps, making the description adequate for its 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 coverage is 100%, with company_name fully described and provided with examples. The tool description adds no parameter details beyond the schema, so it does not compensate for any gaps. 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 ('Get') and resource ('recent posts from a company's LinkedIn feed'), clearly distinguishing it from sibling tools like get_company_profile or get_company_employees. The scope is 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 usage: when you want a company's recent posts. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites, leaving usage guidance 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, covering safety and dynamic nature. The description adds no extra behavioral traits beyond the core purpose. It does not contradict the annotations, but it also doesn't provide additional context like pagination or rate limits (though the parameter schema does).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with action and resource, with no redundant information. It is concise and 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?
For a simple read-only tool with one parameter, an output schema, and read-only annotations, the description is sufficient to understand what the tool does. It could have added a note about the feed being personalized or real-time, but that is largely covered by the openWorldHint annotation. Minor gap: not explaining that the feed is for the authenticated user only, though that's clear from the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter num_posts is fully described in the schema (coverage 100%), including default, range, and batch-loading behavior. The tool description itself adds no parameter details, but the schema does the heavy lifting, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get posts') and the exact resource ('the authenticated user's LinkedIn feed'). It distinguishes this from sibling tools like get_person_profile or get_company_posts by explicitly limiting to the user's personal 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 the tool is used to fetch the user's personal feed, but it does not explicitly state when to prefer this over alternatives (e.g., get_company_posts, search_conversations). No exclusions or alternative recommendations are provided.
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, which is a small behavioral detail, but does not disclose additional traits like pagination, sorting, or authentication needs beyond what annotations and output schema 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, front-loaded sentence that clearly states the verb and resource without any superfluous words. Every word contributes to understanding the tool's purpose.
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 list tool with one optional parameter, strong annotations, and an output schema, the description is almost complete. It misses only an explicit mention of alternatives or edge cases, but the overall context is sufficient given the structured data.
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 'limit' parameter with min, max, default, and description, so the baseline is 3. The description adds no additional meaning or context about how the parameter affects results.
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 a clear resource 'recent conversations from the LinkedIn messaging inbox', which clearly distinguishes it from siblings like get_conversation (single conversation) and search_conversations (search-based).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for browsing recent inbox conversations but provides no explicit guidance on when to prefer this tool over alternatives such as search_conversations or get_conversation. Context is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true and openWorldHint: true, covering the safety profile. The description adds no extra behavioral context such as response details, rate limits, or access requirements—it simply restates the tool's action. It is consistent with annotations but does not go 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, front-loaded sentence that directly states the tool's purpose. It contains no fluff, redundancy, or irrelevant details, making it an efficient and well-structured summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one well-documented parameter), existing annotations, and an output schema, the description is mostly complete for a read-only lookup. It does not explicitly mention any edge cases, access constraints, or how it relates to search_jobs, but these are not critical for basic use. Slight ambiguity in what 'job details' entails is mitigated by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the job_id parameter fully documented, including examples. The description adds no additional parameter-level meaning, so the baseline score of 3 applies per the rubric 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 uses the specific verb 'Get' and clearly identifies the resource as 'job details for a specific job posting on LinkedIn'. This is distinct from broader search tools like search_jobs, establishing a clear purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific job_id is known but provides no explicit guidance on when to prefer this tool over siblings like search_jobs, nor does it mention any prerequisites or alternatives. The context is implied by the name and single parameter, but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, so the description does not need to repeat that. It adds 'clean up resources,' which gives some context about what closing entails, but it does not specify the consequences (e.g., irreversible, invalidates session token) or prerequisites. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key action ('Close the current browser session') and includes a brief supporting clause ('and clean up resources'). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, destructive cleanup tool, the description is complete. It states the action and the effect. Since an output schema exists, there is no need to describe return values. The simplicity of the tool means no additional context is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema fully covers the input. The description adds value by specifying 'current browser session,' clarifying the scope of what gets closed. Since no parameters exist to explain, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Close the current browser session' with a specific verb and resource. It is unambiguous and distinguishes itself from all sibling tools, which are about data retrieval or messaging, not session management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 or when to avoid it. There are no alternatives mentioned, and no context about whether it should be called at the end of a workflow or as a cleanup step. This is a clear gap for a tool that is destructive.
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 that the tool click-visits rows and 'may mark it as read,' which indicates a side effect on state. This directly contradicts the annotation readOnlyHint: true, so the description contradicts structured metadata. Therefore, the behavioral transparency score is a 1 due to this 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?
The description is appropriately sized and front-loaded with a clear purpose statement. All subsequent sentences provide necessary procedural or contextual information, with no wasted words. It is structured logically from identification to mechanics.
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 moderate complexity, the description comprehensively covers lookup methods, behavioral side effects, parameter usage, and references to related tools. An output schema exists, so return values need no additional explanation. The only issue is the annotation contradiction, which is captured in the behavioral transparency dimension.
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?
Although schema description coverage is 100%, the tool description adds meaningful context beyond the schema. It clarifies the mutual exclusivity of linkedin_username and thread_id, explains the 'index' parameter's role in multi-thread scenarios, and provides procedural detail about the enumeration process.
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 explicitly states the tool reads a specific messaging conversation, using the verb 'Read' and resource 'messaging conversation'. It distinguishes this from siblings like search_conversations and get_inbox by focusing on retrieving a single conversation by identifier.
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 clearly instructs when to use linkedin_username versus thread_id, notes that thread_id skips the enumeration process, and references search_conversations for enumerating thread IDs. This gives explicit guidance on alternative tools and when to use each parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the provided annotations (readOnlyHint, openWorldHint), the description discloses additional behaviors: following 'Show all' links to get full lists and skipping sections that redirect to linkedin.com/premium. This gives the agent useful expectations about tool behavior and potential omissions.
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 and front-loaded with the core purpose. It uses two short paragraphs, each sentence adding specific value: naming the sections, explaining the 'Show all' behavior, and noting premium redirect handling. No unnecessary 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 (one parameter) and the presence of an output schema, the description is fairly complete. It explains what is extracted, how the extraction works, and one edge case (premium redirects). It could mention error behavior or the exact structure of returned links, but the output schema likely covers that. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already well-documented. The description doesn't add extra semantic detail beyond what's in the schema, so it meets the baseline but doesn't exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('profile links from sidebar recommendation sections'), clearly distinguishing it from siblings like get_person_profile. It names the exact sections targeted, 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 provides clear context for when to use the tool: to retrieve profile links from sidebar recommendation sections. It doesn't explicitly state when not to use it or name alternatives, but the context is strong enough for an agent to infer appropriate usage versus sibling tools.
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 openWorldHint=true, covering the safety profile. The description adds valuable context beyond annotations by specifying the return type (job_ids) and its intended use with get_job_details, which helps an agent understand the tool's role in a larger workflow.
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 only two sentences, front-loaded with the primary purpose ('Search for jobs on LinkedIn') followed immediately by the critical output detail. Every word serves a purpose with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 9 parameters, the schema exhaustively documents them, and the output schema handles return values. The description explains the tool's overall purpose and the practical next step (passing job_ids to get_job_details), making it complete for an agent to invoke correctly.
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 schema already provides full parameter semantics. The description does not add any parameter-level detail, but the baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for jobs on LinkedIn' with a specific verb and resource, distinguishing it from sibling search tools like search_people and search_companies. It also adds unique value by explaining the return type ('Returns job_ids') and suggests a downstream workflow via get_job_details.
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: use this tool to search for jobs and receive job IDs for further detail retrieval via get_job_details. It does not explicitly state exclusions or alternatives, but the job-specific scope is obvious given the tool name and sibling context, so the implied usage is strong.
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 include destructiveHint, and the description adds that this is a write operation gated on confirm_send=True, which is valuable conditional behavior. It disambiguates when the actual side effect occurs and does not contradict 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 short sentences: the first states the core action, the second adds a key precondition and side-effect condition. No filler or redundant phrase.
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 rich input schema (100% coverage, output schema present) and annotations, the description is complete enough. It conveys the essential prerequisite and write behavior without needing to restate schema 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 all four parameters already well-documented (including profile_urn bypass and confirm_send gating). The main description adds no extra parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Send') and resource ('a LinkedIn user'), clearly distinguishing the tool from read-only inbox/conversation tools and connection-request tools. The recipient-messageable constraint clarifies the intended action.
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 a clear precondition ('recipient must be directly messageable from the profile page') and notes the write-operation behavior. It does not explicitly name alternative tools, but the sibling set and schema guidance provide enough context.
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 reveals a significant behavioral nuance: it navigates to /in/me/ and resolves the redirect to obtain the real username, ensuring the url field returns the actual profile URL. This is valuable context that annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core purpose in the first sentence and the key behavioral detail in the second. Every sentence earns its place, with no tautology 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?
For a self-profile retrieval tool with an output schema and rich annotations, the description covers the essential nuance (redirect resolution) that could affect agent expectations. Parameters and return values are documented elsewhere, so nothing critical 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 input schema has 100% coverage with detailed descriptions for both 'sections' and 'max_scrolls', including examples and defaults. The tool description itself adds no parameter-specific details, so the schema carries the full burden. This matches 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 the tool's purpose: 'Get the authenticated user's own LinkedIn profile.' It uses a specific verb and resource, and the term 'own' distinguishes it from get_person_profile, which targets other people's profiles.
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 phrase 'authenticated user's own' implies it is for the current user rather than other people, providing clear context. However, it does not explicitly mention when to avoid using it or point to the sibling alternative get_person_profile, so some guidance is left implied rather than stated.
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?
With annotations already declaring readOnlyHint and openWorldHint, the description adds meaningful behavioral context: it exposes demographics unique to this tool, notes page-count limitations relative to search_people, and requires the exact LinkedIn URL slug rather than display name. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and remains efficient despite its length. Each sentence contributes essential information—unique demographics, sibling alternatives, page limits, exact slug requirement, and fallback guidance—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 output schema exists and annotations cover safety, the description offers complete contextual guidance: what the tool returns, how it differs from search_people, how to obtain the correct input, and what the keywords parameter does. No critical gaps remain for an agent to effectively select and invoke the tool.
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 schema coverage is 100%, the description significantly enriches parameter understanding. It explains that company_name must be the exact URL slug, provides a concrete counterexample (Anthropic's slug is 'anthropicresearch' not 'anthropic'), and clarifies the keywords filter scope, adding value beyond 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 states a specific action ('List employees at a company from the LinkedIn /people/ page') and clearly defines the resource and scope. It also distinguishes the tool from siblings by highlighting the unique demographics aggregate this view exposes.
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: when filtered search by network degree or location is needed, the description directs the agent to use search_people with current_company set, and notes that path returns more result pages. It also advises calling search_companies when the exact slug is uncertain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/dzigi00/linkedin-claude-automation'

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