Read-only access to a personal media log (books, audiobooks, movies, anime, drama, variety, games) — search, browse by creator, and get stats, with no write tools exposed.
search_media(keyword, type?, limit=20) — keyword search on title/creator across all types or one type; used to check "have I read/watched/played this?"
media_by_creator(creator, type?) — return all records for a given author, director, or developer
media_stats(type?, topCreators=10) — totals, per-type breakdown, count of entries with reviews, top creators, and per-year counts
Optional type filter values: book, audiobook, movie, anime, drama, variety, game
Cannot add, update, delete records, or discover external candidates — this schema exposes read-only tools only
Provides tools to search books by keyword or author, and aggregate reading statistics (total books, top authors, books per year) from a Bookmeter reading log.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bookmeter-mcp show my reading stats"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
自分が触れてきたメディア（本・映画・アニメ・ドラマ・ゲームなど）の個人台帳です。Claude との会話（MCP）とローカルの Web UI から、同じデータを検索・登録・編集できます。
旧リポジトリ名は
bookmeter-mcpです。v0.4.0 で参照専用から書き込み可能な台帳へ移行しました。
Claude Code / Desktop ──stdio──┐
ローカル Web UI (127.0.0.1) ────┼── lib/service.mjs ── S3: media.json（正本・Versioning）
claude.ai / モバイル ──HTTPS──┘ （全入口で共通）
└─ リモート版は読み取り専用正本は S3 の media.json 1ファイル。約1MB・2,700件規模なので、全件をメモリに載せて部分一致検索する。DB は使わない（部分一致検索と噛み合わないため）
書き込みは ETag を使った条件付き書き込み。別の入口が先に書いていたら最新を読み直して再適用し、黙って上書きしない
巻き戻しは S3 Versioning。古い版は30日で自動削除
業務ロジックは lib/ にだけ置き、MCP（mcp-server.mjs）と Web UI（web.mjs）は入口として呼ぶだけ
入口 | 書き込み | 身元の確認 |
ローカル stdio（ | 可 | 自分のPCにログインできること |
ローカル Web UI（ | 可 | 127.0.0.1 限定。Host 検査と独自ヘッダで他サイトからの要求を拒否 |
リモート（Lambda / | 不可 | IP制限＋URL秘匿のみ。本人確認にならないため書き込みツールを登録せず、IAM でも S3 の読み取りしか許可しない |
Related MCP server: LibraryQuietSpot MCP
type は book / audiobook / movie / anime / drama / variety / game。
status は done（読了・鑑賞済）/ doing（進行中）/ tried（ちょい見・試遊）/ owned（所有・未消化）/ want（これから）/ dropped（途中でやめた）。
ツール | 内容 | リモート |
| タイトル・作者で検索（「これ読んだ?」判定）。結果の | ○ |
| 作者別の全件 | ○ |
| 件数・種別・status・作者・年の集計 | ○ |
| 外部DBから登録候補を探す（登録はしない） | — |
| 1件登録。 | — |
| 部分更新。 | — |
| 1件削除 | — |
登録は「discover_media で候補を出す → 1件を選ぶ → add_media に externalId と自分の status / date / review を渡す」の2段階。上位の候補を自動で採用しないのは、同名の別作品や版違いを混ぜないため。
種別 | 候補検索 | 必要なキー |
book | Google Books |
|
movie / anime / drama / variety | TMDB |
|
game / audiobook | なし |
|
書籍は ISBN を isbn:978… として持ち、既存の Amazon ASIN（amazon:asin:… = ISBN-10）と同じ本として重複判定する。
npm install設定はリポジトリの外の ~/.config/media-log-mcp/env に置く（API キーを誤ってコミット・Lambda へ同梱しないため）。MEDIA_LOG_ENV で場所を変えられる。
MEDIA_STORE=s3://<バケット名>/media.json # sam deploy の出力 MediaStore
AWS_REGION=ap-northeast-1
GOOGLE_BOOKS_API_KEY=... # 任意
TMDB_API_KEY=... # 任意S3 へのアクセスには AWS CLI と同じ認証情報（~/.aws）を使う。
{
"mcpServers": {
"media-log": { "command": "node", "args": ["/絶対パス/media-log-mcp/server.mjs"] }
}
}stdio 版は書き込みツールも有効。読み取り専用にしたいときは "env": { "MEDIA_LOG_READONLY": "1" }。
npm run web # → http://127.0.0.1:4319一覧・絞り込み（種別 / 状態 / 画像なし / 感想なし）・並べ替え・編集・削除・候補からの登録ができる。
claude.ai（Web）やモバイルアプリから検索するための読み取り専用版。
Lambda + Function URL（認証なし）/ Node.js 22.x（arm64）、Streamable HTTP（stateless）
防御は2段: 送信元 IP を Anthropic の outbound レンジ 160.79.104.0/21 に限定し、パスを推測困難なランダム文字列にする（MCP_PATH）
台帳は S3 から読む。warm な Lambda はメモリ上の台帳を使い回し、リクエストごとに ETag で変更の有無だけ確認する（変更が無ければ 304 で本文は転送されない）
費用: Lambda・CloudFront は常時無料枠内。S3 は12ヶ月無料枠を過ぎると従量だが月 $0.01 程度
openssl rand -hex 16 # 初回のみ: 秘匿パスを生成
npm run deploy # = scripts/build-lambda.sh && sam deploy初回は sam deploy --guided で McpPath=/mcp/<生成した文字列>・AllowedCidr=160.79.104.0/21 を渡す（値は samconfig.toml に保存され、このファイルは .gitignore 済み）。
scripts/build-lambda.shは Lambda に必要なファイルだけをdist/に集める。SAM CLI は.samignoreを読まないため、リポジトリ直下をCodeUriにすると.git/やsamconfig.tomlまでパッケージに入る。
デプロイ後、出力の FunctionUrl の末尾に秘匿パスを付けたものが MCP エンドポイント。claude.ai の Settings > Connectors > Add custom connector に登録する（OAuth 不要）。
旧形式（種別ごとの JSON 8ファイル）は v0.4.0 で S3 の単一台帳へ移行し、リポジトリからは削除した。移行はコミット 9aa7ecc の JSON から再現できる（同じ入力なら ID も含めて同一の出力になる）:
mkdir -p /tmp/legacy && git archive 9aa7ecc -- '*.json' ':!package*.json' | tar -x -C /tmp/legacy
node scripts/migrate.mjs --from /tmp/legacy --out ./media.json --at 2026-09-25T00:00:00.000Zレコードの主な項目（lib/schema.mjs）:
項目 | 内容 |
| 不変の識別子（ |
| 必須。通称は |
| 著者・監督・開発元 |
| 自分固有の情報。 |
| 外部の情報。画像は外部 URL をそのまま持つ |
| 種別固有・取り込み元 |
| 自動 |
npm test指定した作者(著者・監督・開発元など)のメディア記録を全件返す。type未指定なら全種別を対象にする
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| creator | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It only states the basic operation without disclosing pagination, limits, ordering, or authentication needs. Lacks depth for a mutation-free read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no filler. Every word is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal description for a tool with no output schema. Does not describe return format, ordering, or potential limits. Agent may lack information to handle results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning by clarifying that 'creator' can be author, director, etc., and that type defaults to all. However, with 0% schema description coverage, more detail on expected formats or examples would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns all media records for a specified creator, and specifies behavior when type is not given. It differentiates from siblings like search_media (broader search) and media_stats (statistics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when querying by creator, but does not explicitly state when to use this over siblings or provide exclusions. No direct comparison to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
メディア記録の総件数・種別内訳・感想を書いた数・作者別トップN・年別件数を集計する。type指定でその種別のみ集計
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| topCreators | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses aggregation behavior and optional type filtering, but does not mention side effects, read-only nature, or authentication needs. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with two clauses, no redundancy. Information is front-loaded: what it aggregates and optional filtering. Efficient but could be better structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations. Description doesn't specify return format or behavior when no type is given. For a stats tool, more context on output structure would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It only covers 'type' (filter by that type), but does not explain 'topCreators' parameter. Missing semantics for one of two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it aggregates total records, type breakdown, review counts, top creators by count, and annual counts. This is specific and actionable, though doesn't explicitly differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like media_by_creator or search_media. The description implies it's for statistics, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
タイトル・作者のキーワードでメディア記録(本・映画・アニメ・ゲーム)を検索する（「これ読んだ/観た/やった?」判定用）。type未指定なら全種別を横断検索
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| keyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose behavioral traits such as pagination, ordering, case sensitivity, or error handling. The description is too brief for an AI agent to understand all behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the key action and purpose. Every word is meaningful, and it avoids repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no output schema, and no annotations, the description provides minimal context. It clarifies the search scope and type behavior but lacks details on sorting, pagination, or result structure, which would be needed for full correctness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides partial semantics: keyword is for title/author, type filters by media type (with default of all if unspecified). However, it does not explain the limit parameter or provide format details for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches media records (books, movies, anime, games) by keyword in title/author, and mentions the use case for 'have you read/watched/played?' judgment. It distinguishes from sibling tools like media_by_creator by being a general keyword search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (for checking if someone has consumed a media item) and implies that if type is unspecified, all types are searched. However, it lacks explicit guidance on when not to use this tool versus alternatives like media_by_creator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0media_by_creatormedia_statssearch_mediaScored across 3 tools
Each tool has a clearly distinct purpose: retrieving records by creator, aggregating statistics, and searching by keyword. No overlap.
All names follow a consistent verb_noun snake_case pattern: media_by_creator, media_stats, search_media.
3 tools is on the lower end but acceptable for a query-focused server. However, it feels slightly thin for a media tracking service.
Missing essential tools for adding, updating, or deleting media records, and no tool to retrieve a single record by ID. The surface is read-only, which is a significant gap.
Search books and authors, fetch editions, browse subjects, and resolve cover images.
Search books, authors and series, get recommendations, and manage your own reading shelves.
Search Chinese books with Douban ratings, AI book guides and curated toplists. Free, no API key.
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
