How do I use mcp-jp-fts?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-jp-fts search for 'データベース設計' in /home/user/docs with limit 5" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-jp-fts

by syaryn

Overview Schema Related Servers Score Discussions

Python

Local

日本語全文検索 MCP サーバー

English

FastMCP、SQLite FTS5、SudachiPy を使用した日本語全文検索用の Model Context Protocol (MCP) サーバーです。

特徴

日本語対応の全文検索: SudachiPy（モード A）を使用して、日本語テキストを適切にトークン化し、高精度な検索を実現
ローカルファイルのインデックス作成: ディレクトリを再帰的にスキャンしてテキストファイルをインデックス化
正確な行番号: トークンマップ戦略を使用し、トークン化された日本語テキストでも正確な行番号を特定可能
拡張子フィルタリング: 検索時に特定のファイル拡張子（例: .py, .md）のみを対象に指定可能
.gitignore 対応: .gitignore ファイルを尊重し、不要なファイルをインデックスから除外
自動クリーンアップ機能: ディレクトリの再インデックス時に、削除されたファイルのエントリを自動的に削除してインデックスをクリーンに保つ
FastMCP 統合: index_directory と search_documents を MCP ツールとして公開

Related MCP server: code-memory-rs

grep との比較における優位性

LLM が grep を使ってファイル検索を行う場合と比較して、この全文検索サーバーには以下の優位性があります：

1. 日本語の形態素解析による高精度検索

grep の場合:

文字列の単純な部分一致で検索
「東京都」を検索すると「東京都庁」「東京都民」などは見つかるが、文脈や単語の境界を理解しない
複合語や活用形の検索が困難（例：「走る」で検索しても「走った」「走っている」は見つからない）

本サーバーの場合:

SudachiPy による形態素解析で単語単位で正しく分割
日本語の言語的な構造を理解した検索が可能
正確な行番号特定: トークン化により単純な文字列検索ではズレが生じる場合でも、トークンマップを用いて正確な行番号を算出
トークン化により、より精度の高い検索結果を提供

2. インデックス化による高速検索

grep の場合:

検索のたびに全ファイルをスキャン
大量のファイルがある場合、毎回時間がかかる
LLM のコンテキストウィンドウやトークン数の制約により、複数回の grep 実行が必要になることがある

本サーバーの場合:

事前にインデックスを作成するため、検索が高速
SQLite FTS5 による最適化された全文検索
一度のクエリで関連する全ての結果を取得可能

3. 関連性スコアリングとスニペット表示

grep の場合:

マッチした行をそのまま表示
どの結果がより関連性が高いかの判断が困難
コンテキストの把握に追加の cat や head コマンドが必要

本サーバーの場合:

FTS5 の rank 機能により、関連性の高い順に結果を表示
マッチ箇所を含むスニペット（前後の文脈付き）を自動生成
検索結果の品質が向上し、LLM がより適切な判断が可能

4. 検索パターンの柔軟性

grep の場合:

正規表現の知識が必要
複雑な検索条件は正規表現が複雑になり、エラーが発生しやすい
日本語の特性（ひらがな、カタカナ、漢字の混在）を考慮した検索が困難

本サーバーの場合:

自然言語クエリで検索可能
トークン化により、単語の区切りを自動認識
FTS5 の演算子（AND、OR、NEAR など）を活用した柔軟な検索

使用例の比較

grep を使った検索（LLM が実行する場合）:

# 「データベース」という単語を含むファイルを探す
$ grep -r "データベース" /path/to/docs/
# → 大量の結果が返り、LLM が処理しきれない可能性
# → 関連性の低い結果も含まれる
# → 複数回の実行で絞り込みが必要

本サーバーを使った検索:

{
  "query": "データベース 設計",
  "limit": 5
}

→ 形態素解析により「データベース」と「設計」の両方を含む関連性の高い結果を、スニペット付きで返却

必要条件

