LinkedIn MCP Server

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true, but the description fails to explain what makes this destructive (irreversible publish? overwrite behavior?) or other behavioral traits like rate limits, required OAuth scopes, or partial failure modes. It relies entirely on annotations for the safety profile without adding contextual specifics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Highly inefficient structure that repeats the title content ('Share on LinkedIn, create a share post') verbatim before adding the actual useful clause. The dash-separated repetition wastes space that should have been used to explain the complex parameter requirements or destructive behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Inadequate for a tool with complex nested objects, destructive annotations, and no output schema. Fails to explain the LinkedIn URN format for author, the meaning of lifecycleState/visibility choices, or what successful creation returns. Leaves significant gaps for proper invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage and complex 4-level nested structure, the description inadequately compensates. While it mentions 'text, URLs, and images' (mapping to shareCommentary and media), it omits critical semantics: author URN format, lifecycleState options (PUBLISHED vs DRAFT), visibility constraints, and the required shareMediaCategory enum.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States specific action (create/share) and resource (LinkedIn post) clearly, mentioning content types (text, URLs, images). However, verbs are somewhat redundant with the tool name/title, and it doesn't explicitly distinguish from sibling getSharePosts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides no guidance on when to use versus alternatives (e.g., difference between public vs connections visibility), no prerequisites mentioned (like authentication requirements), and no warnings about the destructive nature implied by annotations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, non-destructive safety (readOnlyHint=true, destructiveHint=false). The description adds the scope qualifier 'basic' regarding what profile information is returned, providing minimal but valid behavioral context about the data payload without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description 'Get person profile - Get basic profile information for a person' is structurally wasteful, essentially repeating the same action twice with minor variation. While brief, the redundancy means not every clause earns its place, and it could be condensed to a single clause without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with no output schema, the description fails to explain the critical mechanism of resource identification—specifically, how the tool determines which person's profile to retrieve (e.g., current authenticated user). This omission leaves a significant functional gap despite the operation's apparent simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema contains zero parameters. Per the scoring rules, a tool with 0 parameters receives a baseline score of 4. The description is not expected to add parameter semantics when none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool retrieves 'basic profile information for a person' which adds slight specificity ('basic') beyond the tool name, but remains vague regarding which person is targeted given the lack of input parameters. It avoids being a complete tautology (like 'Gets the profile') but lacks the specificity to distinguish resource scope clearly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 its siblings (createSharePost, getSharePosts) or under what circumstances an agent should retrieve a person profile. There are no exclusions, prerequisites, or alternative selection criteria mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate read-only safety, but description fails to disclose behavioral details: no mention of pagination behavior (count/start parameters), filtering logic for 'authors', or what data structure is returned. Scope limitation to 'user or organization' is the only transparency provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence structure is efficient, but begins with redundant clause 'Get share posts -' that restates the tool name before the actual description, slightly wasting space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 3 undocumented parameters and no output schema, the description needs to explain parameter semantics and return values, but does neither. The scope clarification (user vs organization) is insufficient for a data retrieval tool with filtering capabilities.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage across 3 parameters, and the description adds zero compensating information. Does not explain that 'count/start' implement pagination, or what format 'authors' expects (comma-separated IDs? usernames?).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States the basic action (Retrieve) and resource (share posts) and specifies scope (authenticated user or organization). However, opens with tautology 'Get share posts' that restates the tool name, and does not explicitly differentiate from sibling createSharePost.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides no guidance on when to use this tool versus createSharePost or getPersonProfile. No mention of prerequisites, typical use cases, or when to avoid this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.