Antwork

fetch_platform_posts

Read-only

Posts read straight from a platform, with metrics and permalinks: the account's own, or other people's public posts.

source="own" (default): the connected accounts' own posts, Antwork's or not, one entry per account in accounts, so two LinkedIn accounts come back side by side. It includes posts made on the platform directly, which get_performance (Antwork-published posts only) does not; a duplicate check before drafting is create_post's similarRecent. LinkedIn personal profiles cannot be read this way (LinkedIn closed that API): they come back unsupported: true with a reason. Antwork-published posts on them still have metrics in get_performance and get_post. An account that could not be read has fetchError (reason, message): its empty posts is not an empty account, so say it could not be read, never that it has no posts. X answers carrying cachedAt come from a read kept up to a week (X bills per post read). A post's mediaUrls (Instagram, Facebook, Threads, Pinterest, Mastodon, Bluesky images) go to add_media(url=...) to repost the file; they expire.

source="search" (query) or "account" (handle): public posts by anyone on platform, read with a connected account's sign-in and sorted by outlierScore, how many times its usual a post did (1 is typical; scoreBasis says against what: engagement per follower across the results, or a creator against their own median). Each post has text, url, author, format, metrics and traits (length bucket, first line, hashtag count, link, question). X, YouTube, Bluesky and Mastodon, plus Instagram creators only (source="account", public Business or Creator accounts, read with a Unified Login account; an Instagram Login one answers instagram_reconnect_for_discovery with the reconnect link). Any other platform, or an Instagram search, answers unsupported with the way around it. Paid plans; X searches have a weekly limit. A read is reused for a day.

Studying what went viral, in order: get_post_context for the user's account (the voice to write in); this tool for the outliers; the 2 or 3 patterns they share (hook, format, length, angle) named for the user, rather than their topics; a plan of variations on the user's own business, agreed before any create_post. A variation takes the structure, never the source's wording, and a quote names its creator.

Args: platform: One platform, e.g. "linkedin". Omitted = every connected one (own only; required otherwise). account_id: One connected account; with search/account, whose sign-in makes the read. max_posts: Own posts per account (1-25, default 10); with search/account, the same as limit. workspace_id: Workspace ID or name. Optional if user has only one workspace. source: "own" (default), "search" or "account". query: Keywords or a #hashtag, with source="search". handle: A creator's handle, with source="account" (on Mastodon user@server). since_days: How far back with search/account, 1-30 (default 7 for search, 30 for account; X search reaches 7). limit: Posts returned with search/account (1-25, default 10); with own, the same as max_posts.

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

Input Schema

Name	Required	Description	Default
`limit`	No
`query`	No
`handle`	No
`source`	No		own
`context`	No	The user's underlying goal for this call, in one sentence without personal details. Used for product analytics only.
`platform`	No
`llm_model`	No	The model identifier of the calling assistant, or "unknown". Used for product analytics only.
`max_posts`	No
`account_id`	No
`since_days`	No
`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.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 9, 2026
- addedInput schema / properties / limit / anyOf
```
Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
```
- changedInput schema / properties / limit / default
```
Previous value: -10New value: +null
```
- removedInput schema / properties / limit / type
```
Removed value: -"integer"
```
- addedInput schema / properties / max_posts / anyOf
```
Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
```
- changedInput schema / properties / max_posts / default
```
Previous value: -10New value: +null
```
- removedInput schema / properties / max_posts / type
```
Removed value: -"integer"
```

Changed5 schema fields changedNov 6, 2026

addedInput schema / properties / handle

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Handle"
+}

addedInput schema / properties / limit

Added value: +{
+  "default": 10,
+  "title": "Limit",
+  "type": "integer"
+}

addedInput schema / properties / query

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Query"
+}

addedInput schema / properties / since_days

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Since Days"
+}

addedInput schema / properties / source

Added value: +{
+  "default": "own",
+  "title": "Source",
+  "type": "string"
+}

Changed1 schema field changedOct 26, 2026

changedInput schema / required

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

First observedOct 22, 2026

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered; the description adds genuinely useful behavior: `fetchError` semantics ('its empty `posts` is not an empty account'), `unsupported`/`instagram_reconnect_for_discovery` responses, expired `mediaUrls`, and week-long `cachedAt` reuse for X. Those are real disclosures beyond the annotations, though output shape is partly covered by the existing output schema.

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 is front-loaded and the Args block is well organized, but the body is dense and long, packing mode rules, caching, error codes and a full editorial workflow into running prose. The 'Studying what went viral, in order' paragraph, including 'a quote names its creator', is advisory guidance beyond what is needed to invoke the tool and dilutes scannability. Almost every sentence carries information, but structure could be sharper.

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 12-parameter, three-mode, paid, rate-limited read tool, the description covers mode selection, platform support matrix, limits, caching and failure states thoroughly, and an output schema exists so return values need no explanation. Minor gaps remain around what happens when required mode parameters are omitted (the schema marks nothing required) and the undocumented analytics parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25% (context, llm_model, conversation_id only), so the description must carry the load, and it does: it documents nine parameters with defaults, ranges (1-25, 1-30, X search reaches 7) and cross-interactions ('max_posts ... with search/account, the same as `limit`'). It also supplies the enum-like values for `source` that the schema lacks. It does not mention the three analytics/conversation params, but those carry their own schema text.

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+resource and scope: 'Posts read straight from a platform, with metrics and permalinks: the account's own, or other people's public posts.' It immediately enumerates its three modes (own/search/account) and distinguishes itself from get_performance ('Antwork-published posts only') and list_posts, so an agent can place it against siblings without reading 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?

Gives explicit mode selection: source='own' for connected accounts, source='search' with `query`, source='account' with `handle`, plus the fallbacks when a mode is unsupported. It names alternatives explicitly (get_performance, create_post's similarRecent for duplicate checks, get_post_context as the first step) and even prescribes an ordered workflow for viral-post study.

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.