dhruvのObsidian MCP

この夏、MLコンパイラとOSの概念を学習する予定なので、学習状況を追跡するためにObsidianボルトをセットアップしました。

偶然にもMCPを使った開発経験も積みたいと考えていたため、Codexに接続し、学習の評価方法やプロジェクトが正しい方向に向かっているかを確認するためのポインターを提供するMCPサーバーを作成することにしました。

今後のアップデートにご期待ください！まだ始まったばかりです ☺︎

ロードマップ

このプロジェクトは、Obsidianボルトを構造化されたコンパイラ学習インターフェースに変えるためのローカルMCPサーバーです。

目標は単に「AIが私のノートを読める」ことではありません。目標は、以下を備えた真のMCPネイティブ学習システムを構築することです：

計算と分析のためのツール
安定したコンテキストサーフェスのためのリソース
再利用可能なワークフローのためのプロンプト

現在のステータス

フェーズ 1 — 既存のMCP統合

[x] Codexを既存のObsidian MCPサーバーに接続
[x] ボルトへの基本的なアクセスとノートの要約を検証

フェーズ 2 — カスタムローカルMCPサーバー

[x] カスタムPython MCPサーバーの構築
[x] 初期ツールの公開:
- [x] extract_concepts
- [x] get_learning_gaps
- [x] generate_study_session
- [x] compare_notes_to_project
[x] Codexへのサーバー登録
[x] MCP Inspectorによる検証
[x] ローカルでのエンドツーエンドのツール呼び出しの動作確認

次のステップ

フェーズ 3 — MCPインターフェースの具体化

目標：「ツールの寄せ集め」から、真のMCPベースの学習インターフェースへと進化させる。

3.1 リソース

学習システムの安定した、検査可能なビューを公開する。

計画中のリソース:

[x] vault://compiler/concepts
[x] vault://compiler/gaps
[x] vault://compiler/recent-notes
[x] vault://project/alignment
[x] vault://weekly-review/latest

理由:

ツールはアクションに適している
リソースは永続的なコンテキストに適している
これにより、サーバーが単発の関数ではなく、システムのように感じられるようになる

3.2 プロンプト

MCPを通じて再利用可能なワークフローテンプレートを直接追加する。

計画中のプロンプト:

[ ] weekly_learning_review
[ ] generate_study_plan
[ ] notes_vs_project_analysis
[ ] paper_to_implementation_breakdown

理由:

優れたプロンプトの言い回しを覚える必要がなくなる
繰り返されるワークフローをファーストクラスのインターフェースに変える

3.3 分析ヒューリスティックの改善

単純なキーワードカウントから、より意味のあるノート分析へとアップグレードする。

計画中の改善:

[ ] フロントマターを考慮したフィルタリング
[ ] タグを考慮した概念のグループ化
[ ] 新規性を考慮した分析
[ ] ノートの深さのスコアリング
[ ] バックリンク / ノートリンクグラフ分析
[ ] より優れた「浅い vs 深い」の検出
[ ] 単なる完全一致キーワードではなく、概念のクラスタリング

理由:

現在のヒューリスティックは有用だが原始的である
ここがサーバーの真の知能が向上する部分である

フェーズ 4 — マルチソース学習システム

目標：Markdownノートだけでなく、より多くのソースを比較・統合する。

計画中のソース:

[ ] Obsidianボルト
[ ] ローカルプロジェクトリポジトリ
[ ] 紙のノート / 読書ノート
[ ] PDFまたはエクスポートされた論文の要約
[ ] 軽量なプロジェクトトラッカー / タスクファイル

計画中の機能:

[ ] ノートと実装の比較
[ ] 論文の概念とプロジェクトのギャップの比較
[ ] 学習したが実装していないトピックの検出
[ ] 最近の学習から実装のアイデアを生成

理由:

ここからMCPが真に高いレバレッジを発揮し始める
サーバーが学習、計画、構築の架け橋となる

フェーズ 5 — Codexワークフローの統合

目標：日常のCodexワークフロー内で、サーバーを簡単かつ自然に使えるようにする。

計画中の作業:

[ ] ツールの命名と説明の改善
[ ] 出力をより構造化され予測可能なものにする
[ ] 各MCP機能の使用タイミングに関する AGENTS.md ガイダンスの追加
[ ] 各ツール/リソース/プロンプトの例示プロンプトの追加
[ ] 手動でのツール呼び出しの言い回しの必要性を減らす

理由:

強力なMCPサーバーも、ホストやクライアントがうまく使えなければ無意味である
人間工学は機能と同じくらい重要である

将来 / 拡張のアイデア

サンプリング

将来の方向性:

[ ] MCPサンプリングを通じて、サーバーがモデル生成による統合を要求できるようにする

考えられるユースケース:

[ ] 週次レビューの自動生成
[ ] グループ化されたノートから学習ガイドを合成
[ ] ノートのクラスタから概念の要約を作成

注: これは意図的に短期的な優先事項ではありません。サーバーは、よりエージェント的な動作を追加する前に、まず強力なツール/リソース/プロンプトを備えるべきです。

リモート / ホスト版

将来の方向性:

[ ] ローカルのstdioサーバーからリモートサーバーへ移行
[ ] HTTPトランスポートのサポート
[ ] 必要に応じて認証を追加
[ ] ローカルのCodex利用を超えた、より広範なクライアントのサポート

注: これは製品化であり、直近の学習目標ではありません。

直近の優先事項

優先度 1

リソースの実装:

[x] 概念
[x] ギャップ
[x] 最近のノートのダイジェスト
[x] ノートとプロジェクトの整合性要約

優先度 2

プロンプトの実装:

[ ] 週次レビュー
[ ] 学習セッション
[ ] ノートとプロジェクトの比較

優先度 3

ヒューリスティックの改善:

[ ] フロントマターとタグのサポート
[ ] 新規性フィルター
[ ] より優れた深さのスコアリング

指導原則

このプロジェクトは以下を目指すべきです：

コンパイラ学習ワークフローのための真のMCPインターフェース

そして、以下から脱却すべきです：

緩やかに関連するノート分析関数の山

新しい機能が以下のいずれかを改善しない場合、おそらく追加すべきではありません：

学習のフィードバックループ
学習計画
ノートとプロジェクトの整合性
再利用可能なCodexワークフロー
構造化されたMCPネイティブインターフェース

Obsidian MCP Learning System