Skip to main content
Glama
Sign In

LinkedIn MCP Server and API by Cotlet

by dev.cotlet
OverviewDiscussionsAdmin

Create post in LinkedIn

linkedin_create_post
Read-onlyIdempotent

Create post in the user's own LinkedIn account from ChatGPT, Claude or any AI agent. Returns how to do it in LinkedIn step by step (screens, buttons, fields) and opens nothing by itself; then do it with the cotlet_browser_* tools in the user's LinkedIn Cloud Browser. LinkedIn's official API: LinkedIn has an official API, but most of it needs an approved application (checked 6 Nov 2026).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "linkedin_create_post"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior4/5

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

The annotations declare readOnlyHint=true and destructiveHint=false, and the description explains why: it 'opens nothing by itself' and only returns guidance, which is valuable confirmation rather than contradiction. It also discloses the prerequisite of a LinkedIn Cloud Browser session and notes that LinkedIn's official API is largely gated behind an approved application. It stops short of describing the exact shape of the returned steps or any failure modes.

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

Conciseness3/5

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

The core message is front-loaded, but the middle clause is a semicolon-chained run-on and the closing API note ('checked 6 Nov 2026') is a dated aside that adds little for an agent choosing a tool. The content is relevant overall, yet it could be trimmed to two tight sentences without losing meaning.

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 zero-parameter guidance tool with no output schema, the description covers what it returns (step-by-step screens, buttons, fields), that it performs no action, and which sibling tools complete the task. The only gap is that it does not characterize the return format beyond 'step by step', which would help an agent plan the follow-up browser calls.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter meaning the description could add. The absence of parameters is itself consistent with the stated behavior of a guidance-only tool.

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 states a specific verb and resource (create a post on the user's own LinkedIn account) and immediately clarifies that the tool returns step-by-step instructions rather than performing the action, which resolves the apparent mismatch with the tool name. It distinguishes itself from the cotlet_browser_* siblings by naming them as the execution path. A slightly crisper opening sentence 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 Guidelines4/5

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

It explicitly tells the agent the workflow: call this first to get the screens/buttons/fields, then carry it out with the cotlet_browser_* tools in the user's LinkedIn Cloud Browser. That is clear context for when to use it and what to pair it with. It does not state exclusions (e.g., posting to company pages or other users' feeds), so it falls short of full when/when-not guidance.

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

All LinkedIn MCP Server and API by Cotlet toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources