de en es ja ko ru zh

semantic-code-intelligence

Name: semantic-code-intelligence
Author: saitarrun

by saitarrun

Overview Schema Source Related Servers Discussions Admin

Python

Local

Semantic Code Intelligence

ソフトウェアリポジトリ向けのローカルファーストなセマンティック検索と、引用付きコードウォークスルー。

Semantic Code Intelligence は、リポジトリをシンボル認識チャンクに解析し、そのチャンクを FAISS と BM25 でインデックス化して、両方の結果セットを融合し、クロスエンコーダーで最も有力な候補を再ランク付けします。結果には正確なファイルパスと行範囲が含まれます。すべてローカルで実行され、クラウド API キーは不要です。

提供される機能

ハイブリッドなセマンティックおよび語彙的コード検索
正確なシンボル、パス、コンテキスト用語のブースティング
検索の一致に基づく信頼性ラベル
Python AST 解析と一般的なプログラミング言語向けの構造解析
src/auth.py:L42-L67 などの正確な引用
ブラウザダッシュボードと REST API
CLI、MCP、LSP インターフェース
決定論的エビデンスのフォールバックを備えた、ローカルの Ollama を利用したコードウォークスルー
FAISS、BM25、SQLite インデックスの永続化
インクリメンタルなファイルシステム監視
シンボルグラフと依存関係グラフ
再現可能なインデックス作成と検索のベンチマーク

Related MCP server: codebase-analyser

必要条件

macOS または Linux
Python 3.10 以降
Git
Python の依存関係とローカルモデルキャッシュ用に約 2〜4 GB の空きディスク容量
任意: uv（環境管理を高速化）
任意: Ollama（コードウォークスルーの生成用）

最初のインデックス作成と再ランク付けの操作では、Hugging Face のモデル重みをダウンロードするためにインターネットアクセスが必要です。モデルがキャッシュされると、検索はオフラインで動作します。

クリーンなマシンでのクイックスタート

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

git clone https://github.com/saitarrun/Semantic-code-intelligence.git
cd semantic-code-intelligence

2. 環境を作成してアプリケーションをインストール

uv を使用する場合:

uv venv
source .venv/bin/activate
uv pip install -e .

標準の Python ツールを使用する場合:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e .

Windows は現時点ではテスト対象ではありませんが、同等のアクティベーションコマンドは .venv\Scripts\activate です。

3. 検索モデルをダウンロードしてインデックスを作成

モデルのダウンロードは、通常のアプリケーションリクエストが予期しないネットワークトラフィックを発生させないよう、デフォルトで意図的に無効化されています。最初のインデックス作成とクエリの際に、明示的にダウンロードを有効にしてください:

export CODE_INTEL_ALLOW_MODEL_DOWNLOADS=1

code-intel index .
code-intel query "Where is HybridRetrievalPipeline implemented?" --citations-only

unset CODE_INTEL_ALLOW_MODEL_DOWNLOADS

これにより以下が準備されます:

密な埋め込み用の sentence-transformers/all-MiniLM-L6-v2
再ランク付け用の cross-encoder/ms-marco-MiniLM-L-6-v2

リポジトリインデックスは .code_intel_index/ に保存されます。このディレクトリには FAISS インデックス、BM25 データ、SQLite メタデータが含まれており、コミットすべきではありません。

4. Web アプリケーションを起動

code-intel serve --host 127.0.0.1 --port 8000

http://127.0.0.1:8000 を開きます。

ダッシュボードには以下が含まれます:

セマンティック検索
コードウォークスルー
依存関係マップ
Diff および LSP ツール
リポジトリ選択と再インデックス作成のコントロール
ステージごとのレイテンシと検索信頼性のインジケーター

別のリポジトリをインデックス化

インデックスデータは、デフォルトでは対象リポジトリ内に保存されます:

code-intel index /absolute/path/to/project

そのリポジトリを検索:

code-intel query \
  "How are access tokens validated?" \
  --dir /absolute/path/to/project

ソースリポジトリを変更せずに残す場合は、別のインデックスディレクトリを使用します:

