Contextberg MCP serverをnpxで接続する: 作業履歴をMCPで渡す手順
Contextberg MCP serverをnpxで起動し、Claude Code、Codex、Cursorへローカル作業履歴を渡す設定例をまとめます。MCP、Skills、ローカルAPIの役割も整理します。
Contextberg MCP serverは作業メモリへの入口になる
MCP接続の設定を探している人が知りたいのは、どのコマンドを実行すればAIエージェントから作業メモリを読めるかです。Contextbergでは、npxで起動する薄いMCP bridgeを使い、ローカルで動いているデスクトップアプリの作業履歴へ接続します。
Contextbergは、AIアプリに組み込むmemory SDKではありません。既存のClaude Code、Codex、Cursor、Claude Desktopへ、PC上の作業文脈を後付けで渡すためのlocal work memoryです。
会話履歴だけではなく、画面、ブラウザ履歴、アプリ利用、キーボード入力、エージェント履歴をまとめて、MCP経由で読ませる構成です。どのツールを使っていたかよりも、作業者の文脈がどの順序で進んだかを渡せることを重視しています。
重要なのは、接続作業をユーザーにJSON編集だけで背負わせないことです。Contextberg側ではMCP接続やSkills導入をコマンドとして提示し、必要なブロックをコピーできる形に寄せています。
接続は設定ブロックかコマンドで渡す
ContextbergのMCP接続は、基本的には各MCPクライアントのCLIにコマンドとして渡します。Codexならcodex mcp add、Claude Codeならclaude mcp addで、Contextberg用のMCP serverをstdio接続として追加する認識です。
Windowsではnpxをcmd経由で起動するため、実際に見せるコマンドはcmd /c npx -y @contextberg/mcp-serverになります。ここで起動するのは記憶本体ではなく、ローカルで起動しているContextbergアプリへつなぐbridgeです。
codex mcp add contextberg -- cmd /c npx -y @contextberg/mcp-server
claude mcp add --transport stdio contextberg -- cmd /c npx -y @contextberg/mcp-serverGUIや設定ファイルで追加するMCPクライアントでは、同じ内容を設定ブロックとして表現します。ただし、ユーザーに最初に見せる導線は、JSONを手で編集させるよりもコマンドをコピーして実行する形に寄せます。
{
"mcpServers": {
"contextberg": {
"command": "cmd",
"args": ["/c", "npx", "-y", "@contextberg/mcp-server"]
}
}
}@contextberg/mcp-serverは、npm packageの中に作業データを置くものではありません。作業データはContextbergデスクトップアプリ側にあり、MCP serverはそれをClaude Code、Codex、Cursorなどのエージェントが読める形にします。
Skillsもコマンドとして渡す
MCPはライブの作業メモリを読む入口です。一方で、agentにContextbergの使い方や呼び出しタイミングを覚えさせるにはSkillsを使います。Contextbergアプリ側では、MCP接続コマンドとSkill導入コマンドをコピーできる形にしています。
| 接続 | 使う場面 | ユーザーに見せる具体例 |
|---|---|---|
| MCP server | 直近のActivity、Daily Report、LTM、agent historyをその場で読む | codex mcp add contextberg -- cmd /c npx -y @contextberg/mcp-server |
| Skill | ContextbergのMCPをいつ使うべきかをagentに覚えさせる | npx skills add contextberg/skills |
| CLI command | MCP clientごとに接続を追加する | codex mcp add / claude mcp add / openclaw mcp set |
| Manual config | GUIやCLIが使えない環境で設定する | mcpServersにcmd /c npx -y @contextberg/mcp-serverを追加 |
npx skills add contextberg/skillscodex mcp add contextberg -- cmd /c npx -y @contextberg/mcp-server
claude mcp add --transport stdio contextberg -- cmd /c npx -y @contextberg/mcp-server
openclaw mcp set contextberg '{"command":"cmd","args":["/c","npx","-y","@contextberg/mcp-server"]}'MCPで何が読めるか
Contextberg MCP serverが返すのは、生ログの丸投げではなく、用途に合わせて整えた作業文脈です。local-first AI memoryとして、必要な粒度だけをClaude Code、Codex、Cursorから読めるようにします。
| Tool | 読むもの | 質問例 |
|---|---|---|
| get_activity | 直近N時間のActivity。アプリ、ウィンドウ、スクリーンショット、ブラウザ履歴 | 直近2時間で何をしていた？ |
| get_daily_memory | 指定日のDaily Report | 昨日の午後に進めた作業を要約して |
| get_weekly_memory | 指定週のWeekly Report | 今週の実装テーマを3つにまとめて |
| get_agent_history | Claude Code / Codex / Cursorなどの会話turn | 認証リファクタについて話した履歴を探して |
| read_ltm | Long-Term Memory全体 | このプロジェクトの前提を読んでから回答して |
| update_ltm | LTMへの差分追記 | 今後も使う制約を記憶に追加して |
接続後にどう見えるか
具体例がないと、MCP接続はただの設定作業に見えます。実際には、agentがローカル作業メモリを読めることで、回答の出発点が変わります。
昨日の午後、ContextbergのMCP接続まわりで何をしていた？
読んでいたページ、触っていたファイル、残っている確認事項を分けてまとめて。昨日の午後は、ContextbergのMCP bridgeとSkill導入導線を整理していました。
読んでいたもの:
- Claude Desktop / Claude Code / Codex / OpenClawのMCP設定
- @contextberg/mcp-serverの起動方式
- npx skills add contextberg/skills の導入導線
触っていたもの:
- ExportViewModel.cs の McpCliCommand
- SkillInstallCommand
- ローカルAPI http://localhost:18080 への接続前提
残っている確認:
- Codexでは codex mcp add のコマンドで接続できるか
- Claude Codeでは claude mcp add のコマンドで接続できるか
- MCP serverがstdoutにprotocol以外を出していないか
- Record pauseや除外設定の状態がActivityに反映されるかうまく動かないとき
まずContextbergアプリが起動しているか、ローカルサーバーが動いているか、MCPクライアント側にcontextbergサーバーが表示されているかを確認します。
Record pauseや除外設定が有効だとActivityが生成されない場合があります。Recordタブで記録が増えているかを確認するのが一番早いです。