Skip to main content
Glama
Sign In
hatena-blog-mcp

hatena-blog-mcp

by sumiVer2
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

固定ページ更新

update_page

Update an existing Hatena Blog fixed page by replacing only the fields you provide; omitted fields keep their current values, and set draft to false to publish it.

Instructions

固定ページを更新する。指定した項目だけを差し替える差分更新で、省略した項目は現在の値がそのまま残る。下書きを公開するには draft=false を指定する。categories を渡すと現在のカテゴリは完全に置き換わる。 固定ページははてなブログの有料プランでのみ利用できる。無料プランでは 404 が返る。

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": {
      "page_id": "<page_id>"
    },
    "name": "update_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
draftNo下書き状態。false にすると公開される
titleNo新しいタイトル
contentNo新しい本文（全文）
page_idYes更新する固定ページの ID
updatedNo投稿日時（ISO 8601）。省略時は現在の投稿日時を維持する
custom_urlNoカスタム URL。省略時は変更しない
content_typeNo本文の記法。実際の解釈はブログの編集モード設定に従うため、ブログ側の設定と揃えること（既定: text/x-markdown）
preview_sharedNo下書きのプレビュー共有 URL を発行するか

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses patch semantics (omitted fields retain current values), that categories are destructively replaced, that publishing requires draft=false, and that free plans get a 404. Only auth/permission requirements and response behavior are left unstated.

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?

Four short sentences, front-loaded with the core update semantics before the conditional behaviors. Each sentence adds distinct information (patch model, publishing, category replacement, plan limitation) with no filler.

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 an 8-parameter mutation tool with no annotations and no output schema, the description covers the critical behavioral facts an agent needs: differential update, publish flag, destructive category replacement, and the paid-plan precondition. Minor gaps are auth requirements and the page-vs-entry routing, but the essentials are present.

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 per-field meaning and baseline is 3. The description adds cross-cutting patch semantics (omitted = keep current) and clarifies draft publishing, which is genuine value — but it also references a 'categories' parameter that is absent from the schema, which could mislead.

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+resource (固定ページを更新する) that clearly separates it from entry-updating siblings like update_entry, and the title reinforces this. It doesn't explicitly name a sibling to route away from, but the post-vs-page distinction is unambiguous from the wording.

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 gives conditional usage advice — draft=false for publishing, categories for full replacement — but never states when to use this tool instead of update_entry or create_page. Usage is implied rather than routed explicitly.

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

Deploy Server

Other Tools