code-intel index /absolute/path/to/project \
  --index-dir /absolute/path/to/index-storage

code-intel query \
  "Where is the database connection pool created?" \
  --dir /absolute/path/to/project \
  --index-dir /absolute/path/to/index-storage

パーサーや埋め込みの動作を変更した後、クリーンな再構築を強制する:

code-intel index /absolute/path/to/project --force

セマンティック検索

ハイブリッドモードをお勧めします。自然言語の類似性と正確な識別子マッチングを組み合わせます:

code-intel query "How does the application serve the web UI?"

正確なシンボル検索:

code-intel query "Where is serve_ui implemented?"

より多くの結果を返す:

code-intel query "authentication middleware" --top-k 10

コードを表示せずに引用を表示:

code-intel query "database transaction rollback" --citations-only

診断用に個別の検索戦略を選択:

code-intel query "PaymentProcessor" --mode sparse
code-intel query "logic responsible for charging a customer" --mode dense
code-intel query "charge customer payment" --mode hybrid

精度よりも低レイテンシが重要な場合は、クロスエンコーダーの再ランク付けを無効にする:

code-intel query "configuration loader" --no-rerank

コードウォークスルー

決定論的エビデンスモード

このモードは Ollama を必要としません。取得したシンボル、スコープ、依存関係、ソースブロック、引用を、動作を推測せずに返します:

code-intel ask \
  "How does the indexing pipeline persist metadata?" \
  --provider extractive

Ollama によるローカル生成ウォークスルー

Ollama をインストールして起動し、デフォルトモデルをダウンロードします:

ollama pull qwen2.5-coder:7b

引用付きウォークスルーを実行:

code-intel ask "Explain the hybrid retrieval control flow"

別のローカルモデルまたは Ollama サーバーを使用:

export CODE_INTEL_OLLAMA_MODEL=deepseek-coder-v2:lite
export OLLAMA_BASE_URL=http://127.0.0.1:11434

Ollama に到達できない場合、アプリケーションは応答を extractive-fallback と明確にラベル付けし、決定論的なソースエビデンスを返します。

対話型 CLI

継続的な検索セッションを開始:

code-intel interactive --dir /absolute/path/to/project

インデックス統計を確認:

code-intel stats --dir /absolute/path/to/project

すべてのコマンドを表示:

code-intel --help
code-intel query --help

REST API

サーバーを起動:

code-intel serve --host 127.0.0.1 --port 8000

ヘルスチェック:

curl http://127.0.0.1:8000/api/health

リポジトリをインデックス化:

curl -X POST http://127.0.0.1:8000/api/index \
  -H 'Content-Type: application/json' \
  -d '{
    "target_dir": "/absolute/path/to/project",
    "force": false
  }'

ハイブリッド検索を実行:

curl -X POST http://127.0.0.1:8000/api/search \
  -H 'Content-Type: application/json' \
  -d '{
    "query": "Where is token validation implemented?",
    "repo_path": "/absolute/path/to/project",
    "top_k": 5,
    "mode": "hybrid",
    "rerank": true
  }'

ウォークスルーを生成:

curl -X POST http://127.0.0.1:8000/api/synthesize \
  -H 'Content-Type: application/json' \
  -d '{
    "query": "Explain token validation failure paths",
    "repo_path": "/absolute/path/to/project",
    "top_k": 8,
    "provider": "extractive"
  }'

主要なエンドポイント:

Method	Endpoint	Purpose
`GET`	`/api/health`	サービスとインデックスのステータス
`GET`	`/api/stats`	ファイル、行、チャンク、インデックスマニフェスト
`GET`	`/api/index/stream`	SSE インデックス作成の進行状況
`POST`	`/api/index`	同期リポジトリインデックス作成
`POST`	`/api/search`	密、スパース、またはハイブリッド検索
`POST`	`/api/synthesize`	引用付きコード回答
`POST`	`/api/synthesize/stream`	ストリーミング引用付き回答
`GET`	`/api/graph`	シンボルおよび依存関係グラフ
`POST`	`/api/watcher/toggle`	インクリメンタル監視の開始または停止
`GET`	`/api/lsp/inspect`	定義、参照、ホバーデータ
`POST`	`/api/patch/generate`	提案された unified diff を生成
`POST`	`/api/patch/apply`	選択したリポジトリに unified diff を適用

