Journal Mandala に Claude から直接日記エントリを書き込むための MCP サーバーです。
「思考の流れ」を会話の途中でマンダラに刻みたいときに使います。
Node.js 20+
Claude Desktop (または Claude Code)
Journal Mandala の API キー （発行方法は「APIキーの取得」参照）
Related MCP server: Obsidian Nexus
npm でグローバルにインストールします。
npm install -g --install-links github:takezone/journal-mandala-mcp--install-links は必須（付けないと一時ディレクトリへのsymlinkになって起動できなくなる）。
更新するときも同じコマンドを再実行。もし過去に --install-links なしで入れて壊れている場合は:
npm uninstall -g journal-mandala-mcp
# 残骸掃除 (npm prefix は `npm prefix -g` で確認)
rm -rf $(npm prefix -g)/lib/node_modules/journal-mandala-mcp
rm -rf $(npm prefix -g)/lib/node_modules/.journal-mandala-mcp-*
npm install -g --install-links github:takezone/journal-mandala-mcp~/Library/Application Support/Claude/claude_desktop_config.json (macOS) を編集:
{
"mcpServers": {
"journal-mandala": {
"command": "journal-mandala-mcp",
"env": {
"JOURNAL_MANDALA_API_KEY": "jm_XXXXXXXXXXXXXXXXXXXXXXXX"
}
}
}
}{
"mcpServers": {
"journal-mandala-personal": {
"command": "journal-mandala-mcp",
"env": {
"JOURNAL_MANDALA_API_KEY": "jm_PERSONAL_KEY"
}
},
"journal-mandala-work": {
"command": "journal-mandala-mcp",
"env": {
"JOURNAL_MANDALA_API_KEY": "jm_WORK_KEY"
}
}
}
}それぞれ別ツールとして Claude から見えます。「work に記録して」のように自然言語で切り替え可能。
設定後は Claude Desktop を再起動。
現在は Journal Mandala 管理者（@takezone）に以下を伝えて発行してもらってください:
自分の Google アカウントのメールアドレス
ラベル名（例: alice-personal）
管理者から API キーが送られてきたら、上の設定の JOURNAL_MANDALA_API_KEY にコピペします。
Note: 将来的にブラウザで自動発行できる予定です。
Claude との会話で「今日の出来事をジャーナルに記録して」のように依頼すると、add_journal_entry ツールが呼ばれて Journal Mandala にエントリが追加されます。
提供ツール:
add_journal_entry — 日記エントリ追加title タイトル（省略可）
event 出来事（何があったか）
thought 思考（どう感じたか）
entry_date 日付 YYYY-MM-DD（省略時は JST 今日）
entry_time 時刻 HH:MM
tags タグ配列 — 文字列の配列として渡すこと
✅ 正: ["仕事", "運動"]
❌ 誤: ["[\"仕事\",\"運動\"]"] (JSON 文字列化した配列を1要素にしない)
star_rating 1-5 評価
find_entries — 最近のエントリ一覧id を取得する目的で使う。直近更新順で返す。
limit 取得件数 (デフォルト 20、最大 100)
update_entry — 既存エントリ更新id 指定で部分更新。指定したフィールドのみ上書き、省略したフィールドは維持。
id 必須
他は add_journal_entry / add_todo と同じフィールドが全て任意指定可能
使い方: find_entries で id を調べる → update_entry で更新
add_todo — Todo 追加title タスク名（必須）
thought タスクに関するメモ（任意）
entry_date 作成日（省略時は JST 今日）
due_date 期限日 YYYY-MM-DD（任意）
todo_status pending | in_progress | completed | cancelled（省略時 pending）
todo_points 見積もりポイント（任意）
is_today 今日やるリストフラグ（任意）
tags タグ配列
1: 微妙・ネガティブな出来事
2: 普通の1日（デフォルト）
3: そこそこ良いことがあった日
4: かなり良いことがあった日
5: 人生の一大イベント級
安易に 5 を付けない。基本は 2、良いことがあれば 3 or 4
title / event / thought のいずれか1つは必須です。
JOURNAL_MANDALA_API_URL — APIエンドポイント (デフォルト: https://journal-mandala.vercel.app)
Claude にツールが表示されない → 設定ファイルのJSON構文エラーの可能性。Claude Desktop の Developer メニューで MCP ログを確認
API エラー 401 → JOURNAL_MANDALA_API_KEY が無効。管理者に再発行を依頼
ネットワークエラー → Vercel の稼働状況を確認
運用者がキーを紛失した時の参考。このMCPはVercel側に保存された正本を参照するので、~/.claude.json のコピーが消えても復旧できる。
層 | 場所 | 役割 |
サーバー env var | Vercel | 初期seedの静的アカウント配列（正本） |
サーバー KV | Vercel KV (Upstash Redis) |
|
クライアント |
| 認証用のキーコピー（失くしても再取得可） |
API認証時は KV → env var の順に照合される。
プロジェクトディレクトリ（journal-mandala 本体）で:
# Vercel プロジェクトと連携（初回のみ）
vercel link --yes --project journal-mandala
# サーバー環境変数をローカルに取得
vercel env pull .env.vercel
# env var 内のキー確認
grep JM_API_ACCOUNTS .env.vercel
# KV 内のキー一覧スキャン
source .env.vercel
curl -s "${KV_REST_API_URL}/scan/0/match/jm:account:*/count/100" \
-H "Authorization: Bearer ${KV_REST_API_TOKEN}"
# 特定アカウントの中身を見る
curl -s "${KV_REST_API_URL}/get/jm:account:jm_XXXXX" \
-H "Authorization: Bearer ${KV_REST_API_TOKEN}"
# 終わったら機密情報を必ず削除
rm -f .env.vercel .vercel/project.json && rmdir .vercel 2>/dev/nullChrome で対象Googleアカウントでログイン
https://journal-mandala.vercel.app/api/enroll?label=<任意ラベル> を開く
OAuth承認 → 画面にAPIキーが1回だけ表示されるのでコピー
~/.claude.json の mcpServers.*.env.JOURNAL_MANDALA_API_KEY に反映
同じGoogleアカウントで再enrollすると、古いキーは自動失効し新しいキーに差し替わる。
APIキーはGoogleアカウントに紐付いているので、マシンが変わっても同じキーが使える（再enroll不要）。
# 1. (未インストールなら) Node.js をインストール
brew install node
# 2. MCPサーバーをグローバルインストール
npm install -g --install-links github:takezone/journal-mandala-mcp
# 3. ~/.claude.json に mcpServers を追記（既存設定を壊さないよう python でマージ推奨）
python3 - <<'PY'
import json, os
p = os.path.expanduser('~/.claude.json')
with open(p) as f: c = json.load(f)
c.setdefault('mcpServers', {})
c['mcpServers'].update({
'journal-mandala-personal': {
'command': 'journal-mandala-mcp',
'env': {'JOURNAL_MANDALA_API_KEY': 'jm_XXXXX'} # ←実キー
},
'journal-mandala-work': {
'command': 'journal-mandala-mcp',
'env': {'JOURNAL_MANDALA_API_KEY': 'jm_YYYYY'} # ←実キー
},
})
with open(p, 'w') as f: json.dump(c, f, indent=2, ensure_ascii=False)
print('updated')
PY
# 4. Claude Code を再起動（/exit → claude 再実行）既存キーが手元にない場合: 家のMacの ~/.claude.json からコピーするか、上記「復旧手順」でVercelから取得する。
分散運用のすすめ: 家Mac と 会社Mac で別キーを使うと（例: ?label=personal-home / ?label=personal-work）、片方が漏れても他方に影響せず、ローテーションも片側ずつで済む。同じキーで揃える方が利便性は高いが、好みで選ぶ。
MIT
Journal Mandala に新しい日記エントリを作成する。event (出来事: 何があったか) と thought (思考: それについてどう感じたか) は両方とも任意だが、少なくとも title/event/thought のいずれかは必須。日付を省略すると日本時間での今日の日付になる。
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | エントリのタイトル（任意。省略時は先頭20文字から自動生成） | |
| event | No | 出来事: 何があったかを事実ベースで記述 | |
| thought | No | 思考: それについてどう感じたか・何を考えたか | |
| entry_date | No | YYYY-MM-DD 形式。省略時は日本時間での今日 | |
| entry_time | No | HH:MM 形式（任意） | |
| tags | No | タグの配列（任意） | |
| star_rating | No | 1-5 の評価（任意） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes key behaviors: the tool creates a new entry (implying a write/mutation operation), specifies default values for title (auto-generated from first 20 characters) and date (today's Japan time), and mentions the requirement for at least one of title/event/thought. However, it lacks details on permissions, error handling, or response format, leaving gaps for a mutation 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?
The description is appropriately concise with two sentences that efficiently convey the tool's purpose and key constraints. It is front-loaded with the main action and avoids unnecessary details, though it could be slightly more structured by separating usage rules into bullet points for clarity.
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's complexity (7 parameters, mutation operation) and lack of annotations and output schema, the description is moderately complete. It covers the creation action, parameter requirements, and defaults, but misses details on permissions, error cases, and what the tool returns, which are important for a write tool with no structured output information.
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?
The schema description coverage is 100%, providing detailed descriptions for all 7 parameters. The description adds minimal value beyond the schema by mentioning that event and thought are optional but at least one of title/event/thought is required, and that the date defaults to today's Japan time if omitted. This aligns with the baseline of 3 when the schema does most of the work.
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?
The description clearly states the tool's purpose: 'Journal Mandala に新しい日記エントリを作成する' (creates a new journal entry in Journal Mandala). It specifies the verb (create/作成する) and resource (journal entry/日記エントリ). However, since there are no sibling tools mentioned, it cannot demonstrate differentiation from alternatives, preventing a score of 5.
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 implied usage guidance by stating that at least one of title/event/thought is required, and that the date defaults to today's date in Japan time if omitted. However, it lacks explicit guidance on when to use this tool versus alternatives (none mentioned) or any prerequisites or exclusions, keeping it at a basic level.
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.1.0add_journal_entryScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined as adding journal entries, and no other tools exist to cause confusion.
A single tool inherently has perfect naming consistency, as there are no other tools to compare it against. The name 'add_journal_entry' follows a clear verb_noun pattern (add + journal_entry).
A single tool for a journaling server is too few for the apparent scope. Journaling typically involves operations like viewing, updating, deleting, or searching entries, but this server only supports adding entries, which severely limits functionality.
The tool surface is severely incomplete for a journaling domain. It only allows adding entries, with no tools for retrieving, updating, deleting, or searching entries. This creates dead ends for agents, as they cannot perform basic CRUD operations beyond creation.
Plan trips directly into TravelOwl from a conversation with Claude.
First strength app Claude can write to: plan training in chat, it lands in the app ready to log.
Notes and actions in one app. Let Claude or ChatGPT read and update them.
Handwritten iPad journal your AI can read and write tasks back to, over MCP.