Skip to main content
Glama

Get Post

get_post
Read-onlyIdempotent

Use this when you need one post's details to act on it: to edit it, check its media or checks, approve or review it at its current rev, or read several posts for a task. It returns data and draws nothing; when the person wants to see or review a post themselves, use show_post. Returns one post: body, channel fields, media (asset ids and names; on an X thread, meta.thread holds the replies and meta.threadMedia the asset ids on each reply, in the same order, with post 1 holding the rest; a social post's images from the CMS are meta.cmsImages, and meta.mediaOrder, when set, is the order of post 1's media across both), schedule, status, updatedAt, claim flags, comments (oldest first; each adds author, the display name or the raw id when the name cannot be resolved, and via, the client it was posted through or null), approval history, who approved it (approvedBy: { id, name, at }; name is "Mark (automatic)" for auto-approval and the raw id when the name cannot be resolved; null unless the post is approved, scheduled or published), the live URL (externalUrl), the reason it failed or was not sent (reviewNote), the handoff of an approved social post to the publisher (handoff: { state: handing_off } for the few seconds before it reads scheduled, { state: stuck, reason } when it can't go, with the fix: no scheduled time, no connected account for the channel, or no progress 5 minutes after approval; on an approved LinkedIn Article { state: publish_by_hand, reason } before its scheduled time and { state: publish_now, reason } from it on; on an approved website post whose post type no CMS maps { state: publish_by_hand, reason }, recorded with record_post_published once it is live on the site; null otherwise), the buyer questions a website post answers (buyerQuestions: id, question), the idea it was made for (idea: id, title, archived; null when none), a website post's language (language: a BCP 47 code such as de-CH, the locale its CMS page is saved in; null when unset), the post it translates (translationOf: id, language, title; null when it is not a translation) and the posts that translate it (translations: id, language, title), and, on a refresh of a live page Mark published, refresh: { text, pageUrl } with the reason Mark queued it (null otherwise; approving updates that same page). A published social post carries metricHistory: every metrics reading, oldest first, as { date (YYYY-MM-DD in the render timezone), day (whole days since publish), impressions, engagement }, the newest matching get_content_performance; impressions is the platform's impressions count and engagement is likes + comments + shares + saves, each the total the platform reported at that reading ([] before the first reading; null on unpublished posts). A published blog, FAQ or competitor post's metricHistory is instead its daily site-tag readings, oldest first, as { date (YYYY-MM-DD, the workspace calendar day it covers, whatever timezone is passed), pageviews, submissions (form submissions whose visit started on the page) }, with dataThrough (the newest reading's date, null before the first) and connection (ready, or no-posthog when the workspace has no PostHog project of its own; metricHistory is then [] and the person connects PostHog under Connections); [] before the first reading. Blog, FAQ and competitor posts also carry website: where the page goes, its delivery state (preview, queued, sent_to_cms, published, taken_down, failed, removed, conflict, out_of_sync), the page URL, the draft preview link on the tenant's site (previewUrl) with previewSentAt and previewStale for a pre-approval preview, previewLeftAt (set when the post was rejected or archived and Mark left that preview draft in the CMS; reviewNote says why), previewBlocked (why send_cms_preview is refused, or null), a failed job id to pass to sync_connections retryJobId, a live retry error when the job is still pending, and the exact document Mark sends to the CMS. conflict means the CMS page changed since Mark last sent it and needs an explicit overwrite-or-keep choice; conflictDiff then lists each changed field with its CMS value (cms) and Mark's value (mark); choose with resolve_cms_conflict. checks runs Mark's content checks on the current body, meta and language (exclusion, char_limit, required_meta, ai_fluff, unsourced_number, placeholder; table and open_placeholder on a competitor_page; keyword on a website post with meta.seo.keyword). revisionChecks are the results Mark stored for the current rev when it was sent to review, the ones the reviewer sees ([] at rev 0 or when Mark didn't check that revision); they include brand_fit (the brand voice and offer check, warn or pass) once it lands, up to a minute after submit, and never when the workspace's intelligence is off or its voice is unconfirmed. rev is the frozen revision. It advances on submit, and when save_post edits a post in review, approved or scheduled; saving a draft leaves it alone, and updatedAt confirms that save. Call this before approve_posts, review_post, or a save_post edit to a post in review, so you have the current rev. Optional timezone (IANA) renders scheduled and published times in that zone; it does not change stored data. Related: show_post, search_posts, save_post, approve_posts.

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>"
    },
    "name": "get_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
postIdYesThe post id from search_posts or save_post.
timezoneNoIANA zone to render times in. Does not change stored data. Defaults to the workspace timezone.

Output Schema

NameRequiredDescriptionDefault
postYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / timezone
      Added value: +{
      +  "description": "IANA zone to render times in. Does not change stored data. Defaults to the workspace timezone.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

The annotations already declare this is a read-only, idempotent, non-destructive tool. The description adds useful behavioral context beyond that: it says it 'draws nothing,' that timezone only affects rendering and not stored data, and that rev advances only under specific save/submit conditions. Most remaining length describes return values, which the output schema already covers.

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

Conciseness2/5

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

The description is extremely long and dominated by a dense run-on enumeration of return fields, many of which are already covered by the output schema. It is front-loaded with the key usage guidance, but the bulk of the text does not earn its place for a two-parameter read tool.

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?

Given the tool's complexity and the presence of an output schema and annotations, the description is more than complete. It covers selection, prerequisites, return semantics, revision behavior, conflict handling, and metric history, leaving no important ambiguity for an agent.

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%, so both parameters are already documented. The description repeats that timezone is IANA, renders scheduled and published times, and does not change stored data, but adds little beyond the schema. The postId origin is also already stated in the schema.

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 description opens with a specific verb and resource: retrieving one post's details. It explicitly distinguishes itself from show_post and names related tools (search_posts, save_post, approve_posts), so an agent can select it confidently.

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 gives explicit when-to-use guidance (editing, checking media/checks, approving, reviewing at current rev) and a clear when-not-to-use alternative: show_post when a person wants to view the post themselves. It also states a prerequisite workflow: call this before approve_posts, review_post, or a save_post edit to a post in review.

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