AI駆動のセマンティックコード検索をMCPツールとして提供します — WindsurfのリバースエンジニアリングされたSWE-grepプロトコルを利用。
MCP互換のクライアント（Claude Code、Claude Desktop、Cursorなど）は、自然言語クエリでコードベースを検索できます。すべてのツールはnpm経由でバンドルされています — システムレベルの依存関係は不要です（ripgrepは @vscode/ripgrep、treeは tree-node-cli を使用）。macOS、Windows、Linuxで動作します。
You: "where is the authentication logic?"
│
▼
┌─────────────────────────┐
│ Fast Context MCP │
│ (local MCP server) │
│ │
│ 1. Maps project → /codebase
│ 2. Sends query to Windsurf Devstral API
│ 3. AI generates rg/readfile/tree commands
│ 4. Executes commands locally (built-in rg)
│ 5. Returns results to AI
│ 6. Repeats for N rounds
│ 7. Returns file paths + line ranges
│ + suggested search keywords
└─────────────────────────┘
│
▼
Found 3 relevant files.
[1/3] /project/src/auth/handler.py (L10-60)
[2/3] /project/src/middleware/jwt.py (L1-40)
[3/3] /project/src/models/user.py (L20-80)
Suggested search keywords:
authenticate, jwt.*verify, session.*tokenRelated MCP server: code-rag
Node.js >= 18
Windsurfアカウント — 無料枠で利用可能（APIキーに必要）
ripgrepをインストールする必要はありません — @vscode/ripgrep 経由でバンドルされています。
# Latest stable release
npm install @sammysnake/fast-context-mcp
# Or beta/next release
npm install @sammysnake/fast-context-mcp@nextgit clone https://github.com/SammySnake-d/fast-context-mcp.git
cd fast-context-mcp
npm installサーバーはDevin CLI/DesktopまたはレガシーなWindsurfインストールからAPIキーを自動抽出します。セットアップ後に extract_windsurf_key MCPツールを使用するか、手動で WINDSURF_API_KEY を設定することもできます。
デスクトップの認証情報は、Devin、レガシーの Deviv、その後 Windsurf の順で検出されます。
プラットフォーム | パス |
macOS |
|
Windows |
|
Linux |
|
WSL/Linuxでは、サーバーは最初に ~/.local/share/devin/credentials.toml でDevin CLIの認証情報を確認します。WSL内でWindowsで抽出したキーが403を返す場合は、WSL内で devin login を実行して再試行してください。
~/.claude.json の mcpServers に追加します:
{
"fast-context": {
"command": "npx",
"args": ["-y", "--prefer-online", "@sammysnake/fast-context-mcp"],
"env": {
"WINDSURF_API_KEY": "sk-ws-01-xxxxx"
}
}
}ベータ/次期リリースの場合:
{
"fast-context": {
"command": "npx",
"args": ["-y", "--prefer-online", "@sammysnake/fast-context-mcp@next"],
"env": {
"WINDSURF_API_KEY": "sk-ws-01-xxxxx"
}
}
}claude_desktop_config.json の mcpServers に追加します:
{
"fast-context": {
"command": "npx",
"args": ["-y", "--prefer-online", "@sammysnake/fast-context-mcp"],
"env": {
"WINDSURF_API_KEY": "sk-ws-01-xxxxx"
}
}
}ベータ/次期リリースの場合:
{
"fast-context": {
"command": "npx",
"args": ["-y", "--prefer-online", "@sammysnake/fast-context-mcp@next"],
"env": {
"WINDSURF_API_KEY": "sk-ws-01-xxxxx"
}
}
}
WINDSURF_API_KEYが省略された場合、サーバーはローカルのWindsurfインストールから自動的に検出します。
変数 | デフォルト | 説明 |
| (自動検出) | Windsurf APIキー |
|
| クエリごとの検索ラウンド数（多いほど深く検索されますが、遅くなります） |
|
| ラウンドごとの最大並列コマンド数 |
|
| ストリーミングリクエストのConnect-Timeout-Ms |
|
|
|
|
| コマンド出力の最大行数（切り詰め） |
|
| 出力行の最大文字数（切り詰め） |
| (未設定) |
|
|
| 結果キャッシュのTTL。 |
|
| インメモリキャッシュの最大エントリ数 |
| (未設定) | 信頼された企業プロキシがTLS検証の無効化を必要とする場合にのみ |
|
| Windsurfモデル名 |
|
| Windsurfアプリバージョン（プロトコルメタデータ） |
|
| Windsurf言語サーバーバージョン（プロトコルメタデータ） |
モデルは WS_MODEL を設定することで変更できます（上記の環境変数を参照）。
デフォルト: MODEL_SWE_1_6_FAST — 最速の速度、最も豊富なgrepキーワード、最も細かい位置の粒度。
fast_context_search調整可能なパラメータを備えたAI駆動のセマンティックコード検索。
パラメータ | 型 | 必須 | デフォルト | 説明 |
| string | はい | — | 自然言語の検索クエリ |
| string | いいえ | cwd | プロジェクトルートへの絶対パス |
| integer | いいえ |
| リポジトリマップのディレクトリツリーの深さ（1〜6）。大きいほどコンテキストが増えますが、ペイロードも大きくなります。ツリーが250KBを超えると、自動的に浅い深さにフォールバックします。巨大なモノレポ（5000ファイル超）では1〜2、ほとんどのプロジェクトでは3、小規模プロジェクトでは4〜6を使用します。 |
| integer | いいえ |
| 検索ラウンド数（1〜5）。多いほど深く検索されますが、遅くなります。単純な検索では1〜2、ほとんどのクエリでは3、複雑な分析では4〜5を使用します。 |
| integer | いいえ |
| 返すファイルの最大数（1〜30）。小さいほど焦点が絞られ、大きいほど広く探索されます。 |
| string[] | いいえ |
| リポジトリマップと検索コンテキストから除外するディレクトリ/ファイルパターン。 |
戻り値:
関連ファイル と行範囲
提案された検索キーワード（AI検索で使用されたrgパターン）
診断メタデータ（使用された実際のtree_depth、ツリーサイズ、フォールバックが発生したかどうかを示す [config] 行）
出力例:
Found 3 relevant files.
[1/3] /project/src/auth/handler.py (L10-60, L120-180)
[2/3] /project/src/middleware/jwt.py (L1-40)
[3/3] /project/src/models/user.py (L20-80)
grep keywords: authenticate, jwt.*verify, session.*token
[config] tree_depth=3, tree_size=12.5KB, max_turns=3エラー出力にはステータス別のヒントが含まれます:
Error: Request failed: HTTP 403
[hint] 403 Forbidden: Authentication failed. The API key may be expired or revoked.
Try re-extracting with extract_windsurf_key, or set a fresh WINDSURF_API_KEY env var.
If you are running inside WSL, run `devin login` inside WSL so `~/.local/share/devin/credentials.toml` exists.Error: Request failed: HTTP 413
[diagnostic] tree_depth_used=3, tree_size=280.0KB (auto fell back from requested depth)
[hint] If the error is payload-related, try a lower tree_depth value.extract_windsurf_keyローカルインストールからWindsurf APIキーを抽出します。パラメータはありません。
MCPサーバー起動時に FC_HIDE_EXTRACT_WINDSURF_KEY_TOOL=1 を設定すると、このツールを tools/list から非表示にできます。これは fast_context_search の内部APIキー自動検出を無効にするものではありません。
fast-context-mcp/
├── package.json
├── src/
│ ├── server.mjs # MCP server entry point
│ ├── core.mjs # Auth, message building, streaming, search loop
│ ├── executor.mjs # Tool executor: rg, readfile, tree, ls, glob
│ ├── extract-key.mjs # Windsurf API Key extraction (SQLite)
│ ├── path-safety.mjs # Project-root confinement for model-selected paths
│ ├── response-repair.mjs # Malformed response repair and evidence salvage
│ ├── shared.mjs # Repository map, answer parser, prompt builder
│ ├── cache.mjs # In-memory search-result cache
│ └── protobuf.mjs # Protobuf encoder/decoder + Connect-RPC frames
├── test/ # Unit and MCP stdio integration tests
├── README.md
└── LICENSEプロジェクトディレクトリを仮想パス /codebase にマッピング
要求された深さ（デフォルトL=3）でディレクトリツリーを生成。ツリーが250KBを超える場合は、浅い深さに自動フォールバックします。
クエリとディレクトリツリーをConnect-RPC/Protobuf経由でWindsurfのDevstralモデルに送信
Devstralがツールコマンド（ripgrep、ファイル読み取り、tree、ls、glob）を生成
コマンドをローカルで並列実行（ラウンドごとに最大 FC_MAX_COMMANDS）
結果をDevstralに送り返して次のラウンドへ
max_turns ラウンド後、Devstralがファイルパスと行範囲を返す
検索中に使用されたすべてのrgパターンを提案キーワードとして収集
診断メタデータを追加して、呼び出し元のAIがパラメータを調整できるようにする
プロトコル: Connect-RPC over HTTP/1.1、Protobufエンコーディング、gzip圧縮
モデル: Devstral (MODEL_SWE_1_6_FAST、設定可能)
ローカルツール: rg（@vscode/ripgrep経由でバンドル）、readfile（Node.js fs）、tree（tree-node-cli）、ls（Node.js fs）、glob（Node.js fs）
認証: APIキー → JWT（セッションごとに自動取得）
ランタイム: Node.js >= 18 (ESM)
パッケージ | 用途 |
| MCPサーバーフレームワーク |
| バンドルされたripgrepバイナリ（クロスプラットフォーム） |
| クロスプラットフォームのディレクトリツリー（システムの |
| ネイティブビルドステップなしでDevin/WindsurfのローカルSQLite DBを読み取る |
| スキーマ検証。一部のnpmミラーが配信する不完全な |
MIT
Extract Windsurf API Key from local installation. Auto-detects OS (macOS/Windows/Linux) and reads the API key from Windsurf's local database. Set the result as WINDSURF_API_KEY env var.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses OS auto-detection, reading from the local database, and setting the result as an env var. It does not mention error cases or prerequisites, but it is transparent about its main side effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the core function and side effect. It lacks mention of failure cases or requirements, but is otherwise complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage (empty), so the baseline is 4. No additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Extract Windsurf API Key from local installation', a specific verb+resource with source. It distinguishes itself from the unrelated sibling fast_context_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to get the API key and set it as an env var), and the sibling tool is unrelated, so no exclusions are needed. It does not explicitly list alternatives, but usage is apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI-driven semantic code search using Windsurf's Devstral model. Searches a codebase with natural language and returns relevant file paths with line ranges, plus suggested grep keywords for follow-up searches. Parameter tuning guide:
tree_depth: Controls how much directory structure the remote AI sees before searching. If you get a payload/size error, REDUCE this value. If search results are too shallow (missing files in deep subdirectories), INCREASE this value.
max_turns: Controls how many search-execute-feedback rounds the remote AI gets. If results are incomplete or the AI didn't find enough files, INCREASE this value. If you want a quick rough answer, use 1. Response includes a [config] line showing actual parameters used — use this to decide adjustments on retry.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language search query (e.g. "where is auth handled", "database connection pool") | |
| project_path | No | Absolute path to project root. Empty = current working directory. | |
| tree_depth | No | Directory tree depth for the initial repo map sent to the remote AI. Default 3. Use 1-2 for huge monorepos (>5000 files) or if you get payload size errors. Use 4-6 for small projects (<200 files) where you want the AI to see deeper structure. Auto falls back to a lower depth if tree output exceeds 250KB. | |
| max_turns | No | Number of search rounds. Each round: remote AI generates search commands → local execution → results sent back. Default 3. Use 1 for quick simple lookups. Use 4-5 for complex queries requiring deep tracing across many files. More rounds = better results but slower and uses more API quota. | |
| max_results | No | Maximum number of files to return. Default 10. Use a smaller value (3-5) for focused queries. Use a larger value (15-30) for broad exploration queries. | |
| exclude_paths | No | Directory/file patterns to exclude from tree and search context. Useful for reducing payload size on large repos. Examples: ['node_modules', 'dist', '.git', 'build', 'coverage', '*.min.*'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully explains the search process: rounds of search-execute-feedback, auto fallback for tree depth if payload exceeds 250KB, and mentions API quota usage for more rounds. This provides comprehensive behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main overview and a parameter tuning guide. It is concise overall but the tuning guide could be slightly more compact. Still, it is clear and front-loaded with key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 100% schema coverage, no output schema, and only one sibling, the description covers purpose, behavior, tuning, and response content (including [config] line). It provides sufficient context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds valuable tuning context for tree_depth and max_turns beyond the schema, explaining payload/size errors and result completeness. For other parameters, the schema already suffices. Thus, a 4 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs AI-driven semantic code search, returns file paths with line ranges and grep keywords. It distinguishes itself from the only sibling, extract_windsurf_key, which extracts a key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a parameter tuning guide that explains when to adjust tree_depth and max_turns based on errors or shallow results. It also advises using the [config] line in responses for retry decisions. However, it does not explicitly state when not to use this tool, but given only one dissimilar sibling, this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.1fast_context_search4 fields changedInput schema / properties / exclude_pathsAdded value: +{
+ "default": [],
+ "description": "Directory/file patterns to exclude from tree and search context. Useful for reducing payload size on large repos. Examples: ['node_modules', 'dist', '.git', 'build', 'coverage', '*.min.*']",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / max_resultsAdded value: +{
+ "default": 10,
+ "description": "Maximum number of files to return. Default 10. Use a smaller value (3-5) for focused queries. Use a larger value (15-30) for broad exploration queries.",
+ "maximum": 30,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / max_turnsAdded value: +{
+ "default": 3,
+ "description": "Number of search rounds. Each round: remote AI generates search commands → local execution → results sent back. Default 3. Use 1 for quick simple lookups. Use 4-5 for complex queries requiring deep tracing across many files. More rounds = better results but slower and uses more API quota.",
+ "maximum": 5,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / tree_depthAdded value: +{
+ "default": 3,
+ "description": "Directory tree depth for the initial repo map sent to the remote AI. Default 3. Use 1-2 for huge monorepos (>5000 files) or if you get payload size errors. Use 4-6 for small projects (<200 files) where you want the AI to see deeper structure. Auto falls back to a lower depth if tree output exceeds 250KB.",
+ "maximum": 6,
+ "minimum": 1,
+ "type": "integer"
+}v1.0.0extract_windsurf_keyfast_context_searchScored across 2 tools
The two tools have completely distinct purposes: one extracts an API key from a local installation, the other performs semantic code search. No overlap or ambiguity exists.
Both tools use snake_case and follow a descriptive pattern (extract_* and fast_*). Although the verb style differs slightly (command vs. brand adjective), the naming is clear and consistent in format.
With only two tools, the server feels minimal. While the tools are focused, the count is on the low end of what is typically expected, making it borderline appropriate.
The server covers API key extraction and semantic search, but lacks related operations like API key management, file content retrieval, or result navigation. Significant gaps exist for a context-focused server.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
An MCP server that gives your AI access to the source code and docs of all public github repos
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