Python 3.10 以上 3.14 未満
- 注意: Python 3.14 は現在サポートされていません（依存ライブラリ sudachipy のバイナリ互換性のため）。
uv (パッケージマネージャー)
mise (オプション、開発ツール管理用)

インストールと実行

`uvx` を使用する場合 (推奨)

このサーバーは GitHub リポジトリから直接実行できます：

uvx --from git+https://github.com/syaryn/mcp-jp-fts mcp-jp-fts

`claude_desktop_config.json` (Claude Desktop / Serena など)

MCP クライアントの設定ファイルに以下を追加してください：

{
  "mcpServers": {
    "mcp-jp-fts": {
      "command": "uvx",
      "args": [
        "--python",
        "<3.14",
        "--from",
        "git+https://github.com/syaryn/mcp-jp-fts",
        "mcp-jp-fts"
      ]
    }
  }
}

ローカル開発の場合

1. リポジトリのクローン

git clone https://github.com/syaryn/mcp-jp-fts.git
cd mcp-jp-fts

2. 依存関係のインストール

uv sync

使い方

サーバーの起動

開発モード（ホットリロード付き）

uv run fastmcp dev src/mcp_jp_fts/server.py
# または
mise run dev

本番モード（ローカルインストール済みの場合）

uv run mcp-jp-fts
# または
mise run start

MCP ツール

`index_directory`

指定されたパス内のすべてのテキストファイルをインデックス化します。

入力例:

{
  "root_path": "/path/to/docs"
}

出力例:

Indexed 42 files, Skipped 0 unchanged, Deleted 5 stale in /path/to/docs.

注意: 差分更新を行います。変更されたファイルのみ再インデックスし、削除されたファイルはインデックスから削除します。

`search_documents`

SudachiPy のトークン化を使用してインデックス化されたドキュメントを検索します。

入力例:

{
  "query": "猫",
  "limit": 5,
  "extensions": [".py", ".md"]
}

出力例:

File: /path/to/wagahai.txt:1
Snippet: 吾輩は<b>猫</b>である...

File: /path/to/other.txt:15
Snippet: この<b>猫</b>は...

`delete_index`

指定されたパス（およびそのサブディレクトリ）配下のインデックスを削除します。

入力例:

{
  "root_path": "/path/to/docs/subdir"
}

`list_indexed_files`

インデックスされているファイルの一覧を返します。

入力例:

{
  "limit": 10,
  "offset": 0
}

`update_file`

単一のファイルのインデックスを更新します（存在すれば再インデックス、削除されていればインデックスから削除）。

入力例:

{
  "file_path": "/path/to/docs/new_doc.txt"
}

`watch_directory`

ディレクトリの変更を監視し、インデックスをリアルタイムで自動更新します。

入力例:

{
  "root_path": "/path/to/docs"
}

開発

開発環境のセットアップ

このプロジェクトは mise を使用して開発ツールを管理しています。

# mise のインストール（未インストールの場合）
curl https://mise.run | sh

# ツールのインストール
mise install

# Git フックのインストール
mise exec -- lefthook install

よく使うコマンド

mise タスク

mise run dev          # 開発サーバーを起動（ホットリロード付き）
mise run start        # 本番サーバーを起動
mise run test         # テストを実行（pytest）
mise run test-all     # すべての Python バージョンでテストを実行（tox）
mise run lint         # リンターを実行（ruff）
mise run format       # コードをフォーマット（ruff）
mise run type         # 型チェックを実行（ty）
mise run check        # lint、type、test を一括実行
mise run scan         # 脆弱性スキャンを実行（osv-scanner）
mise run scan-license # ライセンスコンプライアンスチェックを実行

手動コマンド

# テストの実行
uv run pytest tests/

# 複数バージョンでのテスト
uv run tox

# リント
uv run ruff check .

# フォーマット
uv run ruff format .

# 型チェック
uv run ty check .

Git フック

lefthook を使用して自動チェックを実行します：

pre-commit: ruff check（リント）、ruff format（フォーマット）、ty check（型チェック）を実行
pre-push: pytest（テスト）と osv-scanner（脆弱性スキャン）を実行

