File Finder MCP Server
MCP サーバー
このリポジトリには、2 つの MCP (モデル コンテキスト プロトコル) サーバーが含まれています。
ファイルファインダーMCP - ファイル検索用
Whisper STT MCP - 音声をテキストに変換する
ファイルファインダー MCP サーバー
これは、ファイル検索機能を提供するモデル コンテキスト プロトコル (MCP) サーバーです。名前に指定したテキストフラグメントを含むファイルを検索できます。
前提条件
Node.js (バージョン 14 以上)
npm (バージョン6以上)
Python 3.6 以上(HTTP サーバー用)
インストール
このリポジトリをクローンまたはダウンロードする
プロジェクトディレクトリに移動する
依存関係をインストールします:
npm installプロジェクトを組み立てる:
npm run build
サーバーの起動
このプロジェクトでは、MCP サーバーを起動するためのいくつかのオプションが提供されています。
オプション1: MCPサーバーの直接起動
Node.js を使用して MCP サーバーを直接実行できます。
npm startまたは
node build/index.jsこれによりサーバーが起動し、stdin/stdout で JSON-RPC リクエストをリッスンします。
オプション2: HTTPサーバーとMCPプロキシを起動する
このオプションでは、Python HTTP サーバーと、リクエストを HTTP サーバーに転送する MCP プロキシを使用します。
まず、HTTP サーバーを起動します。
npm run start:pythonまたは
python main.py次に、別のターミナルで MCP プロキシを実行します。
npm run start:httpまたは
node build/index-http.js
オプション3: VS Codeとの統合(Cline拡張機能)
サーバーを VS Code および Cline 拡張機能と統合するには:
MCP 設定ファイルを見つけます:
Windows:
%APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.jsonmacOS:
~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.jsonLinux:
~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
設定ファイルの
mcpServersオブジェクトに次の構成を追加します。
"file-finder-mcp": {
"command": "node",
"args": ["<ПОЛНЫЙ_ПУТЬ_К_ПРОЕКТУ>/build/index.js"],
"disabled": false,
"autoApprove": []
}HTTP プロキシを使用するには:
"file-finder-mcp-http": {
"command": "node",
"args": ["<ПОЛНЫЙ_ПУТЬ_К_ПРОЕКТУ>/build/index-http.js"],
"disabled": false,
"autoApprove": []
}<ПОЛНЫЙ_ПУТЬ_К_ПРОЕКТУ>プロジェクト ディレクトリへの実際のパスに置き換えます。
更新された設定を読み込むには、VS Code を再起動します。
利用可能なツール
MCP サーバーは次の 1 つのツールを提供します。
search_files: 指定されたフラグメントを名前に含むファイルを検索しますパラメータ:
fragment(文字列、必須): ファイル名で検索するテキストフラグメント
使用例
<use_mcp_tool>
<server_name>file-finder-mcp</server_name>
<tool_name>search_files</tool_name>
<arguments>
{
"fragment": ".py"
}
</arguments>
</use_mcp_tool>この例では、名前に「.py」が含まれるすべてのファイルを検索します。
HTTP サーバー (main.py)
プロジェクトのルート ディレクトリには、ファイルを検索するための HTTP サーバーを実装するmain.pyファイルがあります。このサーバーは、名前に指定されたフラグメントを含むファイルを検索するための REST API を提供します。
HTTPサーバーの起動
プロジェクトのルートディレクトリに移動する
Python を使用してサーバーを起動します。
python main.pyサーバーはhttp://localhost:8080で起動されます。
APIの使用
ファイルを検索するには、 qクエリ パラメータを指定して/searchに GET リクエストを送信します。
http://localhost:8080/search?q=.jsonこのクエリは、名前に「.json」が含まれるすべてのファイルに関する情報を含む JSON 配列を返します。各配列要素には次のフィールドが含まれます。
name: ファイル名path: ファイルへの絶対パスsize: ファイルサイズ(バイト単位)created: ファイル作成日時
回答例:
[
{
"name": "package.json",
"path": "/absolute/path/to/package.json",
"size": 1234,
"created": "Wed Feb 26 17:00:00 2025"
}
]Related MCP server: Everything Search MCP Server
ウィスパーSTT MCPサーバー
これは、faster-whisper ライブラリを使用して音声テキスト変換機能を提供するモデル コンテキスト プロトコル (MCP) サーバーです。自動言語検出により、音声データをテキストに転記できます。
前提条件
Node.js (バージョン 14 以上)
npm (バージョン6以上)
Python 3.6以上
faster-whisper (
pip install faster-whisperでインストール)
インストール
このリポジトリをクローンまたはダウンロードする
プロジェクトディレクトリに移動する
依存関係をインストールします:
npm install pip install faster-whisperプロジェクトを組み立てる:
npm run build
サーバーの起動
このプロジェクトでは、Whisper MCP サーバーを実行するためのいくつかのオプションが提供されています。
オプション1: MCPサーバーの直接起動
Node.js を使用して MCP サーバーを直接実行できます。
npm run start:whisperまたは
node build/whisper-index.jsこれによりサーバーが起動し、stdin/stdout で JSON-RPC リクエストをリッスンします。
オプション2: HTTPサーバーとMCPプロキシを起動する
このオプションでは、Python HTTP サーバーと、リクエストを HTTP サーバーに転送する MCP プロキシを使用します。
まず、HTTP サーバーを起動します。
npm run start:whisper:pythonまたは
python whisper_server.py次に、別のターミナルで MCP プロキシを実行します。
npm run start:whisper:httpまたは
node build/whisper-index-http.js
オプション3: VS Codeとの統合(Cline拡張機能)
サーバーを VS Code および Cline 拡張機能と統合するには:
MCP 設定ファイルを見つけます:
Windows:
%APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.jsonmacOS:
~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings\cline_mcp_settings.jsonLinux:
~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
設定ファイルの
mcpServersオブジェクトに次の構成を追加します。
"whisper-stt-mcp": {
"command": "node",
"args": ["<ПОЛНЫЙ_ПУТЬ_К_ПРОЕКТУ>/build/whisper-index.js"],
"disabled": false,
"autoApprove": []
}HTTP プロキシを使用するには:
"whisper-stt-mcp-http": {
"command": "node",
"args": ["<ПОЛНЫЙ_ПУТЬ_К_ПРОЕКТУ>/build/whisper-index-http.js"],
"disabled": false,
"autoApprove": []
}<ПОЛНЫЙ_ПУТЬ_К_ПРОЕКТУ>プロジェクト ディレクトリへの実際のパスに置き換えます。
更新された設定を読み込むには、VS Code を再起動します。
利用可能なツール
MCP サーバーは次の 1 つのツールを提供します。
transcribe_audio: faster-whisper を使用して音声データをテキストに書き起こすパラメータ:
audio_base64(文字列、必須): base64形式のオーディオデータlanguage(文字列、オプション): 言語コード (例: "en"、"ru")。指定しない場合は言語が自動的に検出されます。
使用例
<use_mcp_tool>
<server_name>whisper-stt-mcp</server_name>
<tool_name>transcribe_audio</tool_name>
<arguments>
{
"audio_base64": "BASE64_ENCODED_AUDIO_DATA",
"language": "ru"
}
</arguments>
</use_mcp_tool>この例では、音声がロシア語であると仮定して、音声データをテキストに変換します。
HTTP サーバー (whisper_server.py)
プロジェクトのルート ディレクトリには、音声をテキストに変換するための HTTP サーバーを実装するwhisper_server.pyファイルがあります。このサーバーは、音声データをテキストに転記するための REST API を提供します。
HTTPサーバーの起動
プロジェクトのルートディレクトリに移動する
Python を使用してサーバーを起動します。
python whisper_server.pyサーバーはhttp://localhost:8081で起動されます。
APIの使用
音声を書き起こすには、次の内容を含む JSON 本文を含む POST リクエストを/transcribeに送信します。
audio: 音声データを含むbase64エンコードされた文字列language(オプション): 言語コード(例:"en"、"ru")
リクエストの例:
{
"audio": "BASE64_ENCODED_AUDIO_DATA",
"language": "ru"
}回答には次の内容が含まれます。
text:完全な転写テキストsegments: タイムスタンプ付きのセグメントの配列language:特定の言語language_probability: 言語を検出する確率
回答例:
{
"text": "Это пример транскрибированного текста.",
"segments": [
{
"start": 0.0,
"end": 2.5,
"text": "Это пример"
},
{
"start": 2.5,
"end": 4.0,
"text": "транскрибированного текста."
}
],
"language": "ru",
"language_probability": 0.98
}トラブルシューティング
「サーバーへの接続が見つかりません」というエラーが表示された場合は、MCP 設定を更新した後、必ず VS Code を再起動してください。
サーバーが応答しない場合は、MCP 設定のパスが正しく、コンパイルされた JavaScript ファイルを指していることを確認します。
サーバーを使用する前に、
npm run buildを実行してサーバーが正しく構築されていることを確認してください。HTTP プロキシを使用するには、適切な HTTP サーバーが実行されていることを確認してください (file-finder の場合はポート 8080、whisper-stt の場合はポート 8081)。
faster-whisper で問題が発生した場合は、ライブラリが正しくインストールされており、GPU で動作するために必要な依存関係があることを確認してください (GPU を使用している場合)。
プロジェクト構造
以下は、主なプロジェクト ファイルとその目的の一覧です。
ルートディレクトリ
src/index.ts- TypeScript MCP ファイル検索サーバーのソースコード(直接実装)src/index-http.ts- HTTP ファイル検索サーバー用の TypeScript MCP プロキシのソースコードsrc/whisper-index.ts- TypeScript MCP 音声テキスト変換サーバーのソースコード(直接実装)src/whisper-index-http.ts- HTTP 音声テキスト変換サーバー用の TypeScript MCP プロキシのソースコードbuild/index.js- ファイル検索用のMCPサーバーのコンパイル済みJavaScriptコードbuild/index-http.js- ファイル検索用のMCPプロキシのコンパイル済みJavaScriptコードbuild/whisper-index.js- 音声をテキストに変換するMCPサーバーのコンパイル済みJavaScriptコードbuild/whisper-index-http.js- 音声をテキストに変換するMCPプロキシのコンパイル済みJavaScriptコードtsconfig.json- TypeScript 設定package.json- パッケージと依存関係の説明main.py- ファイル取得用の Python HTTP サーバーwhisper_server.py- 音声テキスト変換用の Python HTTP サーバーREADME.md- プロジェクトドキュメント(このファイル)
Available Tools
1 toolsearch_filesC
Search for files containing a specified fragment in their names
| Name | Required | Description | Default |
|---|---|---|---|
| fragment | Yes | Text fragment to search for in file names |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'search' implies a read-only operation, the description doesn't mention permissions, rate limits, result format, pagination, or error conditions. It lacks essential behavioral context for a search tool.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded with the core 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?
For a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the search returns, how results are formatted, whether there are limitations on search scope, or other behavioral aspects needed for effective use.
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 the schema already documents the single parameter. The description adds no additional parameter semantics beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.
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's purpose with a specific verb ('search') and resource ('files'), and specifies the search scope ('containing a specified fragment in their names'). However, there are no sibling tools mentioned, so differentiation from alternatives cannot be assessed.
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 no guidance on when to use this tool versus alternatives, prerequisites, or limitations. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- Added
search_files
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap between tools. The tool's purpose is singular and clearly defined, eliminating any ambiguity in tool selection.
The single tool follows a clear verb_noun pattern (search_files), and with no other tools to compare against, consistency is inherently perfect. There are no deviations or mixed conventions to evaluate.
A single tool is too few for a server named 'File Finder MCP Server', which suggests a broader scope like file searching, filtering, or management. This minimal set feels thin and underdeveloped for the implied domain.
The tool surface is severely incomplete for a file finder domain. It only supports searching by name fragments, lacking essential operations like filtering by type, size, date, content search, or listing files in directories, which are obvious gaps for the stated purpose.
Maintenance
Related MCP Connectors
Securely search and manage workspace context files for AI agents and teams.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Related MCP Servers
- AlicenseBqualityFmaintenanceProvides programmatic search functionality for Obsidian vaults through a REST API interface, allowing external applications to search through notes and retrieve absolute paths to matching documents.230MIT
- AlicenseNot gradedqualityDmaintenanceProvides fast file searching across Windows, macOS, and Linux using platform-native tools like Everything SDK, mdfind, and locate.MIT
- AlicenseNot gradedqualityDmaintenanceIntelligent file search engine with Frecency ranking, fuzzy matching, and Git awareness. Provides MCP server for AI agents to search files, content, and get file statistics via natural language.MIT
- AlicenseNot gradedqualityDmaintenanceExposes type-aware code navigation and fast file search to AI agents via language servers, enabling definitions, references, symbols, and file lookup without reading entire codebases.2,694 npmMIT