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

hatena-blog-mcp

by sumiVer2
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ブログ記事作成

create_entry

Creates a new Hatena Blog entry as a draft by default; set draft to false to publish, or combine draft=true with a future updated date and scheduled=true to queue a scheduled post.

Instructions

ブログ記事を新規作成する。既定では下書きとして作成されるので、公開する場合は draft を false にする。予約投稿する場合は draft=true・scheduled=true と、未来日時の updated を指定する。

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": {
      "title": "<title>",
      "content": "<content>"
    },
    "name": "create_entry"
  }
}

Input Schema

NameRequiredDescriptionDefault
draftNo下書きとして保存するか（既定: true）
titleYesタイトル
contentYes本文。ブログの編集モードに合わせた記法で書く
updatedNo投稿日時（ISO 8601、例: 2026-08-26T15:30:00+09:00）。省略時は現在時刻
scheduledNo予約投稿にするか。draft=true かつ updated が未来日時のときに有効
categoriesNoカテゴリ名の配列。既存のカテゴリは list_categories で確認できる
custom_urlNoカスタム URL（記事 URL のスラッグ部分）
content_typeNo本文の記法。実際の解釈はブログの編集モード設定に従うため、ブログ側の設定と揃えること（既定: text/x-markdown）
preview_sharedNo下書きのプレビュー共有 URL を発行するか

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

No annotations are provided, so the description must carry the full behavioral burden. It does usefully disclose the non-obvious default state (draft=true) and the cross-parameter condition under which scheduling takes effect, which the agent could not otherwise infer without carefully reading two schema entries. It still does not state whether required permissions exist, whether publishing is reversible, or what happens if custom_url collides.

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?

Three short sentences with zero filler, and the most important constraint (defaults to draft) is placed first. Every sentence carries an actionable instruction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutation tool with no annotations and no output schema, the description covers the mode-selection logic well but omits what a successful call returns (entry ID/URL) and how failures surface (for example, invalid custom_url or an unrecognized category). These gaps matter because the agent cannot otherwise know whether it can chain into update_entry afterwards.

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%, with each of the 9 parameters documented inline, including defaults, the enum for content_type, and the conditional rule for scheduled. The description largely restates the draft/scheduled/updated relationship that the schema already spells out, and it says nothing about the remaining parameters (categories, custom_url, preview_shared). Baseline 3 applies when the schema does the heavy lifting.

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 (create a new blog article), so an agent can immediately tell it is a write operation on entries. It does not distinguish itself from create_page, which is the closest sibling in the tool list, but the resource wording is clear enough to tell the two types of content apart.

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?

The description gives explicit conditions for the three creation modes: default draft, publishing by setting draft=false, and scheduled posting by setting draft=true and scheduled=true with a future updated datetime. It does not say when to use this tool instead of create_page or update_entry, so routing between siblings is still left to inference.

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