位置づけ
ライセンスは MIT。npm パッケージは @upstash/context7-mcp（4.0.3、2026-08-21 公開）。
モデルが学習した時点より新しい API を扱わせるための経路にあたります。エージェントに書かせたコードが古い書き方になる、という失敗に直接効きます。この図書館が facts/ で公式ドキュメントを固定しているのと同じ問題に対する、別の解き方です。まだ手順には組み込んでいません。
実測でわかったこと（2026-08-23）
手元で動かして確かめました。判定は 使える。経緯は notes/claude-code/mcp.md にあります。
題材は「Astro 7 で Markdown に rehype プラグインを適用する設定を書く」。正解はこのリポジトリの astro.config.ts が実際に使っている形です。
| 資料なし | Context7 の資料あり | |
|---|---|---|
| 出力 | markdown.rehypePlugins（Astro 3〜5 系の書き方。v7 では動かない） | processor: unified({...})（正しい） |
| 補足 | 「v7 で変更がないかは未確認」と自己申告した | @astrojs/markdown-remark の別途インストールが必要な点まで指摘 |
| 所要時間 | 10.4 秒 | 7.9 秒 + 資料取得 4.1 秒 = 12.0 秒 |
動かないコードが動くコードになりました。 精度の差が主観なしで判定できた例です。
使う前に確認すること
- 問い合わせが Upstash のサーバーへ送られる。 顧客のコードや要件が混ざる場面では、何が送信されるかを確認してからでないと使えない
- 手動である。 指示に書き足さなければ、従来どおり古い情報で書かれる
- 文脈を消費する。 取得したドキュメントはトークンを食う（実測の題材では 3,703 文字）
- ツール名と引数はバージョンで変わっている。4.0.3 では
resolve-library-id（引数libraryName）とquery-docs（引数libraryId/query）。古い解説記事のとおりに呼ぶと引数エラーになる
確認できていないこと
- 使い勝手そのものを測っていない。 プロンプトに
use context7と書くだけ、という本来の使い方ではなく、サーバーを直接呼んで取得した資料をプロンプトへ貼る形で測った（MCP 登録は再起動が要るため） - 1 ライブラリ・1 題材・1 回。 ライブラリごとにドキュメントの網羅度は違うはずで、どこでも同じ差が出るとは限らない
- 取得したドキュメントが古い場合にどうなるか
出典
- リポジトリと npm レジストリ（front matter の
sources） - 実測の経緯: notes/claude-code/mcp.md
- 着想となった記事: Qiita「AIコーディングの精度を劇的に向上させる Context7 MCP Server 完全ガイド」（
_meta/trials/trt58ef.json）