手動でフックを実行：

lefthook run pre-commit
lefthook run pre-push

テスト

プロジェクトには以下のテストが含まれています：

トークン化テスト: 日本語テキストの正しい分割を確認
インデックス作成テスト: ファイルのウォーク、読み取り、トークン化、SQLite への挿入を検証
アトミック更新テスト: ディレクトリの再インデックス時に存在しないファイルの削除を確認
検索テスト: クエリが正しいドキュメントを返し、日本語のトークン化を処理することを確認

# すべてのテストを実行
mise run test

# 複数の Python バージョンでテスト（3.10, 3.11, 3.12, 3.13）
mise run test-all

コード品質

このプロジェクトは以下のツールを使用してコード品質を維持しています：

ruff: リントとフォーマット
ty: 型チェック
pytest: テスティングフレームワーク
tox: 複数バージョンでのテスト自動化
osv-scanner: 脆弱性とライセンスのスキャン
lefthook: Git フック管理

プロジェクト構成

mcp-jp-fts/
├── src/
│   └── mcp_jp_fts/
│       └── server.py      # FastMCP サーバーのメイン実装
├── tests/
│   ├── test_server.py     # サーバー機能のテスト
│   └── resources/         # テスト用リソース（サンプルテキストファイル）
├── pyproject.toml         # プロジェクトメタデータと依存関係
├── tox.ini                # Tox 設定
├── mise.toml              # Mise ツールとタスク設定
├── lefthook.yml           # Git フック設定
├── osv-scanner.toml       # OSV Scanner 設定
└── uv.lock                # ロックファイル

技術スタック

FastMCP: MCP サーバーフレームワーク
SQLite FTS5: 全文検索エンジン
SudachiPy: 日本語形態素解析ライブラリ
uv: パッケージマネージャー
mise: 開発ツール管理

ライセンス

このプロジェクトは MIT ライセンスの下で公開されています。

貢献

プルリクエストを歓迎します！大きな変更の場合は、まず issue を開いて変更内容について議論してください。

トラブルシューティング

Python バージョンの問題

このプロジェクトは Python 3.10 以上 3.14 未満をサポートしています。SudachiPy の wheel が利用可能なバージョンを使用してください（Python 3.14 は現在未対応です）。

# 現在の Python バージョンを確認
python --version

# uv で特定のバージョンを使用
uv python install 3.13
uv sync

SudachiPy の辞書エラー

初回実行時に SudachiPy が自動的に辞書をダウンロードします。ネットワークエラーが発生した場合は、手動でインストールできます：

uv run python -c "import sudachipy; sudachipy.Dictionary()"

Available Tools

7 tools

delete_indexB

Delete all indexed documents under the specified root path.

ParametersJSON Schema