リモートアクセスが意図的に必要な場合を除き、127.0.0.1 にバインドしてください。パッチ適用とファイルを開くエンドポイントはローカルファイルシステム上で動作するため、信頼できないネットワークに公開すべきではありません。

MCP 統合

MCP サーバーを使用すると、VS Code、Cursor、Claude Code、その他の互換性のあるコーディングエージェントが、インデックス化されたコードベースを検索し、正確なソース範囲を取得できます。最初にプロジェクトをインストールしてインデックス化してください:

git clone https://github.com/saitarrun/Semantic-code-intelligence.git
cd Semantic-code-intelligence
python -m venv .venv
source .venv/bin/activate
pip install -e .
code-intel index --dir /absolute/path/to/your/project

以下の例では、which code-intel が出力する実行ファイルの絶対パスを使用してください。

VS Code

エージェントに検索させたいプロジェクトに .vscode/mcp.json を作成します:

{
  "servers": {
    "semanticCodeIntelligence": {
      "type": "stdio",
      "command": "/absolute/path/to/Semantic-code-intelligence/.venv/bin/code-intel",
      "args": ["mcp", "--dir", "${workspaceFolder}"],
      "cwd": "${workspaceFolder}"
    }
  }
}

コマンドパレットから MCP: List Servers を実行し、semanticCodeIntelligence を起動して、そのツールを承認します。古いツールリストがキャッシュされている場合は、MCP: Reset Cached Tools を実行してください。

Cursor

対象プロジェクトに .cursor/mcp.json を作成します:

{
  "mcpServers": {
    "semantic-code-intelligence": {
      "command": "/absolute/path/to/Semantic-code-intelligence/.venv/bin/code-intel",
      "args": ["mcp", "--dir", "${workspaceFolder}"]
    }
  }
}

Claude Code

検索したいプロジェクトからローカルの stdio サーバーを登録します:

claude mcp add --transport stdio --scope project semantic-code-intelligence -- \
  /absolute/path/to/Semantic-code-intelligence/.venv/bin/code-intel mcp --dir /absolute/path/to/your/project
claude mcp get semantic-code-intelligence

他の MCP 互換エージェントの場合は、同じ実行ファイルを、引数 mcp --dir /absolute/path/to/your/project を指定したローカル stdio サーバーとして構成します。サーバーは、stdio クライアントの要件に従って、stdout に JSON-RPC メッセージのみを書き込みます。

利用可能な MCP ツール:

code_intel_search: 正確な行と信頼性メタデータを備えたハイブリッド、密、またはスパース検索
code_intel_symbol_graph: リポジトリまたはシンボルの依存関係およびコールグラフデータ
code_intel_index: コーディングエージェントからインデックスを構築または更新
code_intel_read_file: 設定されたリポジトリ内の最大 400 行を安全に読み取る

検索リクエストの前に、対象プロジェクトをインデックス化する必要があります。デフォルトでは、そのインデックスは <project>/.code_intel_index に保存されます。別のインデックスディレクトリを使用する場合は、MCP コマンドに --index-dir /path/to/index を渡してください。モデルのダウンロードは引き続きオプトインです: 埋め込みまたは再ランク付けモデルがまだキャッシュされていない場合は、CODE_INTEL_ALLOW_MODEL_DOWNLOADS=1 を設定してください。

LSP とファイルシステムウォッチャー

stdio LSP ブリッジを起動:

code-intel lsp --dir /absolute/path/to/project

インクリメンタルウォッチャーを起動:

code-intel watch --dir /absolute/path/to/project

ウォッチャーはサポートされているソースファイルを監視し、変更後にインデックスの状態を更新します。いずれかのプロセスを停止するには Ctrl+C を使用します。

設定

環境変数:

