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.
自分が触れてきたメディアの記録（本・映画・アニメ・ゲーム）を提供する最小の MCP サーバーです。3つのツールで記録を横断検索・集計できます。読書記録は Bookmeter のエクスポートをそのまま利用します。
旧リポジトリ名は
bookmeter-mcpです。読書記録だけの MCP から全メディア対応へ拡張したのに合わせて改名しました。
使い方は2通りあります。
ローカル(stdio) — 自分の PC の Claude Desktop / Claude Code から使う。セットアップが最も簡単。
リモート(AWS Lambda) — claude.ai(Web) やモバイルアプリからも使う。公開エンドポイントを立てる。
いずれも type（book / audiobook / movie / anime / drama / variety / game）で種別を絞り込めます。未指定なら全種別を横断します。
search_media(keyword, type?, limit=20) — タイトル・作者をキーワード検索（「これ読んだ/観た/やった?」判定用）
media_by_creator(creator, type?) — 指定した作者（著者・監督・開発元など）の記録を全件返す
media_stats(type?, topCreators=10) — 総件数・種別内訳・作者別トップN・年別件数を集計
Related MCP server: LibraryQuietSpot MCP
git clone <このリポジトリのURL>
cd media-log-mcp
npm install
node server.mjsnode server.mjs を実行して、エラーなく起動しプロセスが待機状態になっていれば起動確認は完了です
（stdio 前提のサーバーなので、ターミナルで単体実行しても何も表示されずに待機し続けるのが正常動作です。
終了する場合は Ctrl+C で止めてください）。
npm パッケージとして公開しているわけではないため、npx ではなく node コマンドで直接起動します。
設定ファイル（例: Claude Desktop の claude_desktop_config.json）に以下のように追記してください。
args の値は、クローンした先の server.mjs への絶対パスに置き換えます。
{
"mcpServers": {
"media-log": {
"command": "node",
"args": ["/絶対パス/media-log-mcp/server.mjs"]
}
}
}設定後、MCP クライアントを再起動すると media-log サーバーが認識され、上記3つのツールが利用できます。
claude.ai(Web) やモバイルアプリからも使いたい場合、AWS Lambda に立てて「リモート MCP コネクタ」として登録します。ローカルの stdio サーバーは claude.ai(Web) からは使えないため、Web で使うにはこちらが必要です。
AWS Lambda + Function URL（認証なし）/ Node.js 22.x（arm64）
トランスポート: Streamable HTTP（stateless、単一 JSON 応答）
Express アプリ（app.mjs）を @codegenie/serverless-express で Lambda ハンドラ（lambda.mjs）に載せる
ツール定義（mcp-server.mjs）は stdio 版とリモート版で共有
費用: Lambda 無料枠内（月100万リクエスト）。API Gateway も WAF も使わないので実質 $0/月
IP制限 — Lambda ハンドラで送信元 IP を検査し、Anthropic の outbound レンジ 160.79.104.0/21（公式）以外を 403 で拒否
URL秘匿 — MCP エンドポイントのパスを推測困難なランダム文字列にする（/mcp/<ランダム>）。パスは環境変数 MCP_PATH で渡し、コードには含めない
books.json自体は公開リポジトリに含まれるため、上記はデータ機密性というより無駄なアクセス・DoS を防ぐ目的です。
AWS アカウントと認証済みの AWS CLI
AWS SAM CLI
# 1. 秘匿パスを生成（出力の32文字hexをメモ）
openssl rand -hex 16
# 2. デプロイ（McpPath に /mcp/<生成した文字列> を渡す）
sam deploy \
--stack-name media-log-mcp \
--resolve-s3 --capabilities CAPABILITY_IAM \
--region ap-northeast-1 \
--parameter-overrides 'McpPath=/mcp/<生成した文字列> AllowedCidr=160.79.104.0/21'デプロイ後、出力の FunctionUrl の末尾に秘匿パスを付けたものが MCP エンドポイントです:
https://xxxx.lambda-url.ap-northeast-1.on.aws/mcp/<生成した文字列>
パラメータ | 意味 | 既定 |
| MCP エンドポイントの秘匿パス | (必須) |
| 許可する送信元 IP レンジ |
|
スタック名を後から変えることはできません（変えると別スタックが新規作成されて Function URL が変わり、コネクタの再登録が必要になります）。
自分の PC から疎通確認したいときは、一時的に
AllowedCidrを自分のグローバル IP（curl https://checkip.amazonaws.comの結果）の/32にしてデプロイし、確認後に160.79.104.0/21へ戻します。本番レンジのままだと、Anthropic のクラウド経由（＝Claude から）以外はすべて 403 になります。
Settings > Connectors（設定 > コネクタ）を開く
Add custom connector（カスタムコネクタを追加）
上記の MCP エンドポイント URL（秘匿パス込み）を入力。認証（OAuth）は不要
追加後、チャットの「+」からコネクタを ON にして使う
無料プランでも1個まで登録できます。一度登録すれば Web・モバイル・Desktop すべてで使えます（新規登録は Web / Desktop 推奨）。
メディア種別ごとに JSON ファイルを分けて管理します。記録の追加・修正はファイルを直接編集して git にコミットする運用です（リモート版は再デプロイで反映）。
種別 | ファイル | パス上書き用の環境変数 |
本（Bookmeter） |
|
|
本（Kindle購入分） |
|
|
オーディオブック |
|
|
映画 |
|
|
アニメ |
|
|
ドラマ |
|
|
バラエティ |
|
|
ゲーム |
|
|
Bookmeter からのエクスポート形式をそのまま温存しています。読み込み時に下記の共通スキーマへ正規化されます。
フィールド | 内容 |
| タイトル |
| 著者 |
| 日付（ |
| 感想文 |
| Amazon画像URL |
| Amazon商品ページURL |
最初から共通スキーマで記録します。title 以外は省略可で、任意の追加フィールドも
そのまま検索結果に含まれます。
[
{
"title": "作品タイトル",
"creator": "監督・開発元など",
"date": "YYYY-MM-DD",
"review": "感想",
"url": "関連URL"
}
]date は「自分が観た・遊んだ時期」。日付まで不明なら "2010頃" のような年表記でもよい
（集計は文字列中の4桁年を拾う）。完全に不明なら空文字
通称・略称で検索できるよう、title に "ゼルダの伝説 ティアーズ オブ ザ キングダム (ティアキン)" の
ように括弧で併記する（検索対象は title + creator のみのため）
任意フィールドの例:
favoriteRank — 「好きな作品トップ10」の順位（movies / games で使用）
platform / hours — 機種・プレイ時間/視聴時間（games / 映像記録で使用）
status — played（プレイ済み）/ tried（1時間以下の試遊、映像・オーディオブックでは冒頭だけのちょい見・ちょい聴き）/ playing（プレイ中）/ purchased（Kindleで購入したが読了記録なし）
dateLast / episodes / source — 視聴期間の終端・視聴話数・記録の出典（Prime Video 視聴履歴からの取り込み分で使用。date は初回視聴日）
progress — オーディオブックの聴取進捗（%。audiobooks で使用）
purchasedDate — Kindle 購入日（読了日が date に入っている場合の補助。kindle-books で使用）
同じ種別を複数ファイルに分けることもできます（
SOURCESに同じtypeの行を複数書く。例:books.jsonとkindle-books.jsonはどちらもbook）。
新しい種別（ドラマなど）を増やす場合は、mcp-server.mjs の SOURCES に1行足して
対応する JSON ファイルを置くだけです。
指定した作者(著者・監督・開発元など)のメディア記録を全件返す。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.
