Postey

Update a post

update_post

Destructive

Overwrite an existing post's contents. get_post_content shows the current content for the user to confirm changes against. Updating applies to DRAFT and SCHEDULED posts; updating a PUBLISHED post does not re-publish it. Partial updates are safe: only the fields sent change. A field omitted on a content item is carried over from the existing post. This covers media_urls, post_type and every platform config (the youtube_* fields except youtube_title, tiktok_privacy_status, cover_url, graduation_strategy, share_to_feed, and the pinterest_* fields except pinterest_title). Updating text alone does not strip media or reset configs, and the whole post does not need re-sending. A config changes only when its new value is passed explicitly. media_urls=[] on a content item removes its media. YOUTUBE is the one exception: youtube_title is required, so an update keeps exactly one content item and includes contents[0].youtube_title on every call. contents[0].text is the video description and is left out unless a description is intended; contents[0].media_urls holds the uploaded video. post_type does not apply to YOUTUBE. PINTEREST works the same way: pinterest_title is required, so an update keeps exactly one content item and includes contents[0].pinterest_title on every call. contents[0].text (the Pin description), pinterest_board_id, pinterest_link and pinterest_alt_text are optional and carried over if omitted. post_type does not apply to PINTEREST. Tags: update_tags takes specs ({tag, color, account_id}), not tag_ids. A spec whose name already exists resolves to that tag rather than creating a duplicate, and postey://accounts/{account_id}/tags lists existing tags with their exact casing.

Input Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 25, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations by explaining that partial updates are safe, omitted fields are carried over, text-only updates do not strip media, media_urls=[] clears media, and a PUBLISHED post is not re-published. It also discloses the two structural exceptions (YOUTUBE and PINTEREST require exactly one content item with a mandatory title), which is precisely the kind of behavior an agent would otherwise get wrong.

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 safety/overwrite semantics are front-loaded and earn their place, but the middle section degenerates into a long enumeration of individual platform config field names that reads as a schema dump and is hard to scan. The PINTEREST paragraph also largely restates the YOUTUBE pattern instead of compressing it.

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?

Given nested objects, nine platforms, and destructive semantics, the description covers the risky cases (partial update, media removal, single-item YouTube/Pinterest) well, and the output schema covers returns. It omits tags_to_remove behavior and says nothing about what happens when an update targets an ineligible state, but the core is covered.

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?

Adds meaning not present in the schema: which fields are carried over vs. reset, that update_tags takes specs rather than tag_ids, that an existing tag name resolves instead of duplicating, and that contents[0].text means the video/Pin description on YOUTUBE/PINTEREST. These are semantic rules that materially change how the nested params must be filled.

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?

Opens with a specific verb and resource ('Overwrite an existing post's contents') and explicitly contrasts read vs write by naming get_post_content. It does not distinguish itself from create_post, publish_draft, or schedule_post, which are the closest write-side siblings an agent could confuse it with.

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 concrete usage context: applies to DRAFT and SCHEDULED posts, does not re-publish PUBLISHED ones, and points to get_post_content for confirming current state before writing. No explicit 'do not use this when...' routing to create_post or publish_draft, so the routing is implied rather than complete.

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

All Postey 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?