linkedin-mcp

by amankumar-2001

Overview Schema Source Related Servers Discussions Admin

Publish a link post on LinkedIn

create_link_post

Publish a LinkedIn post with a link card showing a title, optional description, and thumbnail. Confirm the post text with the user before publishing.

Instructions

Publishes a post with a link card (title, optional description and thumbnail). Confirm the exact text with the user first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "text": "<text>",
      "url": "<url>",
      "title": "<title>"
    },
    "name": "create_link_post"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	Link to share.
`text`	Yes	Post text. #hashtags are kept as hashtags; other formatting characters are posted literally.
`title`	Yes	Title shown on the link card (LinkedIn does not fetch it from the page).
`visibility`	No	PUBLIC (anyone) or CONNECTIONS (your 1st-degree network).	PUBLIC
`description`	No	Optional description shown on the link card.
`thumbnail_path`	No	Optional local PNG/JPEG/GIF to use as the link card image.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already cover mutability, open-world reach, and non-idempotency, so the bar is lower. The description adds one useful bit of behavior beyond them, the user-confirmation requirement, but says nothing about irreversibility, rate limits, or whether the post can be subsequently edited. The schema carries the visibility semantics, so this is an acceptable but thin add.

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, zero padding. The capability statement comes first and the safety instruction second, so an agent can read the essential behavior at a glance.

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

Completeness3/5

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

For a publishing tool with no output schema, the description never indicates what a successful call yields (a post ID, a URL, or a confirmation), which matters for a subsequent delete or edit. The pre-publication confirmation guidance partly compensates, but the picture is incomplete for the tool's complexity.

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

Parameters3/5

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

Schema description coverage is 100%, including the useful note that LinkedIn does not fetch the card title from the page, so baseline is 3. The description only surfaces title, optional description, and thumbnail - a subset of the six parameters - and adds no syntax or format detail beyond the schema.

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 names a specific verb and resource ('Publishes a post with a link card') and enumerates the card fields, which distinguishes it from siblings like create_text_post and create_image_post by implication. It stops short of naming those siblings explicitly, so the differentiation has to be inferred from the 'link card' qualifier.

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

Usage Guidelines3/5

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

The description gives a real procedural constraint, 'Confirm the exact text with the user first', which tells the agent how to sequence the call. It does not say when to prefer this over create_text_post or create_image_post, and there is no stated prerequisite such as authentication or required account permissions.

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

Deploy Server