Variable	Default	Description
`CODE_INTEL_ALLOW_MODEL_DOWNLOADS`	`0`	`1` に設定すると Hugging Face モデルのダウンロードを許可します
`CODE_INTEL_OLLAMA_MODEL`	`qwen2.5-coder:7b`	生成ウォークスルーに使用される Ollama モデル
`OLLAMA_BASE_URL`	`http://127.0.0.1:11434`	Ollama API のベース URL
`CODE_INTEL_CORS_ORIGINS`	Localhost origins	API が許可するブラウザオリジンのカンマ区切りリスト
`CODE_INTEL_PIPELINE_CACHE_SIZE`	`4`	API によってキャッシュされるリポジトリパイプラインの最大数

プログラムによる構成:

from pathlib import Path

from semantic_code_intel.config import CodeIntelConfig
from semantic_code_intel.indexing.engine import HybridIndexer
from semantic_code_intel.retrieval.pipeline import HybridRetrievalPipeline

project = Path("/absolute/path/to/project")
config = CodeIntelConfig(project_root=project)
config.retrieval.dense_top_k = 75
config.retrieval.sparse_top_k = 75
config.retrieval.final_top_k = 8

HybridIndexer(config).index_codebase(project)
response = HybridRetrievalPipeline(config).query(
    "Where is request authentication enforced?",
    top_k=8,
)

for result in response.results:
    print(result.citation, result.chunk.symbol_name, result.score)

print(response.reliability, response.reliability_reasons)

サポートされているファイル

デフォルトのスキャナーには以下が含まれます:

Python
JavaScript と TypeScript
Go
Rust
Java
C と C++
C#
Ruby
PHP
Swift
Kotlin と Scala
シェルスクリプト
SQL
HTML と CSS
JSON、YAML、TOML、Markdown

一般的な生成ディレクトリ、仮想環境、依存関係フォルダー、ロックファイル、バイナリ、圧縮済みアセット、.git、.code_intel_index、oss_evaluation はデフォルトで除外されます。拡張子と無視パターンをカスタマイズするには、semantic_code_intel/config.py の ParserConfig を参照してください。

アーキテクチャ

flowchart LR
    A[Repository] --> B[Scanner and ignore rules]
    B --> C[Python AST or polyglot parser]
    C --> D[Symbol-aware chunks]
    D --> E[Local embedding model]
    E --> F[(FAISS)]
    D --> G[Code-aware tokenizer]
    G --> H[(BM25)]
    D --> I[(SQLite metadata)]

    Q[Query] --> X[Intent expansion]
    X --> F
    X --> H
    F --> R[Reciprocal Rank Fusion]
    H --> R
    R --> J[Cross-encoder reranker]
    J --> K[Exact symbol and path boosts]
    K --> L[Diversity and reliability]
    L --> M[CLI, API, Web, MCP, LSP]

コアモジュール:

Package	Responsibility
`parser`	リポジトリのスキャンと構造的なコードチャンク化
`indexing`	埋め込み、FAISS、BM25、SQLite、監視
`retrieval`	クエリ展開、融合、再ランク付け、信頼性、引用
`generation`	根拠に基づくプロンプト、Ollama による合成、決定論的フォールバック
`api`	FastAPI エンドポイントとブラウザダッシュボード
`cli`	コマンドラインインターフェース
`graph`	シンボルおよび依存関係グラフ
`mcp`	Model Context Protocol サーバー
`lsp`	Language Server Protocol ブリッジ
`benchmark`	合成リポジトリの生成と検索評価

テスト

完全なテストスイートを実行:

uv run pytest -q

または、アクティベートされた環境で実行:

pytest -q

このスイートは、パーサー、FAISS、BM25、クエリ展開、完全一致ブースティング、融合、引用、API エンドポイント、ローカル合成動作、MCP、LSP、パッチ適用、監視、ベンチマーク生成をカバーしています。

ベンチマーキング

再現可能な合成ベンチマークを実行:

code-intel benchmark \
  --workspace ./benchmark_workspace \
  --loc 40000 \
  --queries 30

ランナーは以下を含む benchmark_report.json を書き出します:

