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

固定ページ一覧

list_pages
Read-only

Lists Hatena Blog fixed pages in newest-first order, including drafts. Pass the returned next_page token as page to fetch more results.

Instructions

固定ページを新しい順に一覧する。下書きも含まれる。1 ページあたりの件数は API 側で決まっており、続きを読むには戻り値の next_page を page に渡す。本文まで読みたい場合は get_page を使う。 固定ページははてなブログの有料プランでのみ利用できる。無料プランでは 404 が返る。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_pages"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNo次ページを取得するためのトークン。前回の戻り値の next_page を渡す
include_contentNo各件の本文を含めるか。true にすると出力が大きくなる

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

The description adds useful behavior beyond the readOnlyHint annotation: drafts are included, page size is API-determined, continuation uses next_page, and free plans get 404. These details help the agent understand scope and failure modes, though return structure and other error behavior are not covered.

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 description is front-loaded with the listing purpose and then adds pagination, alternative-tool guidance, and plan restrictions. It is appropriately sized with little waste, though it could be slightly more tightly grouped by concern.

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 two-parameter read-only listing tool with no output schema, the description covers ordering, draft inclusion, pagination, plan availability, and the main alternative tool. The main remaining gap is that it does not describe the returned list item shape, but that is less critical given the schema coverage.

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 the schema already documents both page and include_content. The description reinforces the page-token continuation pattern but does not explain include_content and instead points to get_page for reading bodies.

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?

The description states a specific verb and resource: listing fixed pages in newest-first order. It also distinguishes this listing operation from get_page when the body content is needed, so the agent can identify the tool’s role among 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?

It explicitly says to use get_page when the full body is needed, and it warns that fixed pages require a paid plan and return 404 on free plans. It does not compare against search_pages or list_entries, but the primary usage context is clear.

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