postnext

Update a post draft

update_post_draft

DestructiveIdempotent

Update an existing draft post. At least one of content, threadParts, mediaUrls or media is required. To give images alt text (an image description for screen readers), pass media instead of mediaUrls: [{ "url": "...", "alt": "..." }] with an optional type (IMAGE, VIDEO or GIF); it replaces the media on the draft. Alt text limits: X and Instagram 1,000 characters, Bluesky 2,000, LinkedIn 300 (saved for LinkedIn but not sent to it yet); it is ignored on video and GIF. For a thread draft (X/Threads), pass threadParts (one string per post) to replace its posts; content only edits a single-post draft. Optional platform scopes the update to one platform on a multi-platform cross-post (e.g. rewrite just the Twitter copy without overwriting the Instagram caption). When the user has multiple channels per platform (e.g. three Twitter accounts), additionally pass channelName (e.g. "@acme") to narrow the update to one specific account's copy. When both are omitted, all providers in the draft are overwritten uniformly. Returns dashboardUrl — a clickable link to view/edit the just-updated draft in the PostNext dashboard.

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

Input Schema

Name	Required	Description	Default
`media`	No
`postId`	Yes
`content`	No
`platform`	No
`mediaUrls`	No
`channelName`	No
`threadParts`	No
`clientRequestId`	No

Output Schema

Name	Required	Description	Default
`postId`	Yes
`status`	Yes
`content`	No
`mediaUrls`	Yes
`updatedAt`	No
`dashboardUrl`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / media

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "alt": {
+        "maxLength": 2000,
+        "type": "string"
+      },
+      "type": {
+        "enum": [
+          "IMAGE",
+          "VIDEO",
+          "GIF"
+        ],
+        "type": "string"
+      },
+      "url": {
+        "$ref": "#/properties/mediaUrls/items"
+      }
+    },
+    "required": [
+      "url"
+    ],
+    "type": "object"
+  },
+  "maxItems": 10,
+  "type": "array"
+}

Changed2 schema fields changedOct 6, 2026

changedInput schema / properties / content / maxLength
```
Previous value: -2200New value: +25000
```

addedInput schema / properties / threadParts

Added value: +{
+  "items": {
+    "maxLength": 25000,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 25,
+  "minItems": 2,
+  "type": "array"
+}

Changed1 schema field changedOct 2, 2026
- removedOutput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```
First observedSep 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations it discloses exactly what is destroyed and replaced: `media` replaces the draft's media, `threadParts` replaces its posts, and omitting platform/channelName overwrites all providers uniformly — consistent with destructiveHint=true. It adds practical limits the annotations cannot express (alt-text character caps per network, ignored on video/GIF, LinkedIn saved but not sent) and even names the return value `dashboardUrl`.

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?

Purpose and the at-least-one-of rule are front-loaded, followed by the media/threadParts/scoping details in a sensible order. It is dense — the alt-text limits sentence is long and slightly parenthetical-heavy — but almost every clause carries actionable information.

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 destructive 8-parameter mutation tool with a nested media object, the description covers the required input, the replacement semantics, the scoping rules, and the return value; the output schema and annotations handle the rest. An agent could call this correctly without opening the schema.

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?

With 0% schema coverage the description carries the load and mostly does: it explains content vs threadParts vs media vs mediaUrls, the alt/type fields with example payload shape and per-platform limits, and the platform/channelName narrowing semantics. `clientRequestId` (the idempotency key implied by idempotentHint) and the `postId` argument are never explained, leaving a small gap.

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 ("Update an existing draft post") and immediately states the at-least-one-of constraint. It distinguishes itself from create_post_draft and schedule_post implicitly by scoping to mutating an existing draft, and the media/threadParts explanation makes the exact edit surface unambiguous.

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 explicit conditional routing: pass `media` instead of `mediaUrls` when alt text is needed, use `threadParts` for thread drafts versus `content` for single-post drafts, and use `platform`/`channelName` to scope cross-post edits. It never explicitly contrasts against sibling tools (e.g. create_post_draft to make a new draft, schedule_post to publish), so it stops 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 postnext 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.

Resources

Need Help?