データセットとインデックスのサイズ
インデックス作成スループット
密、スパース、再ランク付け、エンドツーエンドのレイテンシパーセンタイル
ヒット率と平均逆順位（Mean Reciprocal Rank）
実行されたクエリのレコード
Python、プラットフォーム、ハードウェア、パッケージ、モデルのメタデータ

ベンチマーク結果は、ハードウェア、モデルキャッシュの状態、リポジトリの構成、クエリセットによって異なります。過去の数値は保証ではなく測定結果として扱ってください。

トラブルシューティング

モデルがローカルにない場合

ダウンロードを有効にして、失敗した操作をもう一度実行します:

CODE_INTEL_ALLOW_MODEL_DOWNLOADS=1 code-intel index /absolute/path/to/project --force
CODE_INTEL_ALLOW_MODEL_DOWNLOADS=1 code-intel query "warm up reranker" --dir /absolute/path/to/project

インデックスが見つからない場合

クエリに使用する --dir と --index-dir の値は、インデックス作成に使用した値と一致している必要があります。

code-intel stats --dir /absolute/path/to/project

ウォークスルーが Ollama を利用できないと表示する場合

ローカルサーバーとインストール済みモデルを確認します:

ollama list
curl http://127.0.0.1:11434/api/tags

常に決定論的エビデンスモードを使用できます:

code-intel ask "your question" --provider extractive

検索結果が弱い場合

既知の場合は、正確なクラス、関数、メソッド、エンドポイント、または構成名を使用してください。
通常の使用ではハイブリッドモードを推奨します。
回答が複数のファイルにまたがる場合は、--top-k を増やしてください。
パーサーまたは埋め込み構成を変更した後は、--force で再インデックスしてください。
信頼性ラベルを確認してください。信頼性が低い場合は、取得シグナルが強く一致していないことを意味します。

サーバーポートがすでに使用中です

別のポートを選択してください：

code-intel serve --host 127.0.0.1 --port 8010

プロジェクトの状態

このプロジェクトは活発に開発中です。生成されたパッチを適用する前にレビューし、通常の使用ではAPIをlocalhostにバインドしたままにし、ベンチマークの主張はご自身のターゲットリポジトリで検証してください。

ライセンス

オープンソースライセンスはまだ追加されていません。リポジトリへの公開アクセスは、それ自体ではコードのコピー、変更、再配布の許可を与えるものではありません。

Available Tools

4 tools

code_intel_indexC

Build or refresh the semantic and lexical indexes for a local repository.

ParametersJSON Schema

Name	Required	Description
`force`	No
`index_dir`	No	Optional index storage directory.
`repo_path`	No	Repository root; defaults to the server --dir.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so the description carries the full behavioral burden. It doesn't disclose cost/duration (indexing can be slow), whether it blocks, whether it overwrites existing indexes, or what happens on failure. 'Refresh' hints at mutation but no depth.

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 clear sentence with verb and scope front-loaded, zero waste.

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?

For a mutation tool with no annotations, no output schema, and an undocumented 'force' parameter, the description is too thin. It leaves the agent guessing about cost, prerequisites, and the effect of force.

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 coverage is 67%, with index_dir and repo_path already documented in the schema. The 'force' parameter (schema has no description) is undocumented anywhere, and the description doesn't compensate. Baseline 3 given partial coverage.

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

Purpose4/5

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

States a specific verb ('Build or refresh') and resource ('semantic and lexical indexes for a local repository'). It's distinct from siblings like code_intel_search, though it doesn't explicitly name them.

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 run this versus using existing indexes, nor prerequisites like whether search requires prior indexing. Purely descriptive, no when-to-use direction.

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

code_intel_read_fileB

Read a bounded line range from a source file inside the configured repository.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Repository-relative or absolute file path.
`end_line`	No	Inclusive; at most 400 lines are returned.
`repo_path`	No	Repository root; defaults to the server --dir.
`start_line`	No

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: reads are bounded to a line range and restricted to the configured repository. However, it never states that the operation is read-only/side-effect free, nor how it behaves on a missing file, an out-of-repo absolute path, or a range exceeding the cap.

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?