Name	Required	Description	Default
`root_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits but only states it deletes documents. No mention of irreversibility, side effects, or required permissions for this destructive action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence efficiently communicates the core action without extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description lacks completeness for a destructive tool: no usage guidance, behavioral transparency, or parameter semantics beyond a basic hint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Single parameter 'root_path' is partially clarified by 'under the specified root path', but no format, validity conditions, or default behavior is given. Schema coverage is 0%, so description adds minimal value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'delete' and resource 'indexed documents under the specified root path', distinguishing it from sibling tools like 'index_directory' or 'list_indexed_files'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., removing specific files via 'update_file'?), nor any context on prerequisites or consequences.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_index_statsA

Get statistics about the current index and watched directories. Returns a JSON string containing:

total_files: Number of indexed files
total_size_bytes: Size of the SQLite database file
last_scanned: Timestamp of the most recent indexing operation
watched_directories: List of directories currently being watched

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It discloses that the tool returns a JSON string and lists four specific fields (total_files, total_size_bytes, last_scanned, watched_directories), providing good behavioral transparency for a read-only stat tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two short sentences with no wasted words. The first sentence states the core purpose, and the second provides a structured list of return fields. It is highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (no parameters, few return fields) and an output schema exists. The description covers the main purpose and return fields adequately, though it could mention potential error states or empty index scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters and schema coverage is 100%. The description adds value by explaining the tool's purpose and detailing the return values, which goes beyond the empty input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'statistics about the current index and watched directories'. It distinguishes from siblings like delete_index and index_directory by being a purely informational tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives. It only implies usage for retrieving index stats, but no guidance on exclusions or conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

index_directoryA

Recursively indexes all text files in the given root_path.

WARNING: This will remove all existing index entries that start with this root_path before re-indexing.

ParametersJSON Schema

Name	Required	Description	Default
`root_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses the destructive behavior (removing existing index entries). It does not cover other behavioral aspects like file permissions or performance impact, but the key side effect is mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: one for purpose and one for warning. Both are essential and concise, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema, so not describing output is acceptable. The description covers the operation and key side effect, but could mention file types or index format for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, root_path, has no description in the schema (0% coverage). The description adds 'given root_path' but no further details like format or existence requirements, partially compensating but not fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the purpose: recursively indexing all text files in a root_path. This distinguishes it from sibling tools like delete_index or search_documents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a warning about removing existing index entries before re-indexing, which guides usage context. It does not explicitly compare to alternatives but implies careful use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_indexed_filesA

List paths of all indexed files with pagination.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided. The description implies read-only behavior and pagination, but lacks details on rate limits, authentication, or output format. It is minimally adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise sentence that front-loads the purpose. Could be slightly expanded, but no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description is fairly complete for a simple list-with-pagination tool. Missing scope of 'indexed files' but still adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description mentions 'pagination' which hints at limit/offset usage, but does not explain what they represent (e.g., max results, starting point). Partial compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (list paths) and the target (all indexed files) with pagination. It distinguishes itself from sibling tools like search_documents, delete_index, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives (e.g., when to use search_documents instead). No mention of prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_documentsA

Search for documents matching the Japanese query string. Optionally filter by a root path and/or file extensions.

Args: query: Japanese search query limit: Max results to return path_filter: Only return results under this path extensions: List of file extensions to include (e.g., [".py", ".md"])

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No
`path_filter`	No
`extensions`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It implies a read-only search operation but does not explicitly state safety, idempotency, or side effects. Basic disclosure but lacks thoroughness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a clear one-line summary followed by structured parameter details. Every sentence adds value, with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters (1 required), an output schema, and sibling tools, the description covers the core functionality and filters. However, it could elaborate on search behavior (e.g., tokenization) and error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description includes an Args section that explains each parameter's meaning beyond the schema (e.g., 'Japanese search query', 'filter by root path'). This fully compensates for the 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches for documents matching a Japanese query string, specifying the resource and scope. It distinguishes from sibling tools like delete_index or index_directory, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (searching documents) but does not explicitly state when not to use it or provide alternative tools. No guidance on prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_fileA

Update the index for a single file. If the file exists, it is re-indexed. If the file does not exist, it is removed from the index.

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description fully covers behavioral traits: it explains the effect for both cases (file exists or not). This is sufficient for a simple tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences with no wasted words. The first sentence declares the purpose, the second provides the core behavioral detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no nested objects) and the presence of an output schema, the description covers the essential behavior. It does not discuss prerequisites or errors, but that is acceptable for this context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not add any meaning to the file_path parameter beyond its name. The parameter's format or constraints are not mentioned.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool updates the index for a single file, with specific conditions. It distinguishes from siblings like index_directory (multiple files) and delete_index (different operation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about what the tool does but no explicit guidance on when to use it instead of alternatives like index_directory or delete_index. The scope is well-defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

watch_directoryC

Start watching a directory for changes and automatically update the index.

ParametersJSON Schema

