redis-docs-mcp

Redis Docs MCP

redis-docs サーバーは、redis.io のドキュメントを MCP 経由で search、fetch、ask として公開します。各ツールには説明が付いており、どのような場合に呼び出すかについては正確です。まず search を使い、必要な情報を fetch し、複数の領域にまたがる質問には ask を使ってください。このスキルでは、各ツールの説明が誤っている点や説明していない点を取り上げます。

適用する場面

• これらのツールで何かを調べようとしている場合。
• 結果がツールの説明で期待したものと異なる場合。
• search の結果が空だった場合、または ask がレート制限を受けたか、回答を拒否した場合。

トピックを扱っている Redis の関連スキルがあれば、まずそちらを参照してください。関連スキルには、生のドキュメントページにはない、厳選されたガイダンスが含まれています。これらのツールは、詳細の確認や情報の補完に使ってください。

1. ID が指すのはページではなくセクションです

ツールの説明では、search は「ページ」を返し、fetch は「Redis のドキュメントページを 1 つ」返すとされています。インデックスはセクション単位で、ID には次の 4 つの形式があります。

形式	例	fetch が返すもの
ページのみ	commands/expire	ページ全体 — EXPIRE の場合、例や付録を含めて約 8.5 KB
名前付きアンカー	develop/using-commands/keyspace#sec:key-expiration	そのセクション
順序付きウィンドウ	develop/ai/search-and-query/advanced-concepts/expiration#sec:w0	そのウィンドウ、約 1～2 KB
アンカー + ウィンドウ	develop/clients/jedis/connect#sec:configure-a-connection-pool-w0	そのセクションのそのウィンドウ

ここから、次のことが分かります。

• 1 つの検索結果セット内で URL が重複していても、重複項目ではありません。 複数の検索結果で同じページ URL が共有されていても、異なる ID が付いている場合があります。これらは同じページ内の別々のセクションです。URL ではなくスニペットで見分けてください。
• #sec:wN はインデックスのウィンドウです。 関連度順に返されるため、w0、w1、w2 の順とは限りません。スニペットからページを再構成しようとせず、必要なセクションを fetch してください。
• ID を自分で作らないでください。 有効な ID は search の結果、または ask の結果の sources[].id から取得できます。commands/<name> では推測した ID がたまたま使えることもありますが、セクションを含むものでは使えません。
• スニペットは本文の先頭部分を切り詰めたもので、要約ではありません。 興味のある箇所の途中でスニペットが途切れている場合、その ID を fetch すれば続きが必ず含まれています。別の語句で再検索する必要はありません。
• ページの url を引用し、本文ではセクション名を示してください。 #sec:w1 はインデックス上のアドレスであり、ウェブ上のアンカーではありません。名前付きアンカー（#sec:<name> または #sec:<name>-wN）を含む ID は使用可能なフラグメントを持つ URL を返しますが、#sec:wN のみの ID は返しません。

返されたテキスト内のリンクはソースファイルを指しています — [`DEL`](/content/commands/del.md) — これらはウェブ URL でも fetch の ID でもありません。引用したり、ID に変換したりせず、代わりに該当する用語を search してください。

2. metadata.version が示すのは「追加されたバージョン」であり、「現在のバージョン」ではありません

fetch は topic、version、section を含む metadata を返します。commands/* ページでは、その version はコマンドが導入されたリリースです。commands/setex は 2.0.0、commands/hexpire は 7.4.0 を報告します。これは「いつ追加されたか」を調べるのには役立ちますが、それ以外の用途には使えません。commands/expire は 1.0.0 を報告しますが、本文には 2.1.3 での動作変更と、Redis 8 と Redis Search の相互作用が記載されています。commands/* 以外では、このフィールドはリリースを示すものではない場合がよくあります。たとえば、Redis Search のページでは、製品チャネルである stack が報告されます。

したがって、metadata.version を基に「これは Redis N で変更されましたか？」と回答しないでください。本文には「Redis 8 より前では…」「Redis 7.4 以降」のように明記されています。本文を読み、その内容を引用してください。

3. コーパスの対象範囲

インデックスの対象は redis.io のみですが、その範囲は想像以上に広いものです。言語ごとのクライアントの使用ガイドがインデックス化され、返されます（develop/clients/redis-py/connect#sec:…、develop/clients/jedis/connect#sec:…）。また、integrate/… のページ、operate/… 配下にある Redis Software と Redis Cloud の運用ドキュメント、Kubernetes オペレーターの生成された CRD リファレンスも対象です。そのため、クライアントライブラリや Enterprise に関する質問も、まず検索してください。

詳しい情報がスニペットに含まれないこともよくあります。redis-py の max_connections を検索すると、スニペットにはその名前が一切出てこない develop/clients/redis-py/async#sec:connection-pools が返されますが、取得したセクションには記載されています。ライブラリの完全なシグネチャについては、そのライブラリ独自の API リファレンスまたはソースを正としてください。

インデックスの対象外なのは、GitHub の issue とディスカッション、パッケージマネージャーのページ（PyPI、npm、Maven）、サードパーティの投稿です。

したがって、不足があると結論づける前に、関連する検索結果を fetch してください。それでも見つからない場合は、「取得した検索結果には見つかりませんでした」と報告し、「redis.io にはない」や「存在しない」とは決して言わないでください。

4. ask は見た目以上にコストがかかります

• IP ごとの 1 分あたりの利用上限は低く、同じ NAT の背後にいる全員で共有されます。そのため、オフィスや CI ランナーでは、全員で利用上限に達することがあります。レート制限エラーが発生した場合は、すぐに再試行せず、時間をおいてから再試行し、一度に質問する内容を一つに絞ってください。
• 回答を拒否された場合、言い換えて再試行しないでください。「ドキュメントにはこの内容が記載されていません」は、根拠に基づく結果であり、解析の失敗ではありません。代わりに search と fetch を使ってください。
• 合成された回答の元となる一次ソースを確認したい場合は、ask → sources[].id → fetch の順に使ってください。

すべてのツールに渡したクエリテキストは Redis に送信されます。また、ask の場合はゲートウェイの背後にあるモデルプロバイダーにも送信されます。そのため、独自コードを貼り付けるのではなく、Redis のコマンドや動作について一般的な質問をすることをおすすめします。