A single front-loaded sentence with no filler; the core action and its two constraints are stated immediately.

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

Completeness3/5

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

For a four-parameter read tool with no annotations and no output schema, the description is adequate but thin: it omits read-only confirmation, error/edge-case behavior, and any hint of the return shape (raw lines vs numbered lines). An agent can call it, but cannot fully predict its behavior.

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 75%, so the schema already documents path, end_line, and repo_path; only start_line's default relies on the schema's default keyword. The description's 'bounded line range' and 'inside the configured repository' echoes rather than extends the end_line cap and repo_path semantics, so baseline 3 is appropriate.

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

Purpose4/5

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

The description names a specific verb and resource ('Read a bounded line range from a source file') and scopes it to the configured repository, which is enough for an agent to distinguish it from code_intel_search, code_intel_symbol_graph, and code_intel_index. It stops short of explicitly naming which sibling to use when, but the purpose itself is unambiguous.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as code_intel_search for locating content versus this tool for reading it. An agent must infer the read-content use case purely from the verb.

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

code_intel_searchB

Search indexed code with hybrid semantic and lexical retrieval, exact citations, match reasons, and reliability scoring.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No		hybrid
`query`	Yes	Question, behavior, or symbol to find.
`top_k`	No
`rerank`	No
`index_dir`	No	Optional index storage directory.
`repo_path`	No	Repository root; defaults to the server --dir.

TDQS

B3/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose some behavioral traits: hybrid semantic/lexical retrieval, exact citations, match reasons, and reliability scoring. However it omits key operational facts such as whether the index must already exist, which repo/index is targeted by default, and whether results are bounded or truncated.

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?

A single front-loaded sentence with no filler; every clause adds information. It is efficient, though the terse packing of output traits without any usage context borders on under-specification.

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

Completeness3/5

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

For a 6-parameter tool with no annotations, no output schema, and half the parameters undocumented, the description is only partially complete. It hints at the return content (citations, match reasons, reliability) but leaves prerequisites and most parameter behavior unaddressed.

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 only 50%, and the description adds no parameter meaning at all – it does not explain mode options (hybrid/dense/sparse), rerank, top_k limits, index_dir, or repo_path defaults. An agent must infer the effect of switching from hybrid to dense/sparse with no help.

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

Purpose4/5

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

States a specific verb and resource ("Search indexed code") and names the retrieval techniques (hybrid semantic + lexical) plus output traits, so the agent knows this is a code search tool. It does not name or differentiate itself from siblings like code_intel_symbol_graph or code_intel_read_file, so it stops short of a 5.

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?

There is no guidance on when to choose this over code_intel_symbol_graph (symbol relations) or code_intel_read_file (direct reads), nor any preconditions such as needing the repository indexed first. Usage is only weakly implied by the verb "Search".

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

code_intel_symbol_graphC

Return repository dependency/call-graph data, optionally centered on a symbol.

ParametersJSON Schema

Name	Required	Description
`symbol`	No	Optional function, class, or symbol name.
`index_dir`	No	Optional index storage directory.
`repo_path`	No	Repository root; defaults to the server --dir.

TDQS

C2.9/5.0

Behavior2/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 does state that symbol centering is optional and that graph data is returned, but says nothing about output format, graph depth/limits, whether an index must exist first (relevant given index_dir), or cost/size of the result.

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?

A single tight sentence with no waste, front-loading the resource (dependency/call-graph data) before the optional scoping. Very brief, which is efficient but leaves little room for behavioral detail.

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

Completeness3/5

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

For a read tool with no annotations and no output schema, the description is minimally adequate. It should mention whether an index is required beforehand and what the returned graph looks like, since an agent has no other source for that.

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 100%, so parameters are already documented. The description only adds that symbol centering is optional, which is already reflected in the schema's 'Optional' prefix; baseline 3 applies 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.

Purpose4/5

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