Name	Required	Description	Default
`root_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of disclosure. It fails to mention whether the watching is blocking or non-blocking, how to stop it, what events trigger updates, or error handling behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short but lacks necessary detail, indicating under-specification rather than conciseness. Every sentence should add value, but here it is insufficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a file watcher tool and the presence of an output schema (not shown), the description does not explain return values, lifecycle, or error conditions, leaving significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description does not explain the root_path parameter beyond the schema. There is no added meaning about format, permissions, or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool watches a directory for changes and updates the index, distinguishing it from sibling tools like index_directory (one-time indexing) and update_file (single file update).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, such as index_directory for one-time indexing or search_documents for querying. There is no mention of scenarios or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a distinct purpose: delete, stats, index directory, list files, search, update single file, watch directory. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, e.g., delete_index, get_index_stats, search_documents.

Tool Count5/5

7 tools cover the core operations for a file indexing server without being excessive or insufficient.

Completeness5/5

The tool set includes full lifecycle management: initial indexing, incremental updates, watching, listing, searching, stats, and bulk deletion. No obvious gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Orcha
io.github.westonhancock
Securely search and manage workspace context files for AI agents and teams.
Search File Systems Knowledge & Memory
1
Maguyva
ai.maguyva
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Code Analysis Coding Agents
23
wgong-sqlite-mcp-server
ai.smithery
Explore, query, and inspect SQLite databases with ease. List tables, preview results, and view det…
Databases Developer Tools
21
Devdocs Io B
io.github.pipeworx-io
DevDocs.io keyless docs index + entry search + content (Angular, MDN, Rust, etc.).
Documentation Access Search Developer Tools
383

Related MCP Servers

wiki-mcp-hub
Search Documentation Access
atototo
F
license
Not graded
quality
C
maintenance
Enables lexical search over local Markdown wiki folders using SQLite FTS5, with MCP tools for querying and managing wiki indices.
Updated a month ago (2026-07-25 11:51 UTC)
code-memory-rs
Code Analysis Search
juandisay
F
license
Not graded
quality
D
maintenance
Enables local semantic code search across repositories using natural language, with AST-aware chunking and hybrid vector/FTS5 retrieval.
Updated 5 months ago (2026-04-11 05:28 UTC)
claude-history-mcp
Search Knowledge & Memory
fifeek0
F
license
Not graded
quality
D
maintenance
Enables full-text search and browsing of Claude.ai conversation history by ingesting exported conversations into a local SQLite database with FTS5 indexes.
Updated 6 months ago (2026-03-18 07:51 UTC)
1
anydocs
Search Documentation Access RAG Systems
kiyeonjeon21
A
license
A
quality
A
maintenance
Provides fast, token-efficient search over coding agent documentation (e.g., Claude Code, Cursor) using local SQLite FTS5 indexing, with tools for searching snippets, reading pages, and grepping markdown.
Updated 19 days ago (2026-08-15 11:27 UTC)
5
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/syaryn/mcp-jp-fts'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

日本語全文検索 MCP サーバー

特徴

grep との比較における優位性

1. 日本語の形態素解析による高精度検索

2. インデックス化による高速検索

3. 関連性スコアリングとスニペット表示

4. 検索パターンの柔軟性

使用例の比較

必要条件

インストールと実行

uvx を使用する場合 (推奨)

claude_desktop_config.json (Claude Desktop / Serena など)

ローカル開発の場合

1. リポジトリのクローン

2. 依存関係のインストール

使い方

サーバーの起動

開発モード（ホットリロード付き）

本番モード（ローカルインストール済みの場合）

MCP ツール

index_directory

search_documents

delete_index

list_indexed_files

update_file

watch_directory

開発

開発環境のセットアップ

よく使うコマンド

mise タスク

手動コマンド

Git フック

テスト

コード品質

プロジェクト構成

技術スタック

ライセンス

貢献

トラブルシューティング

Python バージョンの問題

SudachiPy の辞書エラー

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`uvx` を使用する場合 (推奨)

`claude_desktop_config.json` (Claude Desktop / Serena など)

`index_directory`

`search_documents`

`delete_index`

`list_indexed_files`

`update_file`

`watch_directory`