Antwork

get_post

Read-only

One post in full: text, account, status, schedule, media, links, and for a published post its lifetime metrics.

A published post nothing has read yet (15 minutes or older) is read from its network once, before answering. metricCells holds each metric (likes, comments, shares, impressions, reach, saves, clicks, bookmarks, linkClicks, profileVisits, follows, watchTimeSeconds) with whether it was measured (a 0 the platform reported vs a field it does not report). The text is current even if the user edited it in the web composer (editUrl; mediaUrl and settingsUrl open its media picker and platform settings). mediaUrls are library files: create_post(media_urls=...) reuses them to repost on another account. Per-day history is get_performance(post_id=...). approval (approval workspaces): state, decidedBy, decidedAt, and requestedFor while pending. A draft with state changes_requested was sent back: make the change its note asks, then schedule_post it again. post_ids reads up to 25 posts in one call: posts has one entry per id, each this shape or that id's error; with include_comments, up to 5.

Args: post_id: The post ID. workspace_id: Workspace ID or name. Optional if user has only one workspace. include_comments: Published posts only: add comments, the latest 20 read live from the network (newest first, replies one level deep, each with the id reply_to_comment takes), and commentReply (whether this network takes replies). A network that shares no comments answers commentsUnavailable instead; commentsNote says the list misses older replies (X: 7 days). post_ids: Several posts to read at once, instead of post_id.

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

Input Schema

Name	Required	Description
`context`	No	The user's underlying goal for this call, in one sentence without personal details. Used for product analytics only.
`post_id`	No
`post_ids`	No
`llm_model`	No	The model identifier of the calling assistant, or "unknown". Used for product analytics only.
`workspace_id`	No
`conversation_id`	No	Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.
`include_comments`	No

Output Schema

Name	Required	Description	Default
`_mcp_instructions`	No	Server-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 9, 2026

addedInput schema / properties / post_id / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / post_id / default
```
Added value: +null
```
removedInput schema / properties / post_id / type
```
Removed value: -"string"
```

addedInput schema / properties / post_ids

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Post Ids"
+}

changedInput schema / required

Previous value: -[
-  "post_id"
-]New value: +[]

Changed1 schema field changedOct 29, 2026

addedInput schema / properties / include_comments

Added value: +{
+  "default": false,
+  "title": "Include Comments",
+  "type": "boolean"
+}

Changed1 schema field changedOct 26, 2026

changedInput schema / required

Previous value: -[
-  "post_id",
-  "context",
-  "llm_model"
-]New value: +[
+  "post_id"
+]

First observedOct 22, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only say this is a non-destructive read; the description adds substantial behavior an agent could not infer, such as the one-time network fetch for a published post nothing has read yet at 15 minutes or older, and that the text is current even after web-composer edits. It also discloses per-metric measured-vs-zero semantics, network-specific comment limits (X: 7 days), and the commentsUnavailable fallback.

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

Conciseness4/5

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

The lead sentence front-loads what comes back, then the caveats (network refresh, metricCells, comments limits) follow in short paragraph blocks that each carry information. It is dense and long for a getter, but little looks removable given the output nuances being flagged.

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 7-param read tool with an output schema, the description covers the parts that matter operationally: refresh behavior, the metricCells encoding, the approval/changes_requested workflow, batch reads, and comment availability caveats. It never says what happens if both post_id and post_ids are omitted (both are optional, required: []), which is the main remaining gap.

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?

include_comments and post_ids get real meaning the schema lacks: latest 20 comments newest-first, replies one level deep with the id reply_to_comment takes, commentReply, and post_ids returning one entry per id or that id's error. workspace_id is only 'Workspace ID or name' with no schema description, and the analytics params (context, llm_model, conversation_id) are left entirely to the schema, so not every gap is closed.

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?

Opens with a specific verb-and-resource frame: 'One post in full: text, account, status, schedule, media, links' plus lifetime metrics for published posts. It also separates itself from a named sibling by stating 'Per-day history is get_performance(post_id=...)'.

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?

Routes the agent to alternatives in several concrete cases: get_performance for per-day history, post_ids to read up to 25 posts at once, create_post(media_urls=...) to reuse library files, and schedule_post after a changes_requested draft. It doesn't state when not to use this tool at all (e.g. bulk listing or searching), which keeps it short of a 5.

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

All Antwork tools Inspect

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.