States a specific verb (Return) and resources (dependency/call-graph data) with a scoping qualifier (optionally centered on a symbol). Clear enough to distinguish from siblings like code_intel_search or code_intel_read_file, though it doesn't explicitly name alternatives.

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 code_intel_search (symbol lookup) or code_intel_index (index building). The optional symbol scoping is implied but no conditions or prerequisites are given.

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.

4 tool updatesv0.1.0Sep 11, 2026
- First observedcode_intel_index
- First observedcode_intel_read_file
- First observedcode_intel_search
- First observedcode_intel_symbol_graph

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-09-11 14:40 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: indexing, hybrid search, dependency/call-graph retrieval, and bounded file reading. Although search and read_file both return code, their boundaries are clear from descriptions (retrieval vs direct file access).

Naming Consistency4/5

All tools share the consistent code_intel_ prefix, which provides a predictable namespace. However, suffixes mix verb forms (search, index) and noun forms (symbol_graph), so the pattern is mostly but not perfectly consistent.

Tool Count5/5

Four tools is well-scoped for a code intelligence server, covering the essential operations of indexing, searching, graph exploration, and reading without redundancy or bloat.

Completeness4/5

The core lifecycle (index → search → explore graph → read file) is covered, but missing operations such as listing indexed repositories, retrieving symbol definitions, or index management could create minor dead ends for some agent workflows.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ref-tools-mcp AOAuth
tools.ref
Token-efficient search for coding agents over public and private documentation.
Documentation Access Search Coding Agents
221,180
GraphifyOAuth
io.github.Graphify-Labs
Search indexed code, trace dependencies, assess change impact, and recall repository memory.
Code Analysis 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
ContextStream MCP ServerOAuth
io.github.contextstream
Project memory, semantic code search, and grounded agent context.
Knowledge & Memory Code Analysis RAG Systems
144

Related MCP Servers

Qurio MCP Server
RAG Systems Search
irahardianto
A
license
Not graded
quality
D
maintenance
Enables AI coding assistants to search and retrieve information from a locally ingested knowledge base using hybrid search, grounded in user-curated documentation.
Updated 8 months ago (2026-02-15 22:06 UTC)
16
MIT
codebase-analyser
akshith120
F
license
Not graded
quality
D
maintenance
Enables AI agents and IDEs to ingest and search code repositories using hybrid retrieval (dense + sparse) with exact line-level citations for precise code analysis.
Updated 3 months ago (2026-07-20 14:32 UTC)
1
-
shelfmark
RAG Systems Knowledge & Memory Search
LucasSantana-Dev
A
license
A
quality
A
maintenance
Enables coding agents to query local notes, decisions, docs, and code with hybrid retrieval (BM25 + embeddings + reranking) and get path:line citations. It provides tools like rag_query for full-corpus search and search_knowledge for project-scoped knowledge recall.
Updated 8 days ago (2026-10-06 23:56 UTC)
2
1
MIT
LexiconLocal
Knowledge & Memory RAG Systems Search
alexeymohr
A
license
A
quality
B
maintenance
Enables coding agents to search a local, offline archive of past sessions and repository Markdown docs using hybrid lexical and semantic retrieval, and read matching records to ground new work in prior knowledge without external calls.
Updated a month ago (2026-09-11 16:18 UTC)
2
MIT

Semantic Code Intelligence

提供される機能

必要条件

クリーンなマシンでのクイックスタート

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

2. 環境を作成してアプリケーションをインストール

3. 検索モデルをダウンロードしてインデックスを作成

4. Web アプリケーションを起動

別のリポジトリをインデックス化

セマンティック検索

ランキングの仕組み

コードウォークスルー

決定論的エビデンスモード

Ollama によるローカル生成ウォークスルー

対話型 CLI

REST API

MCP 統合

VS Code

Cursor

Claude Code

LSP とファイルシステムウォッチャー

設定

サポートされているファイル

アーキテクチャ

テスト

ベンチマーキング

トラブルシューティング

モデルがローカルにない場合

インデックスが見つからない場合

ウォークスルーが Ollama を利用できないと表示する場合

検索結果が弱い場合

サーバーポートがすでに使用中です

プロジェクトの状態

ライセンス

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers