FeedSquad

Update Post

update_post

DestructiveIdempotent

Edits an unpublished post in place; only the fields passed change. New content returns an approved (ready or scheduled) post to draft, and it needs approval again before it can publish; a title-only edit keeps the status; a new scheduled_date keeps a scheduled post scheduled and makes a draft or ready post a draft with that proposed time. Published posts cannot be edited. dry_run=true validates without writing. Every response carries status_before, status_after and approval_required.

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": {
      "post_id": "<post_id>"
    },
    "name": "update_post"
  }
}

Input Schema

Name	Required	Description
`title`	No	New post title
`content`	No	New post content (max 3000 chars)
`dry_run`	No	When true, the call validates without writing.
`post_id`	Yes	The post id to update
`scheduled_date`	No	New publish time, ISO 8601. With an offset or Z it is used exactly as sent; without one (e.g. 2026-10-22T08:45) it is read in the founder's timezone (the timezone field of scheduling responses) and the response's time_input says so. The time is kept exactly as given, to the minute. A scheduled post stays scheduled at the new time; a draft or ready post becomes a draft with that proposed time.

Output Schema

Name	Required	Description	Default
`kind`	Yes
`dry_run`	No
`post_id`	Yes
`timezone`	No
`server_now`	No
`time_input`	No
`status_after`	No
`dashboard_url`	No
`status_before`	No
`approval_reset`	No
`changed_fields`	No
`scheduled_local`	No
`timezone_source`	No
`approval_required`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.3/5.0

Behavior5/5

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

The description carries a full side-effect model beyond the annotations: content edits send an approved post back to draft and force re-approval, title-only edits preserve status, scheduled_date preserves or demotes scheduling state, and dry_run validates without writing. This matches the destructiveHint=true and idempotentHint=true annotations rather than conflicting with them, and it tells the agent exactly what state it will destroy.

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?

A single dense paragraph that front-loads the core action and constraint before moving into per-field state transitions; nearly every clause adds a distinct behavior. The closing sentence listing status_before/status_after/approval_required is mild duplication against the output schema.

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 5-parameter mutation tool with a destructive hint and an existing output schema, the description supplies everything needed to call it safely: eligibility, per-field side effects, dry-run support, and re-approval consequences. Return values needn't be explained since an output schema exists.

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?

Schema coverage is 100%, so the baseline is 3, and the description earns an extra point by adding conditional meaning the schema does not state — which parameters are mutually constraining, how title-only differs behaviorally from content, and what each mutation does to approval state. It does restate the scheduled_date timezone rule already documented in the schema.

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?

The description opens with a specific verb and resource ('Edits an unpublished post in place') and immediately bounds the scope with 'only the fields passed change' and 'Published posts cannot be edited'. It doesn't name the obvious siblings (reschedule_post, confirm_post, publish_post), so an agent must infer the boundary itself, which keeps it from a 5.

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?

Clear usage conditions: works only on unpublished posts, published posts are excluded, and dry_run=true is the path for validation without writing. There is no explicit routing to alternative tools for the cases it rejects, so an agent told a post is published gets no signpost to publish_post/reschedule_post.

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

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