MisarBlog MCP Server

Update article

update_article

DestructiveIdempotent

Modify an existing blog article or draft by updating only the title, Markdown body, or tags you provide; omitted fields stay unchanged.

Instructions

Update the title, body, or tags of an existing article or draft. Only the fields you pass are changed; omitted fields keep their current values.

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": {
      "id": "<id>"
    },
    "name": "update_article"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Article or draft ID
`tags`	No	Replace the tag list
`title`	No	New title
`body_markdown`	No	New body in Markdown

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv5.2.0Nov 7, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```

Changed4 schema fields changedv5.1.3Oct 14, 2026

changedInput schema / properties / body_markdown / description

Previous value: -"Replacement body as Markdown. Replaces the whole body, not a patch."New value: +"New body in Markdown"

changedInput schema / properties / id / description

Previous value: -"Article or draft id from a listing tool. This is the id, not the slug."New value: +"Article or draft ID"

changedInput schema / properties / tags / description

Previous value: -"Replacement tag list, up to 10. Overwrites the existing tags entirely."New value: +"Replace the tag list"

changedInput schema / properties / title / description

Previous value: -"Replacement headline."New value: +"New title"

Changed4 schema fields changedv5.1.0Aug 19, 2026

changedInput schema / properties / body_markdown / description

Previous value: -"New body in Markdown"New value: +"Replacement body as Markdown. Replaces the whole body, not a patch."

changedInput schema / properties / id / description

Previous value: -"Article or draft ID"New value: +"Article or draft id from a listing tool. This is the id, not the slug."

changedInput schema / properties / tags / description

Previous value: -"Replace the tag list"New value: +"Replacement tag list, up to 10. Overwrites the existing tags entirely."

changedInput schema / properties / title / description

Previous value: -"New title"New value: +"Replacement headline."

First observedv2.0.0Aug 4, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare non-readonly, destructive, idempotent, and open-world behavior. The description adds useful partial-update semantics: only supplied fields change and omitted fields retain current values. It does not mention ownership/auth requirements or that passing tags replaces the whole tag list, so it is helpful but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the affected resource and fields. The second sentence carries important partial-update semantics without any wasted wording.

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 straightforward four-parameter mutation with full schema documentation and behavioral annotations, the description covers the core operation and partial-update behavior. It stops short of ownership/authorization context and tag-replacement implications, but those gaps are limited relative to the tool's complexity.

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 coverage is 100%, so the schema already documents id, title, body_markdown, and tags with their constraints. The description clarifies that only passed fields are updated, but it does not add parameter-specific syntax or format beyond what the schema provides.

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 states a specific verb and resource: updating an existing article or draft, and it names the mutable fields title, body, and tags. It is clear, but it does not explicitly distinguish itself from siblings such as publish_article or create_draft, so it stops short of top-tier sibling differentiation.

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 establishes that the tool applies to an existing article or draft and that updates are partial, which implies when to use it. It does not give explicit when-not guidance or point to alternatives like publish_article or create_draft.

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