Skip to main content
Glama

Record Post Published

record_post_published
Idempotent

Records that an approved post Mark doesn't publish itself is live: a LinkedIn Article (channel linkedin_article), or a website post (blog, faq, competitor_page) whose post type no CMS connection maps (get_post handoff reads publish_by_hand). Pass its id and its live URL: for an Article, the https linkedin.com URL LinkedIn shows for it; for a website post, the page's https address on any host. The post becomes published with publishedAt now and externalUrl the URL, the same as a post Mark published, and Mark sends post_published to the workspace's PostHog project once, on the first recording. For an Article, Mark reads its LinkedIn metrics daily for 30 days, then weekly until 90 days, through the connected LinkedIn account. Mark never publishes an Article itself, since LinkedIn has no API for them; a person copies the approved Article into LinkedIn at its slot time (get_post handoff reads publish_by_hand, then publish_now), then this records it. A website post with no CMS mapping is copied onto the site by hand (title, Markdown body, slug, SEO title and description from get_post), then recorded here. Calling again with the same URL succeeds and changes nothing. Refused for a post that isn't approved, another channel, a website post whose post type a CMS maps (Mark publishes those through the CMS), a URL that isn't https, an Article URL that isn't on linkedin.com or has no urn:li:share: or urn:li:ugcPost: post URN (a /pulse/ address), or a published post with a different URL. To help the person copy an Article, get_post gives the headline (meta.title) and the Markdown body; the cover is the asset meta.cover.assetId names, whose URL get_asset returns. Only use it once the user says the post is live. Related: get_post, get_asset, approve_posts, get_calendar.

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": {
      "postId": "<postId>",
      "url": "<url>"
    },
    "name": "record_post_published"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesThe live post's https address. For an Article, its post address from LinkedIn with its post URN in it, such as https://www.linkedin.com/feed/update/urn:li:ugcPost:7518698639439978496/ (LinkedIn's … > Embed this post shows it); a /pulse/ address is refused: it has no post URN, so Mark couldn't read the Article's metrics. For a website post, the page's address on your site, any host.
postIdYesThe approved LinkedIn Article, or approved website post with no CMS mapping.

Output Schema

NameRequiredDescriptionDefault
appUrlYes
postIdYes
statusYes
externalUrlYes
publishedAtYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / postId / description
      Previous value: -"The approved LinkedIn Article."New value: +"The approved LinkedIn Article, or approved website post with no CMS mapping."
    • changedInput schema / properties / url / description
      Previous value: -"The live Article's post address from LinkedIn, with its post URN in it, such as https://www.linkedin.com/feed/update/urn:li:ugcPost:7518698639439978496/ (LinkedIn's … > Embed this post shows it). A /pulse/ address is refused: it has no post URN, so Mark couldn't read the Article's metrics."New value: +"The live post's https address. For an Article, its post address from LinkedIn with its post URN in it, such as https://www.linkedin.com/feed/update/urn:li:ugcPost:7518698639439978496/ (LinkedIn's … > Embed this post shows it); a /pulse/ address is refused: it has no post URN, so Mark couldn't read the Article's metrics. For a website post, the page's address on your site, any host."
  2. Changed1 schema field changed
    • changedInput schema / properties / url / description
      Previous value: -"The live Article's URL from LinkedIn, such as https://www.linkedin.com/pulse/..."New value: +"The live Article's post address from LinkedIn, with its post URN in it, such as https://www.linkedin.com/feed/update/urn:li:ugcPost:7518698639439978496/ (LinkedIn's … > Embed this post shows it). A /pulse/ address is refused: it has no post URN, so Mark couldn't read the Article's metrics."
  3. Added

TDQS

A4.2/5.0
Behavior5/5

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

Substantially beyond the annotations, it discloses the resulting state (publishedAt=now, externalUrl set), a one-time post_published event to the workspace's PostHog project, the 30-day-daily/90-day-weekly LinkedIn metric polling for Articles, and the idempotent no-op on repeat calls with the same URL. It also explains why Mark can't publish Articles itself (no LinkedIn API), which is genuine causal context an agent can act on.

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 purpose and the key idempotency and refusal facts are front-loaded, which is good, but the prose is a dense run-on paragraph with visible redundancy — "get_post handoff reads publish_by_hand" appears twice, and the manual-copy workflow is explained twice. It would scan far better as short structured sentences or a bullet list of refusal cases.

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?

With an output schema present the description needn't document return values, and it instead covers everything else an agent needs: preconditions, effects, side effects (PostHog event, metric polling), idempotency, and the full rejection matrix. Nothing material about calling this tool correctly is left unstated.

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, but the description adds cross-parameter meaning the schema lacks: postId must be an approved post of the two eligible kinds, and url semantics are tied to eligibility (https, linkedin.com host, URN required for Articles, any host for site posts) plus the same-URL/different-URL repeat-call rules.

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 opening sentence names a specific verb and resource (records that a post is live) and enumerates the two supported cases: a LinkedIn Article and a website post with no CMS mapping. It is very precise about scope, but it never contrasts itself with the sibling resolve_external_post, which on its name alone sounds like the nearest alternative for marking off-platform posts live.

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 gives an explicit gate ("Only use it once the user says the post is live") plus a detailed list of refusal conditions — not approved, wrong channel, CMS-mapped post type, non-https URL, /pulse/ Article URL, conflicting URL on an already-published post. What's missing is a named alternative: it points to get_post and get_asset for preparation but never routes the agent to resolve_external_post or unpublish_post for adjacent situations.

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