LinkedIn MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific LinkedIn entities (company, group, job, post, profile) and actions (get vs. search). The naming and descriptions make it easy to differentiate between tools like get_post_comments and get_post_reactions, with no overlapping functionality.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with 'get_' for retrieval and 'search_' for search operations, using snake_case throughout. The naming is predictable and systematic across all 17 tools.
Tool Count4/5
17 tools is slightly high but reasonable for a comprehensive LinkedIn API covering multiple entity types and actions. It's well-scoped for the domain, though it could be streamlined by grouping related tools.
Completeness4/5
The toolset provides strong coverage for retrieving and searching LinkedIn data across key entities (profiles, companies, jobs, posts, groups). Minor gaps exist, such as no update/delete/create operations, but this is typical for a read-only data extraction server.
Average 3/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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 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?
No annotations are provided, so the description carries full burden. It mentions 'Returns cleaned data in TOON format' which adds some behavioral context about output formatting. However, it lacks critical details: whether this requires authentication, rate limits, what 'cleaned' means, if it's a read-only operation, or error conditions. For a tool with 4 parameters and no annotations, this is insufficient.
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 concise with two clear sentences. The first sentence states the core purpose, and the second adds important output format information. There's no wasted text. However, it could be slightly more structured by explicitly mentioning parameter relationships.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It mentions the output format ('TOON format') which helps, but doesn't cover authentication needs, error handling, parameter interdependencies, or what happens when multiple identification parameters are provided. The agent would struggle to use this correctly without trial and error.
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 schema already documents all 4 parameters thoroughly. The description adds no parameter-specific information beyond implying that parameters relate to identifying a company. It doesn't explain relationships between parameters (e.g., whether 'url', 'universalName', and 'search' are alternatives) or the purpose of 'save_dir'. Baseline 3 is appropriate when 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's purpose: 'Get LinkedIn company information' specifies the verb ('Get') and resource ('LinkedIn company information'). It distinguishes from siblings like 'search_companies' by focusing on retrieval of specific company data rather than searching. However, it doesn't explicitly contrast with 'get_company_posts' which retrieves posts instead of company info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'get_company' versus 'search_companies' (for finding companies) or 'get_company_posts' (for company posts). There are no prerequisites, exclusions, or context about which parameter combinations are valid.
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?
No annotations are provided, so the description carries full burden. It mentions 'Returns cleaned data in TOON format,' which adds some behavioral context about output formatting. However, it lacks critical details: authentication requirements, rate limits, error handling, or what 'cleaned data' entails. For a tool with no annotations, this is insufficient.
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 concise with two sentences that are front-loaded: the first states the purpose, and the second adds behavioral context. There's no wasted text, but it could be slightly more structured (e.g., separating usage notes).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 parameters, the description is incomplete. It mentions output format but doesn't explain what 'TOON format' is or provide examples. For a tool that returns data, more context on response structure and behavior is needed to be fully helpful to an agent.
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 schema already documents all three parameters (url, groupId, save_dir). The description adds no additional meaning about parameters beyond what's in the schema. It implies parameters are optional (since none are required) but doesn't clarify usage. Baseline 3 is appropriate when 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's purpose: 'Get LinkedIn group information' specifies the verb (get) and resource (LinkedIn group). It distinguishes from siblings like 'search_groups' by focusing on retrieval of specific group data rather than searching. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'get_group' versus 'search_groups' or other sibling tools, nor does it specify prerequisites or exclusions. The agent must infer usage from the name alone.
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?
No annotations are provided, so the description carries full burden. It mentions 'Returns cleaned data in TOON format', which adds some behavioral context about output transformation. However, it lacks critical details like whether this is a read-only operation, authentication requirements, rate limits, or error handling—important for a tool interacting with external APIs like LinkedIn.
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 very concise—two short sentences that are front-loaded with the core purpose. There's no wasted text, and it efficiently communicates key actions and outputs. However, it could be slightly more structured by explicitly separating purpose from output details for even clearer scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with external API interactions. It mentions TOON format but doesn't explain what that entails, and omits behavioral aspects like data sourcing, error cases, or usage constraints. For a tool fetching LinkedIn data, this leaves significant gaps for an agent to operate safely and effectively.
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 schema already documents all three parameters (jobId, url, save_dir) adequately. The description adds no parameter-specific information beyond what's in the schema, such as clarifying relationships between jobId and url, or explaining TOON format implications for save_dir. Baseline 3 is appropriate when 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's purpose: 'Get LinkedIn job details' specifies the verb (get) and resource (job details), and 'Returns cleaned data in TOON format' adds useful output context. However, it doesn't explicitly differentiate from sibling tools like 'search_jobs' or 'get_post', which would require 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 provides no guidance on when to use this tool versus alternatives. With siblings like 'search_jobs' available, there's no indication whether this is for retrieving specific known jobs versus searching, or any prerequisites for usage. This leaves significant ambiguity for an agent.
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?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, the description doesn't address important behavioral aspects like authentication requirements, rate limits, error conditions, or what 'cleaned data' specifically means. The mention of 'TOON format' is unexplained and adds confusion rather than clarity.
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 appropriately brief with two clear sentences. The first sentence states the core purpose, and the second provides output information. However, the unexplained 'TOON format' reference creates ambiguity that slightly reduces effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'cleaned data' includes, what 'TOON format' means, or provide any behavioral context about the operation. Given the complexity of LinkedIn data retrieval and the lack of structured metadata, more complete guidance 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?
With 100% schema description coverage, the schema already documents both parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain URL format requirements, what 'save_dir' actually does with the data, or provide examples. 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.
Purpose4/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 'LinkedIn post details', making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_post_comments' or 'get_post_reactions', which also retrieve post-related data but focus on specific aspects rather than general 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?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'get_post_comments', 'get_post_reactions', and 'search_posts', there's no indication of when this general post details tool is preferred over more specific ones or search functionality.
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?
No annotations are provided, so the description carries full burden. It mentions 'Returns cleaned data in TOON format' which adds some behavioral context about output formatting, but lacks critical details like whether this is a read-only operation, rate limits, authentication needs, pagination behavior beyond parameters, or what 'cleaned' entails. For a tool with 6 parameters and no annotations, this is insufficient.
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, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured by separating purpose from output details. Every part earns its place, but it's brief given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and no output schema, the description is incomplete. It mentions the output format ('TOON format') but doesn't explain what that means or provide behavioral context for a data-fetching tool. For a tool with moderate complexity and rich input schema, more guidance on usage and behavior 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?
Schema description coverage is 100%, providing clear documentation for all 6 parameters. The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline of 3. However, it doesn't compensate with additional context like explaining relationships between parameters (e.g., 'paginationToken' vs 'page').
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 verb ('Get') and resource ('comments on a LinkedIn post'), and specifies the output format ('cleaned data in TOON format'). However, it doesn't explicitly differentiate from sibling tools like 'get_profile_comments' or 'get_post_reactions', which target different resources or aspects of LinkedIn content.
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. With multiple sibling tools for LinkedIn data (e.g., 'get_post_reactions', 'get_profile_comments'), there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Returns cleaned data in TOON format,' which adds some context about output formatting, but fails to address critical behavioral aspects like whether this is a read-only operation, authentication requirements, rate limits, pagination behavior beyond the schema, or what 'cleaned data' entails.
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 extremely concise with just one sentence that efficiently states the core purpose and output format. It's front-loaded with the main action and resource, with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain the relationship between 'profile' and 'profileId' parameters, doesn't clarify what 'TOON format' means, and provides no context about the tool's behavior, error handling, or typical use cases. The description leaves too many open questions for effective agent use.
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 schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. It mentions 'cleaned data' which relates to output, not input parameters. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get comments made by a LinkedIn profile.' It specifies the resource (LinkedIn profile comments) and the action (get/retrieve). However, it doesn't explicitly differentiate from sibling tools like 'get_post_comments' or 'get_profile_posts,' which would require more specific scope clarification.
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. With sibling tools like 'get_post_comments' and 'get_profile_posts' available, there's no indication of whether this tool is for profile-specific comments, how it differs from post comments, or any prerequisites for use.
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?
With no annotations, the description carries full burden but provides minimal behavioral insight. It mentions 'Returns cleaned data in TOON format,' which hints at output structure, but doesn't disclose critical traits like rate limits, authentication needs, data freshness, or whether it's a read-only operation. For a tool with 6 parameters and no annotations, this is inadequate.
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 extremely concise—two sentences that directly state the tool's function and output format. Every word earns its place with no redundancy or fluff, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't cover key aspects like error handling, data limits (beyond max_items default), or what 'TOON format' entails. For a data-fetching tool with complexity, more context is needed to guide effective use.
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 parameters are well-documented in the schema. The description adds no additional parameter semantics beyond implying data retrieval and cleaning. It doesn't explain trade-offs (e.g., profile vs. profileId for speed) or interactions (e.g., paginationToken usage), but the schema provides a solid baseline.
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 reactions') and resource ('from a LinkedIn profile'), distinguishing it from siblings like get_profile or get_post_reactions. However, it doesn't explicitly differentiate from get_post_reactions (which targets posts rather than profiles), leaving some 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 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 like get_profile (which might return general profile data) or get_post_reactions (for reactions on posts). The description lacks context about prerequisites, such as needing a valid LinkedIn URL or ID, or when pagination is necessary.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Returns cleaned data in TOON format' which adds some value about output format, but doesn't cover important behavioral aspects like whether this is a read-only operation, rate limits, authentication requirements, pagination behavior beyond the 'page' parameter, or what 'cleaned' specifically entails.
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 extremely concise at just two sentences, with zero wasted words. It's front-loaded with the core purpose and follows with output format information. However, the brevity comes at the cost of missing important contextual information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the relationship between parameters, what 'TOON format' means, how results are structured, or provide any examples. The lack of output schema means the description should do more to explain what the tool returns.
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 provides no parameter-specific information beyond what's already in the schema. However, with 100% schema description coverage and all 7 parameters well-documented in the schema (including defaults for 'page' and 'max_items'), the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search LinkedIn companies') and the resource ('companies'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling search tools like search_groups, search_jobs, or search_profiles, which all search different LinkedIn entities.
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. With multiple sibling search tools available (search_groups, search_jobs, search_profiles, etc.), there's no indication that this tool is specifically for company searches rather than other LinkedIn entity types.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Returns cleaned data in TOON format,' which adds some context about the output format. However, it lacks details on rate limits, authentication needs, error handling, or whether this is a read-only operation (implied by 'Search' but not explicit). For a search tool with zero annotation coverage, this is insufficient.
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 concise and front-loaded: it states the core purpose in the first phrase and adds output format in the second. Both sentences earn their place by providing essential information without redundancy. It could be slightly more structured (e.g., separating purpose from output details), but it's efficient overall.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose and output format, but lacks behavioral details (e.g., safety, limits) and usage guidelines. With no output schema, the mention of 'TOON format' helps, but more context on what 'cleaned data' entails would improve completeness. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all three parameters ('search', 'save_dir', 'max_items') with descriptions. The description adds no additional parameter semantics beyond what's in the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
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 purpose: 'Search LinkedIn Geo ID by location (for location-based filtering).' It specifies the verb ('Search'), resource ('LinkedIn Geo ID'), and context ('for location-based filtering'). However, it doesn't explicitly distinguish this from sibling tools like 'search_companies' or 'search_profiles' beyond the 'Geo ID' focus, which is why it's a 4 rather than 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 provides minimal usage guidance. It mentions 'for location-based filtering' which hints at context, but doesn't specify when to use this tool versus alternatives (e.g., other search tools in the sibling list) or any prerequisites. There's no explicit 'when' or 'when not' guidance, leaving the agent to infer usage based on the purpose alone.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'cleaned data in TOON format' which provides some output context, but fails to describe critical behaviors: whether this is a read-only operation, rate limits, authentication requirements, pagination behavior (beyond the 'page' parameter), or what 'cleaned' entails. For a search tool with 17 parameters, this leaves significant gaps.
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 extremely concise - just one sentence that states the core functionality and output format. There's zero wasted language. However, the brevity comes at the cost of completeness, as it omits important contextual information that would help the agent use the tool effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex search tool with 17 parameters and no output schema, the description is inadequate. It doesn't explain what 'TOON format' means, doesn't describe the structure of returned data, provides no guidance on parameter combinations or search strategies, and offers no behavioral context. With no annotations and no output schema, the agent has insufficient information to use this tool effectively beyond basic parameter passing.
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, the schema already documents all 17 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the heavy lifting, though the description could have provided higher-level guidance about parameter combinations or typical usage patterns.
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 verb ('Search') and resource ('LinkedIn jobs'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_job' or 'search_companies', which would require explicit comparison. The mention of 'cleaned data in TOON format' adds specificity about the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_job' (likely for retrieving a specific job) and 'search_companies' (for company searches), the agent receives no help in choosing between them. There's no mention of prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that data is returned in 'cleaned data in TOON format', which adds some context about output formatting. However, it lacks critical details such as whether this is a read-only operation, potential rate limits, authentication requirements, or how pagination works (implied by the 'page' parameter). For a search tool with 13 parameters, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality (searching LinkedIn profiles) and includes key details (filtering criteria and output format). There is no wasted language, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values beyond 'cleaned data in TOON format', leaving the agent uncertain about the structure or content of results. For a search tool with many filtering options and no structured output, more context on behavior and results 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?
Schema description coverage is 100%, meaning all parameters are documented in the input schema. The description adds minimal value beyond the schema by listing 'name, company, location' as search criteria, which corresponds to some parameters (e.g., 'search', 'currentCompany', 'location'), but doesn't provide additional syntax or usage details. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches LinkedIn profiles by name, company, and location, and returns cleaned data in TOON format. It specifies the verb ('search'), resource ('LinkedIn profiles'), and scope (filtering criteria). However, it doesn't explicitly differentiate from sibling tools like 'get_profile' or 'search_companies', which would be needed for a perfect score.
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_profile' (which might retrieve a single profile) or 'search_companies' (which searches companies instead of profiles). It mentions filtering capabilities but doesn't clarify scenarios or exclusions, leaving the agent to infer usage from the name alone.
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?
No annotations are provided, so the description carries full burden. It mentions 'Returns cleaned data in TOON format,' which adds some behavioral context about output formatting. However, it lacks details on permissions, rate limits, pagination behavior (beyond parameters), or what 'cleaned' entails, leaving gaps for a tool with 8 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get posts from a LinkedIn company page') and adds value with output format details. There is no wasted text, making it appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and no output schema, the description is minimal but covers purpose and output format. It lacks details on behavioral traits (e.g., auth needs, rate limits) and usage guidelines, making it adequate but with clear gaps for a data-fetching 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 schema fully documents all 8 parameters. The description adds no additional parameter semantics beyond implying company identification and data cleaning, which are already covered in schema descriptions. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 ('posts from a LinkedIn company page'), specifying the source and what is retrieved. It distinguishes from siblings like 'get_post' (single post) or 'get_profile_posts' (profile posts), but doesn't explicitly contrast with 'search_posts' (which might search across companies).
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 like 'search_posts' or 'get_company' (which might get company info, not posts). The description implies it's for company-specific posts, but lacks explicit context or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns cleaned data in TOON format,' which adds some context about output behavior. However, it doesn't disclose critical traits like whether this is a read-only operation, potential rate limits, authentication needs, or what 'cleaned data' entails (e.g., data transformation or filtering). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one sentence, front-loaded with the core purpose and no wasted words. Every part earns its place by stating the action, resource, and output format efficiently, making it easy to parse quickly.
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 moderate complexity (4 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and output format but lacks details on usage guidelines, behavioral traits, and parameter interactions. Without an output schema, it doesn't explain return values beyond 'cleaned data in TOON format,' leaving ambiguity. This makes it functional but incomplete for effective agent use.
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, so all parameters are documented in the schema. The description adds no additional meaning beyond the schema, such as explaining the 'TOON format' for the 'save_dir' parameter or detailing how 'max_items' interacts with pagination. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 verb ('Get') and resource ('reactions on a LinkedIn post'), specifying what the tool does. It distinguishes itself from siblings like 'get_post' (which likely gets post content) and 'get_post_comments' (which gets comments rather than reactions). However, it doesn't explicitly differentiate from 'get_profile_reactions', which might be similar but for profiles instead of posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention when to choose this over 'get_post' (which might include reactions) or 'get_profile_reactions' (for reactions on profiles rather than posts). The description lacks context about prerequisites or exclusions, such as needing a valid LinkedIn URL or authentication requirements.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Returns cleaned data in TOON format' which adds some context about output formatting, but doesn't cover important aspects like whether this is a read-only operation, rate limits, authentication requirements, pagination behavior beyond the parameters, or what 'cleaned data' entails. For a tool with 8 parameters and no annotation coverage, this is insufficient.
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 extremely concise - just two sentences that directly state the tool's purpose and output format. Every word earns its place with zero waste or redundancy. It's front-loaded with the core functionality and doesn't include unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters with full schema coverage but no annotations and no output schema, the description provides minimal but adequate context for a read operation. It specifies the resource (LinkedIn profile posts) and output format (TOON), which helps the agent understand what to expect. However, for a tool with multiple filtering options (time limits, pagination, max items) and data saving capability, more behavioral context would be beneficial.
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 schema already documents all 8 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It implies the tool retrieves posts from profiles, which aligns with the parameter names, but provides no additional syntax, format, or usage details for the parameters. Baseline 3 is appropriate when 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 posts') and resource ('from a LinkedIn profile'), with specific output format ('cleaned data in TOON format'). It distinguishes from siblings like get_profile (which likely gets profile info rather than posts) and get_post (which gets a specific post). However, it doesn't explicitly differentiate from get_profile_comments or get_profile_reactions, which are related but distinct operations.
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. With siblings like get_post (for single posts), get_profile_comments (for comments), and search_posts (for broader searches), the description offers no context on when this profile-specific post retrieval is preferred. The only implied usage is for getting posts from profiles rather than companies or groups.
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?
No annotations are provided, so the description carries the full burden. It mentions that data is 'cleaned' and returned in 'TOON format', which adds some behavioral context beyond basic search functionality. However, it lacks details on permissions, rate limits, pagination behavior (beyond the 'page' parameter), or what 'cleaned' entails, leaving gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core purpose and includes key output details, making it appropriately sized and easy to parse.
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 no annotations and no output schema, the description is minimal but covers the basic purpose and output format. It lacks details on behavioral traits, error handling, or comprehensive usage guidelines, which are needed for a search tool with multiple parameters. It's adequate but has clear gaps in 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?
Schema description coverage is 100%, so the schema fully documents all parameters. The description does not add any meaning beyond the schema, such as explaining the 'TOON format' in relation to parameters or providing usage examples. Baseline 3 is appropriate as the schema handles 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 verb ('Search') and resource ('LinkedIn groups'), and specifies the output format ('TOON format'). It distinguishes from siblings by focusing on groups rather than companies, jobs, posts, or profiles, though it doesn't explicitly contrast with other search tools like search_companies or search_profiles.
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. The description does not mention prerequisites, context for searching groups, or differentiate from sibling tools like get_group (which might fetch a specific group) or other search tools. Usage is implied by the name 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'returns cleaned data in TOON format,' which adds some behavioral context about output formatting. However, it doesn't disclose critical behaviors like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior beyond the parameters, or what 'cleaned data' entails specifically.
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 extremely concise with just one sentence that directly states the tool's purpose and output format. There's zero wasted language, and it's front-loaded with essential information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (14 parameters, no annotations, no output schema), the description is minimal but covers the basic purpose and output format. However, for a search tool with many filtering options and no output schema, it should ideally explain more about result structure, limitations, or typical use cases to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 14 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain TOON format or how parameters interact). With high schema coverage, the baseline is 3 even without param info in the description.
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 LinkedIn posts and returns cleaned data in TOON format, providing a specific verb ('search') and resource ('LinkedIn posts'). However, it doesn't explicitly differentiate from sibling tools like 'search_profiles' or 'search_companies' beyond the resource type, which prevents a perfect score.
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. With many sibling tools available (e.g., 'get_profile_posts', 'get_company_posts', 'search_profiles'), there's no indication of when this search tool is preferred over more specific retrieval tools or other search tools.
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?
With no annotations provided, the description carries full burden. It mentions 'Returns cleaned data in TOON format' which adds some behavioral context about output processing, but doesn't disclose rate limits, authentication requirements, data freshness, error conditions, or what 'cleaned' entails. For a tool with 7 parameters and no annotation coverage, this is insufficient.
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 sentences with zero waste. First sentence covers purpose and main parameters, second sentence covers output format. Perfectly front-loaded and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters with full schema coverage but no annotations and no output schema, the description is adequate but incomplete. It covers the basic purpose and output format but lacks behavioral details needed for a data retrieval tool (rate limits, authentication, error handling). The TOON format mention helps but doesn't fully compensate for missing context.
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 schema already documents all 7 parameters thoroughly. The description adds minimal value beyond the schema by mentioning the three primary input methods (URL, public identifier, profile ID) but doesn't provide additional context about parameter relationships, constraints, or usage patterns.
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 'LinkedIn profile information', specifying three input methods (URL, public identifier, or profile ID) and the output format (TOON format). It distinguishes from siblings like get_company or get_post by focusing specifically on profile data retrieval.
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 context by listing three input methods, but doesn't explicitly state when to use this tool versus alternatives like search_profiles or other get_* tools. No guidance on prerequisites, limitations, or specific scenarios is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jing-yilin/linkedin-mcp-server'

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