Skip to main content
Glama

Reach MCP — LinkedIn for AI agents

create_post

Create or schedule a LinkedIn post, optionally with a media attachment. For a single image pass a urn:li:digitalmediaAsset:… URN; for multiple images pass a urn:li:fsd_multiPhoto:… URN from create_multi_photo. Set scheduled_at (Unix ms) to schedule; omit it to publish immediately. Publishes now or schedules (scheduled_time); counts against the daily posts quota. Show the user the full text before calling.

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": {
      "account_id": "<account_id>",
      "text": "<text>"
    },
    "name": "create_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesPlain text to send or post.
page_idNoAct as this company page instead of the member: page_id (or vanity name) from list_managed_pages. The account must be an admin of the page with a role that allows the action. Omit to act as the member.
media_urnNoOptional media URN to attach.
account_idYesReach id of the LinkedIn account to act on, from list_accounts.
visibilityNo'ANYONE' or 'CONNECTIONS_ONLY'.ANYONE
scheduled_atNoScheduled publish time in Unix milliseconds. Omit to publish now.
idempotency_keyNoOptional. A key you choose (a UUID is fine) that names this exact call. If you retry with the same key and the same arguments, the first call's result is returned and nothing is done twice on LinkedIn. Reusing a key with different arguments is refused. Keys expire after 24 hours.
allowed_commenters_scopeNo'ALL' or 'CONNECTIONS_ONLY'.ALL

Output Schema

NameRequiredDescriptionDefault
resource_keyNoIdentifier of the created or scheduled post

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / page_id
      Added value: +{
      +  "description": "Act as this company page instead of the member: page_id (or vanity name) from list_managed_pages. The account must be an admin of the page with a role that allows the action. Omit to act as the member.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, and the description adds non-obvious behavior beyond them: it consumes the daily posts quota and it publishes immediately unless a time is supplied. It does not cover failure modes (e.g., quota exhaustion, missing media permissions) or the retry/idempotency story, which the schema carries instead.

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?

Front-loaded with the action, then conditional detail (single vs multi image, schedule vs immediate), then constraints. Five short sentences, each carrying distinct information, with no restatement of the tool name.

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 an 8-parameter open-world mutation with an output schema and full schema coverage, the description supplies the quota accounting, scheduling semantics, media routing, and a confirmation requirement. Only edge-case behavior (quota-exceeded errors, page-admin failures) is left to the schema and server responses.

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?

Schema coverage is 100%, so the baseline is 3; the description earns above that by giving the actual URN formats for media_urn (urn:li:digitalmediaAsset vs urn:li:fsd_multiPhoto) and restating the scheduled_at unit and omit-to-publish-now semantics, which the terse schema field 'Scheduled publish time in Unix milliseconds' does not fully convey.

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 first sentence states a specific verb pair and resource ('Create or schedule a LinkedIn post') plus the optional media attachment, and the description explicitly routes multi-image cases to create_multi_photo, so an agent can separate this from the sibling tool without opening the schema.

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?

It names the alternative (create_multi_photo) with the exact condition that selects it, explains scheduled_at vs omitting it for immediate publish, and adds a procedural gate ('Show the user the full text before calling'). Little is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources