tistory-mcp

Update a post (글 수정)

tistory_update_post

Edit an existing Tistory blog post by sending the complete new body; omit fields to keep the current title, category, visibility, slug, and tags.

Instructions

Update an existing post. The body must be sent in full (the server does not merge).

Title, category, visibility and slug keep their current values when omitted; tags are kept by reading them from the post page (pass [] to clear). Rate-limited together with publish.

Input Schema

Name	Required	Description	Default
`tags`	No	New tags; omit to keep the current tags (read from the post page), pass [] to clear
`title`	No	New title; omit to keep the current one
`slogan`	No	New URL slug; omit to keep
`content`	Yes	The complete new body — the server overwrites the whole post. Do not echo content_html from tistory_get_post; write the new body yourself
`post_id`	Yes	Post number (글 번호)
`blog_url`	Yes	Blog host or URL of the post to update
`category`	No	New category id; omit to keep the current one
`password`	No	Password for visibility='protected'
`visibility`	No	New visibility; omit to keep the current one. 'public' makes it live
`attachments`	No	attachment_ref of images used in the new content
`content_format`	No	Default 'html'. Set 'markdown' when sending markdown, or it is posted as raw text	html

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 27, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations only declare it is a non-read-only, non-destructive, non-idempotent, open-world write. The description adds the crucial behaviors the annotations do not: the server does not merge so the full body is overwritten, tags are preserved by re-reading the post page, and the call shares a rate limit with publish. It stops short of noting session/auth requirements or what happens to attachments and password fields.

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 overwrite constraint is front-loaded in the first sentence, followed by field-preservation rules and the rate-limit note. Three sentences with almost no waste, though the trailing 'Rate-limited together with publish' fragment could be folded in more smoothly.

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?

With 11 parameters, full schema coverage, an output schema, and annotations covering the safety profile, the description covers the main non-obvious risk (full-body overwrite) and the omit-to-keep contract. Only auth/session prerequisites and attachment handling are left implicit.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter is already documented; baseline is 3. The description usefully clarifies the 'slogan' param is the URL slug and restates the omit-to-keep contract for title/category/visibility, but adds no syntax, id-format, or password/visibility interaction detail beyond 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?

A clear verb+resource ('Update an existing post') that is distinguishable from publish/save_draft by the word 'existing'. It does not explicitly name the sibling tools it supersedes for editing, so differentiation is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains omission semantics well (fields keep current values, [] clears tags), which is really per-field guidance, but it never says when to choose this over tistory_publish_post or tistory_save_draft, nor what prerequisites (session/auth) must be in place. Usage is inferable rather than directed.

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

Deploy Server