Skip to main content
Glama

Nilyo

by com.nilyo
OverviewDiscussionsAdmin

LinkedIn: Create post

linkedin_create_post
Destructive

Publish a LinkedIn post from the user's own account, optionally on a managed company page using post_as. This is a public side effect; use only after the user has clearly approved the final content and target identity.

Input Schema

NameRequiredDescriptionDefault
textYesLinkedIn Classic mentions belong in text: @ followed by the resolved person's Classic ACo... ID or the company's numeric ID (for example @1441). Resolve people with linkedin_get_profile_from_url/linkedin_resolve_person and companies with linkedin_resolve_company/linkedin_search_companies; disambiguate every target before publishing. Never use a display name, profile URL, company slug, URN, Sales Navigator or Recruiter ID as a mention. Example after resolving both targets: 'Thanks @ACo_RESOLVED_MEMBER for working with @1441.' The API replaces each token with the target's name and mention metadata; no separate mentions field is needed. Approve the final text and mentioned identities before the write; never retry an ambiguous write automatically.
post_asNoExact managed page/company identity returned by linkedin_list_managed_pages; omit to post as the connected person. Never pass a company name or URL.
can_readNo
account_idNoOptional Nilyo connection ID (unipile_account_id from list_connected_accounts). Omit when the user has one account for this provider. When several exist, Nilyo never guesses: list them (display name, identifier, provider user ID), choose the one the user named or ask, and pass its ID here.
can_commentNo
quoted_post_idNoExact provider post ID to quote, returned by post search/list/get. Never pass post text or a URL. Post ID: Exact provider post id; LinkedIn commonly uses a preformatted/base64-style post ID. Obtain with: linkedin_search_posts -> result.id; linkedin_list_user_posts -> result.id; instagram_list_user_posts -> result.id Never pass: post text, author user ID, URL unless a resolver tool explicitly accepts it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / text / description
      Added value: +"LinkedIn Classic mentions belong in text: @ followed by the resolved person's Classic ACo... ID or the company's numeric ID (for example @1441). Resolve people with linkedin_get_profile_from_url/linkedin_resolve_person and companies with linkedin_resolve_company/linkedin_search_companies; disambiguate every target before publishing. Never use a display name, profile URL, company slug, URN, Sales Navigator or Recruiter ID as a mention. Example after resolving both targets: 'Thanks @ACo_RESOLVED_MEMBER for working with @1441.' The API replaces each token with the target's name and mention metadata; no separate mentions field is needed. Approve the final text and mentioned identities before the write; never retry an ambiguous write automatically."
  2. Changed1 schema field changed
    • changedInput schema / properties / quoted_post_id / description
      Previous value: -"Exact provider post ID to quote, returned by post search/list/get. Never pass post text or a URL. Post ID: Exact provider/Unipile post id; LinkedIn commonly uses a preformatted/base64-style post ID. Obtain with: linkedin_search_posts -> result.id; linkedin_list_user_posts -> result.id; instagram_list_user_posts -> result.id Never pass: post text, author user ID, URL unless a resolver tool explicitly accepts it."New value: +"Exact provider post ID to quote, returned by post search/list/get. Never pass post text or a URL. Post ID: Exact provider post id; LinkedIn commonly uses a preformatted/base64-style post ID. Obtain with: linkedin_search_posts -> result.id; linkedin_list_user_posts -> result.id; instagram_list_user_posts -> result.id Never pass: post text, author user ID, URL unless a resolver tool explicitly accepts it."
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is partly covered. The description still adds real value by flagging the public side effect, the approval requirement, and the identity-ambiguity risk ('never retry an ambiguous write automatically'), which reinforces non-idempotency in operational terms.

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 tight sentences: the action and target scope come first, the safety precondition second. No filler, no repetition of schema detail.

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

Completeness5/5

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

For a write tool with no output schema, the description plus the annotations and the richly documented schema cover what an agent needs: what it publishes, under whose identity, and the approval gate. Return-value behavior is not required here.

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 coverage is 67% and the schema itself carries very detailed parameter docs (mention token resolution, post_as identity rules, account_id selection). The description only adds the framing that post_as targets a managed company page, which is already stated in the schema, so it adds little beyond structured data.

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?

States a specific verb and resource ('Publish a LinkedIn post') and scopes it precisely to the user's own account with an optional managed-company-page target via post_as. That scope cleanly separates it from update/comment/react siblings, though no sibling is named explicitly to route the agent away from alternatives like social_update_post.

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?

Gives a clear gating condition: use only after the user has clearly approved the final content and target identity. It does not, however, contrast this tool with alternatives (e.g. social_update_post for edits, or scheduling tools), so the agent gets a precondition but no explicit 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 Nilyo toolsInspect
Try in Browser
Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources