Skip to main content
Glama
dcazman

Claude-Atlas-MCP

by dcazman

Claude-Atlas-MCP

セルフホスト型のMCPサーバーで、Claudeに会話をまたいで持続的なメモリを提供します — エンティティ、オブザベーション、履歴、タイマー付きリマインダー、さらに到着したものを一時的に置くトレイやアイデアを保管する棚 — これらすべてを軽量なNode/SQLiteバックエンドで自分で実行します。

ClaudeにMCPコネクタとして指定すれば、進行中のプロジェクト、決定事項とその理由、あなたや環境に関する事実、将来の日付で再表示するものなど、会話をまたいで覚えておくことができます。

なぜ

Claudeは会話が終わるとすべてを忘れます。Atlasは、小さくて退屈で耐久性のあるメモリレイヤーであり、エンドツーエンドで自分が所有します — サードパーティのサービスもベンダーロックインもありません。単一のNodeプロセスで、1つのSQLiteファイルに支えられています。ホームサーバー、VPS、ラップトップのいずれでも実行できます。

意図的に最初は空です。あなたの人生のスキーマは組み込まれておらず、想定される仕事も、必須の課題トラッカーもありません — 使うにつれて埋まっていく形だけがあります。

Related MCP server: memory-mcp

クイックスタート

git clone https://github.com/dcazman/Claude-Atlas-MCP.git
cd Claude-Atlas-MCP
docker compose up -d --build
docker compose logs atlas-mcp

.envもトークンも設定も不要です。初回起動時にAtlasがデータベースを作成し、スコープごとに1つのトークンを生成して表示します:

    work     3f2a…   (caller "work-client")
    personal 9c41…   (caller "personal-client")
    shared   b7e0…   (caller "shared-client")

  Connect a client to:  http://localhost:7784/atlas-mcp?token=<one of the above>

トークンはデータベースの隣に保存され、再起動ごとに再利用されます。データは./data、単一のSQLiteファイルに格納されます。これで設定は完了です。

動作確認:

curl -s localhost:7784/health
# {"ok":true,"service":"atlas-mcp","version":2,"port":"7784"}

TOKEN=<one of the tokens printed above>
curl -s -X POST localhost:7784/atlas-mcp \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -H "x-atlas-token: $TOKEN" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":
       {"name":"add_observation","arguments":
        {"section":"work","entity":"Atlas","content":"Installed today."}}}'

observation_idが返ってくれば、スタック全体が機能しています:最初のメモリがディスクに保存され、Claudeがそれを読み取れます。

CIはmainへのプッシュごとにイメージを公開します。自分でビルドしたくない場合:

docker run -d --name atlas -p 7784:7784 -v "$PWD/atlas-data:/app/data" \
  ghcr.io/dcazman/claude-atlas-mcp:latest
docker logs atlas

ベアNode — 22.13以上で組み込みのnode:sqliteを使用。ネイティブ依存関係なし、コンパイル不要:

npm install
npm start

独自のトークン、タイムゾーン、グルーム時間をデフォルト以外にしたい場合は、 cp .env.example .env して必要な行をコメント解除します。編集せずにコピーしても何も変わりません — すべての行は意図的にコメントアウトされています。

データモデル

概念

説明

エンティティ

Claudeに追跡させたいトピックやプロジェクト(例:「ホームネットワーク」、「Q3計画」)。名前と1行の概要を持ちます。

オブザベーション

エンティティに紐づく単一の事実(「2026-06-01にルーターを6Eバンドに切り替えた」)。メモリの最小単位。その場で編集可能で、保護マークを付けると修正はできるが削除はできなくなります。

履歴イベント

発生した注目すべき出来事で、後で思い出すためにタイムラインに記録されます。

リマインダー

trigger_dateを持つメモ。日付が来ると会話の開始時に自動的に表示され、却下されるまで残ります。trigger_timeを追加するとタイムドリマインダーになり、それをポーリングする何かによって一度だけ配信されることを意図します。

トレイアイテム

到着したもので、トリアージが必要だが現在の作業を中断させたくないもの。今キャプチャして、後で判断します。

棚アイテム

あなた自身のアイデアの1つ。日付もプレッシャーも経過もありません。

セクション

トップレベルの名前空間 — work、personal、shared。すべてのツール呼び出しはsectionを受け取ります。sharedはworkスコープとpersonalスコープの両方のトークンがアクセスできる引き継ぎチャネルです。get_landscapeはそれを取得するセクションにマージします。

ファネル

コミットメントの度合いが増す3つのサーフェス:

  shelf  ──graduate──▶  tray  ──promote──▶  memory
 (ideas)              (triage)          (observations)
  • 棚はあなたが思いついたものを保持します。1年間そこにあるアイデアはバックログの失敗ではなく、棚が機能している証拠です。アイデアはトレイに昇格するか、理由を残して意図的に破棄されることで棚を離れます。

  • トレイは到着したものを保持します。山積みではなくキューです:キャプチャしてから、昇格、マージ、または却下します。

  • メモリはClaudeが会話の開始時に読み戻す部分です。

途中で何も破棄されません。解決済みのアイテムは表示されなくなりますが、履歴(何に変わったかを含む)は保持されます。

実際にこれらをどう見るか。 get_landscapeはClaudeが会話の開始時に呼び出す唯一の呼び出しなので、注意が必要なものはすべてそれに含まれていなければなりません:

サーフェス

ランドスケープ内での扱い

理由

メモリ

完全に表示

会話が実行されるコンテキストだから

期限切れリマインダー

完全に表示

再表示の目的そのもの

トレイ

完全に表示

未トリアージのキャプチャはあなたの判断を待っている

棚

カウントのみ

毎回の会話ですべてのアイデアを読み上げると、プレッシャーのない棚がうるさいバックログになってしまう — カウントは「何かある」ことを示し、research_listで要求時に表示する

つまり「今キャプチャして、後で判断する」が機能します:会話の途中でトレイに落としたものは、あなたがその存在を覚えていなくても、次の会話の開始時に戻ってきます。

ツール

31個のMCPツール。

読み取り

  • get_landscape — セクション内のすべて(sharedをマージ):すべてのエンティティとそのオブザベーション、期限切れリマインダー、未トリアージのトレイアイテム、オープンな棚アイデアの数。会話の開始時に呼び出して状況を把握します。

  • search — エンティティ、オブザベーション、履歴を横断したキーワード検索。

  • get_entity — 名前で1つのエンティティとそのオブザベーションを取得。

  • get_observation — IDで最大20個のオブザベーションを直接取得。IDは安定しており再利用されないため、特定の事実を会話間で渡す安価な方法になります。

  • get_history — 記録されたイベントのタイムライン。

  • get_time — 現在時刻と、このトークンの最後の呼び出しからの経過時間。

書き込み

  • upsert_entity — エンティティの名前/概要を作成または更新。

  • add_observation — エンティティに事実を追加。

  • update_observation — 事実をその場で編集;IDは安定。保護された行でも動作。

  • remove_observation — 古くなった、または完了した事実を削除(保護されている場合は拒否)。

  • protect_observation / unprotect_observation — 事実を削除不可にする、またはその解除。

  • remove_entity — エンティティとそのオブザベーションを削除(保護されているものがある場合は拒否)。

  • log_event — 注目すべきイベントを履歴に記録。

リマインダー

  • create_reminder — trigger_date、オプションのtrigger_time、オプションのエンティティリンクを持つメモ。

  • list_reminders — スケジュールされたすべて(期限切れかどうかに関わらず)。

  • list_due_reminders — 現在期限切れのすべて。通知ツールがポーリングするためのもの。

  • mark_reminder_fired — タイムドリマインダーに配信済みのスタンプを押し、二度と発火しないようにする。

  • dismiss_reminder — リマインダーを処理済みとしてマーク(表示されなくなる)。

  • remove_reminder — リマインダーを完全に削除。

トレイ

  • pending_add — 到着したものをキャプチャ。

  • pending_list — まだトリアージが必要なもの、古い順。

  • pending_promote — キャプチャをエンティティのオブザベーションに昇格。

  • pending_merge — 重複を保持する方に統合。

  • pending_dismiss — 何も必要ないと判断、理由は保持。

  • pending_reopen — 上記のいずれかを元に戻す。

棚

  • research_add — アイデアを置く。

  • research_list — オープンなアイデア、古い順。

  • research_promote — アイデアをトレイに昇格。

  • research_kill — アイデアを理由を添えて意図的に終了。

  • research_reopen — 元に戻す。

すべてのツール応答には小さな時間フッターが含まれます — 設定されたタイムゾーンの現在のサーバー時刻と、そのトークンの最後の呼び出しからの経過時間 — これにより、モデルは古いメンタルクロックから推測したり日付計算をしたりする必要がなくなります。

通知を受け取る

Atlasは決して自分からプッシュしません — どこに連絡してほしいかを知りません。代わりに、list_due_remindersが通知を行うものとの契約です:

  1. 任意の間隔でlist_due_remindersをポーリングします。

  2. trigger_timeを持つ行を配信します(受動的なものはランドスケープで見られるのを待っているだけです)。

  3. 配信した各リマインダーに対してmark_reminder_firedを呼び出します。

ステップ3が正確に一度の配信を保証します:スタンプはSQLで保護されているため、重複するポーラーが二重送信できません。cron駆動のスクリプト十数行で、これをメール、チャットwebhook、電話通知に接続するのに十分です。

グルームワーカー

src/groom.jsはサーバープロセス内で毎晩実行されます(ホストcron不要)。またはnpm run groomでオンデマンド実行も可能です。意図的にレポートのみで機械的 — LLM呼び出しもデータ削除も行いません:

  • エンティティ内で類似したオブザベーションの可能性があるものをフラグ付け

  • 休眠エンティティ(60日以上未使用)をアーカイブ/圧縮候補としてフラグ付け

  • 長期間却下されたリマインダー(90日以上)を削除候補としてフラグ付け

  • 自身のaudit_log(90日以上)をローテーション — 実際に削除するのはこれだけ

  • 前回の実行以降触れられていないエンティティはスキップするため、繰り返し実行は軽量

結果はセクションごとの「Groom Report」エンティティに保存され、あなた(またはClaude)が対処できます。タイムゾーンのATLAS_GROOM_HOUR(デフォルト午前4時)に実行され、自己修復します:コンテナがダウンしていたためにウィンドウを逃した場合、次のチェック時に実行されます。

Claudeに接続する

Atlasはストリーム可能HTTPでMCPを話し、POST /atlas-mcpで待ち受けます。サーバーのURLとトークンを使用してコネクタとして追加します:

https://<your-host>/atlas-mcp?token=<your-secret>

トークンはATLAS_TOKENトリプルの秘密の部分です(設定を参照)。クエリ文字列の代わりにX-Atlas-TokenヘッダーまたはBearerトークンとして渡すこともできます。

URLにsectionはありません — すべてのツールはsection引数を受け取り、特定の会話がデフォルトでどのセクションを使うかは、Claudeプロジェクトのカスタム指示で設定するのが最適です(例:「あなたのAtlasセクションはpersonalです」)。GET /healthエンドポイントが死活監視用に利用可能です。

実際の使用ではHTTPSの背後に置く必要があります — コンテナの前にリバースプロキシまたはトンネル(Cloudflare Tunnel、Tailscale、nginxなど)を配置します。トークンが唯一の認証であるため、TLSなしでポートを公開しないでください。

接続したら、Claudeに各会話の開始時にget_landscapeを呼び出させ、変更があったらエントリを更新し続けるのが良い習慣です。サーバーにはその旨の指示が同梱されているため、ほとんどのクライアントは何も書かずにそれを拾います。

セキュリティ

Atlasの組み込み認証は共有トークンです — プライベートネットワークやトンネルの背後では問題ありませんが、インターネットに公開する場合は薄いです。実際のアクセス制御には、このサーバー自体を強化するのではなく、専用の認証ゲートウェイを前に配置してください。

mcp-auth-proxy は、MCP サーバー用のプラグアンドプレイ OAuth 2.1 / OIDC ゲートウェイです。Atlas にコード変更は一切不要です。

  • 自社の IdP(Google、GitHub、Okta、Auth0、Azure AD、Keycloak、任意の OIDC プロバイダー)に対して認証。パスワードもオプションで設定可能。

  • 完全一致または glob(例:*@yourcompany.com)でユーザーを認可。

  • TLS を終端し、HTTP トランスポートをそのままプロキシ。Claude、Claude Code、ChatGPT、Copilot、Cursor で動作確認済み。

大まかには、Atlas の HTTP エンドポイントを指定するだけです。

./mcp-auth-proxy \
  --external-url https://<your-domain> \
  --tls-accept-tos \
  -- http://localhost:7784/atlas-mcp

IdP のセットアップと設定についてはドキュメントを参照してください。(提携関係はありませんが、このようなセルフホスト型 MCP サーバーにぴったりです。)

設定

すべてオプションです。.env(.env.example を参照)または環境変数で設定します。

変数

目的

ATLAS_TOKEN

カンマ区切りの caller:secret:scope トリプレットを 1 つ以上指定。スコープは必須 — work(work + shared にアクセス)、personal(personal + shared にアクセス)、shared(shared のみにアクセス)。すべての呼び出しでサーバー側で強制され、スコープ外のリクエストは 403 で拒否されログに記録されます。未設定の場合、Atlas は初回起動時にスコープごとにトークンを生成し、データディレクトリ内の first-run-tokens.txt に保存します。

ATLAS_TZ

リマインダー、フッターの時刻、グルームウィンドウに使用する IANA タイムゾーン(例:America/Chicago、Europe/Berlin)。デフォルトはホストの TZ、次いで UTC。

ATLAS_GROOM_HOUR

夜間のグルームを開始できるローカル時刻(0~23、デフォルトは 4)。

PORT

リスンポート(デフォルトは 7784)。

ATLAS_DB_PATH

SQLite ファイルへのパス(src/ からの相対パスのデフォルトは ../data/atlas.db;Docker イメージでは /app/data/atlas.db)。

カスタマイズ

設計は意図的に小規模に保たれており、拡張が容易です。

  • ツールを追加する。 すべてのツールは src/tools.js にあり、スコープチェックと監査書き込みを行う単一の guarded() ラッパーを介して登録されます。新しいツールは、guarded(name, {description, inputSchema}, handler) ブロックと src/db.js 内の関数です。説明はコードよりも重要です。Claude がいつそのツールを使用するかを判断する材料となるからです。

  • テーブルを追加する。 マイグレーションは src/db.js の PRAGMA user_version ラダーです。番号を上げ、その番号でガードされた追加の SQL を書き、完了です。すべてのマイグレーションは冪等で、起動時に実行されるため、アップグレードは再起動するだけです。

  • ルールをデータベースにプッシュする。 ここでの設計思想は「覚えておかなければならないルールは守られないルール」です。そのため resolved_at はトリガーでスタンプされ、スコープはサーバー側で強制され、保護された行は SQL で保護されます。このパターンに従えば、追加した機能も同じ保護を継承します。

  • セクションを変更する。 work/personal/shared はスキーマの CHECK 制約と src/server.js のスコープマップに固定されています。名前の変更はマイグレーションと 2 行のマップ編集で可能です。用語が生活に合わない場合は検討する価値があります。

テスト

npm test

すべての実行は空のデータベースから開始されるため、テストスイートはクリーンスレートのチェックを兼ねています。スキーマがゼロから構築され、トークンスコープマトリックスが正しく機能し(スコープ外の ID が存在しない ID と区別できないことを含む)、時間指定リマインダーが正確に 1 回だけ発火し、ファネルがアイテムを意図したとおりに移動することを確認します。

セキュリティ

脅威モデル、デプロイ時の強化に関する注意事項、脆弱性の報告方法については、SECURITY.md を参照してください。

変更履歴

CHANGELOG.md を参照してください。概要:v3 では、トレイ、シェルフ、時間指定リマインダー、観測 ID アドレッシング、ゼロコンフィグ起動が追加されました。

ライセンス

MIT — LICENSE を参照してください。

Maintenance

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers