Skip to main content
Glama
hatena-blog-mcp
by sumiVer2

画像アップロード

upload_image

Uploads a local image to Hatena Fotolife and returns embed markup for Markdown or Hatena syntax, plus an image URL for WYSIWYG posts.

Instructions

ローカルの画像をはてなフォトライフにアップロードし、記事本文に貼れる記法(embed)を返す。embed は Markdown・はてな記法の編集モード向け。見たままモードのブログでは imageUrl を使う。画像は認証アカウント(HATENA_ID)のフォトライフに保存され、URL を知っていれば誰でも見られる。社外に出してよい画像だけを渡すこと。アップロードした画像の削除はブラウザから行う。

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": {
      "file_path": "<file_path>"
    },
    "name": "upload_image"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleNoフォトライフ上の画像タイトル。省略時はファイル名
folderNo保存先のフォルダ名。存在しなければ作られる(既定: Hatena Blog)
file_pathYesアップロードする画像ファイルの絶対パス(PNG / JPEG / GIF)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that the image lands in the authenticated account's Fotolife, is publicly viewable by anyone with the URL, that the caller should only pass externally-safe images, and that removal is not possible through this tool. That is exactly the risk context an agent needs for a write with openWorldHint.

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?

Front-loads the action and return value, then layers the mode guidance, visibility warning and deletion note. Dense but every sentence carries operational value; only marginal tightening is possible.

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?

No output schema exists, and the description explains the returned embed versus imageUrl distinction that the agent must relay to the user. Combined with 100% parameter coverage, nothing needed to call it correctly is missing.

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 title, folder (auto-created if missing) and file_path (absolute path, PNG/JPEG/GIF) are already documented in the schema. The description adds no additional parameter-level detail, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (upload a local image to Hatena Fotolife) plus the return value (an embed notation usable in article bodies). No sibling tool performs uploads, so the agent can distinguish it immediately from the entry/page CRUD siblings.

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?

Explicitly says embed is for Markdown/Hatena-notation modes and that WYSIWYG-mode blogs should use imageUrl, and notes that deletion happens in the browser (i.e., not here). It gives clear usage conditions but no explicit 'when not to use this' beyond the visibility caveat.

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