Skip to main content
Glama
deenesjakoruzh
AnIayana

high-performance-mcp-server

by AnIayana
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

高性能MCPサーバー

TypeScriptと最新のMCP v2 SDK（@modelcontextprotocol/server）で構築された、高性能・モジュール式のModel Context Protocol（MCP）サーバーです。デフォルトで安全なセキュリティプロファイル、プロファイル対応のサーバー指示、モジュール式MCPプロンプト、検索機能とホストパスプライバシーを備えた読み取り専用ワークスペースアクセス、Streamable HTTP、Stdioトランスポート、再利用可能なワーカースレッドプール、シングルフライト・スタンピード保護付きの本番用LRUキャッシュ、構造化テレメトリを特長としています。

プロジェクトステータス: パブリックプレビュー (v0.1.0)

[!NOTE] ステータス: 0.1.0 パブリックプレビュー。 このパッケージは、デフォルトで安全なMCPツール、読み取り専用ワークスペース検査、高性能ワーカー実行を提供します。Node.js >= 22.0.0 が必要です。

Related MCP server: VSCode LSP MCP Server

特長

  • 最新のMCP v2アーキテクチャ: @modelcontextprotocol/server をネイティブに採用し、標準のJSON Schema draft 2020-12バリデーションと完全な2026-07-28プロトコルサポートを備えています。

  • デュアルトランスポートサポート: 標準入出力（stdio）または最新のStreamable HTTP（node:http + /mcp）でシームレスに実行できます。

  • プロファイル対応サーバー指示: アクティブなプロファイルに基づいて、接続されたLLMに推奨ワークフロー、ツール実行順序、安全境界を案内する動的なサーバー指示を提供します。

  • モジュール式MCPプロンプト: 再利用可能なタスクプロンプト（explore_workspace、find_and_explain、review_file、trace_symbol）を workspace プロファイルと all プロファイルでのみ公開します。

  • デフォルトで安全なツールプロファイル: デフォルトの safe プロファイルはファイルシステムやハードウェア検査を一切公開しません。workspace、diagnostics、benchmark、admin、all への明示的なオプトインが必要です。

  • 読み取り専用ワークスペースとホストパスプライバシー: パストラバーサルとシンボリックリンクエスケープ防止、論理ルートマッピング（root-1、root-2）、1 MiBのハードリミット、バイナリファイル保護を備えたセキュアな許可リスト方式のディレクトリアクセスを提供し、ホストの絶対パスをクライアントやモデルに公開しません。

  • ワークスペース検索v1: 高速で制限付きのリテラルファイル・テキスト検索（search_files、search_text）で、無視ディレクトリのデフォルト設定、制限付き並行性、座標マッピング、クライアントキャンセルに対応しています。

  • ワーカースレッドプール: CPU負荷の高いタスクをNode.jsイベントループからオフロードし、自動ライフサイクルリカバリとゼロドリフト不変条件を実現します。

  • 本番用LRUキャッシュ: TTLサポート付きのメモリ制限キャッシュと、キャッシュスタンピードを排除するシングルフライトリクエスト合流を備えています。

  • 内部構造化ロギング: stderr のみを使用したStdioセーフなJSONロギング。

クイックスタート

MCPクライアント設定（Claude Desktop、Cursorなど）

MCP設定（例: claude_desktop_config.json）に追加します:

デフォルトのセーフプロファイル（Stdio）

{
  "mcpServers": {
    "high-performance-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "high-performance-mcp-server"
      ]
    }
  }
}

読み取り専用ワークスペースプロファイル

{
  "mcpServers": {
    "workspace-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "high-performance-mcp-server",
        "--profile=workspace",
        "--root=/path/to/project"
      ]
    }
  }
}

ローカル開発 / ソースからの実行

# Clone and build
git clone https://github.com/eminyilmz/high-performance-mcp-server.git
cd high-performance-mcp-server
npm install
npm run build

# Run default safe profile
node dist/index.js

# Run workspace profile with allowlisted root
node dist/index.js --profile=workspace --root=.

デフォルトで安全なプロファイル

ホストマシンを保護し、意図しないリソース消費やメタデータ漏洩を防ぐため、ツール、リソース、指示、プロンプトはセキュリティプロファイルに分類されます:

プロファイル

含まれるカテゴリ

公開されるツール

プロンプト

ユースケース

safe (デフォルト)

safe

echo、ping

(なし)

ホスト検査ゼロ、ファイルシステムアクセスゼロ、変更ゼロ。公開環境に安全。

workspace

safe、workspace

echo、ping、workspace_roots、list_directory、file_info、read_text_file、search_files、search_text

explore_workspace、find_and_explain、review_file、trace_symbol

許可リスト化された --root ディレクトリに厳密に制限された読み取り専用のファイル・ディレクトリ検査。

diagnostics

safe、diagnostics

echo、ping、cache_stats、server_metrics、system_stats、worker_pool_stats

(なし)

ヘルスとイベントループ遅延を監視するためのプロセス・システム可観測性。

benchmark

safe、benchmark

echo、ping、cached_prime_count、heavy_compute_main、heavy_compute_worker

(なし)

CPU負荷の高い素数計算ベンチマークとワーカープールテスト。

admin

safe、diagnostics、admin

echo、ping、cache_stats、server_metrics、system_stats、worker_pool_stats、reset_cache、reset_metrics

(なし)

管理用ランタイム状態変更（キャッシュパージ、メトリクスリセット）を伴う可観測性。

all

safe、workspace、diagnostics、benchmark、admin

登録済み全17ツール

全4ワークスペースプロンプト

完全なツール・プロンプトカタログ。

サーバー指示とプロンプト

プロファイル対応サーバー指示

MCPクライアントが接続すると、サーバーはMCPプロトコルを介して簡潔でプロファイルに合わせた指示を配信します:

  • safe: ファイルシステムとハードウェアの検査が利用できないことをモデルに指示します。

  • workspace: 推奨される調査手順（workspace_roots -> search_files / search_text -> file_info -> read_text_file）の概要を示し、読み取り専用の制約を強調し、ルート相対パスの使用を重視します。

  • diagnostics と benchmark: 観測メトリクスの解釈をガイドし、不要なCPU負荷の高い計算呼び出しを警告します。

  • admin: 変更操作はプロセスローカルのキャッシュとテレメトリ状態にのみ影響することを説明します。

モジュール式MCPプロンプト

workspace または all プロファイルで実行すると、サーバーは一般的なエンジニアリングタスクのための構造化ワークフローを提供するモジュール式プロンプトを公開します:

プロンプト

引数

目的

explore_workspace

rootId (必須)、goal (任意)

検索とファイル検査を使用して、許可リスト化されたワークスペースルートの構造的探索をモデルにガイドします。

find_and_explain

rootId (必須)、query (必須)

リテラルテキスト検索で関連するコードや設定を特定し、定義ファイルを読み取って説明を生成します。

review_file

rootId (必須)、path (必須)、focus (任意)

ワークスペース内の指定されたテキストファイルの構造化された読み取り専用レビューを策定します。

trace_symbol

rootId (必須)、symbol (必須)

ワークスペース全体でシンボルの宣言、参照、使用箇所を追跡します。

[!NOTE] プロンプト引数は制限付きタスクデータとして扱われ、再利用可能なMCPプロンプトテンプレートに挿入される前にエスケープされます。プロンプト自体は直接ファイルシステムI/Oを実行しません。実際のファイル読み取りと検索は、厳格なルート許可リスト制御の下で、標準のMCPツールとリソースを使用してモデルが実行します。

読み取り専用ワークスペースアクセス

ファイルシステムアクセスはデフォルトで無効です。読み取り専用ワークスペースアクセスを有効にするには、--profile=workspace（または --profile=all）と、少なくとも1つの許可リスト化された --root ディレクトリを明示的に指定します:

# POSIX / macOS / Linux
npx high-performance-mcp-server --profile=workspace --root=/home/user/my-project

# Windows
npx high-performance-mcp-server --profile=workspace --root="C:\Projects\app"

# Multiple roots
npx high-performance-mcp-server --profile=workspace --root=./packages/core --root=./packages/cli

セキュリティ保証と制約

  • ホストパスプライバシー: 設定された絶対ファイルシステムパスはサーバー内部に留まります。workspace_roots ツールと workspace://roots リソースは、ホストの絶対パスではなく論理ルート識別子（id: "root-1"、name: "my-project"）を返します:

    {
  "roots": [
    {
      "id": "root-1",
      "name": "my-project"
    }
  ]
}

  • 厳格な許可リスト: 明示的に渡された --root ディレクトリのみアクセス可能です。一意のルートは最大16個（重複排除前の生パスは最大64個）です。

  • 読み取り専用: サーバーコードベースにはファイルシステム変更関数（writeFile、unlink、rm、mkdir、rename など）は存在しません。

  • トラバーサルとシンボリックリンク保護: ターゲットパスは fs.realpath を使用して正規化され、ルート境界を決して越えないことが厳密に検証されます。

  • サニタイズされたエラー: エラーレスポンスは論理ルートID、ルート名、要求された相対パスのみを参照し、内部ディレクトリ構造が漏洩しないことを保証します。

  • ファイル読み取り制限: デフォルトのテキスト読み取り制限は256 KiB、ハード上限は1 MiB（MAX_TEXT_READ_BYTES）です。

  • バイナリファイル検出: NULバイト（\0）を含むファイルは、コンテキスト汚染を防ぐために read_text_file で拒否されます。

  • MCPリソース: workspace://roots（ルートの静的リスト）と workspace://file/{rootId}{?path}（動的テキストリーダー）を公開します。

ワークスペースの検索

workspace プロファイルは、制限付きの読み取り専用検索ツールを提供します:

  1. search_files:

    • リテラル部分文字列マッチングを使用してファイル名とディレクトリ名を検索します。

    • 種類（file、directory、all）、大文字小文字の区別、開始パスでフィルタリングします。

    • 一般的なビルド・ベンダーディレクトリ（.git、node_modules、.next、dist、build、target など）はデフォルトでスキップします。検索するには includeIgnored: true を渡します。

    • 再帰サイクルとエスケープを防ぐため、シンボリックリンク・ジャンクションディレクトリには決してトラバースしません。

  2. search_text:

    • 固定並行性（8ワーカー）で制限付きリテラルマッチングを使用してUTF-8テキストファイルを検索します。

    • 1ベースの行、列、トリミングされたプレビュースニペット（最大300文字）を返します。

    • ファイル拡張子フィルターをサポートします（例: extensions: [".ts", ".md"] または extensions: ["ts", "md"]）。

    • バイナリファイル（NULバイト）と1 MiB（MAX_SEARCH_FILE_BYTES）を超えるファイルを自動的にスキップします。

    • 制限: ハードデフォルト（maxResults: 100 [最大500]、maxFiles: 5000 [最大50000]、timeoutMs: 10000 [最大30000]）。

    • クライアントの AbortSignal による完全キャンセルに対応しています。

コマンドラインインターフェース（CLI）

Usage:
  high-performance-mcp-server [options]

Options:
  --transport=<stdio|http>   Transport protocol to run (default: stdio)
  --port=<number>            HTTP server port (default: 3000, only for http transport)
  --profile=<profile>        Security tool profile (default: safe)
  --root=<path>              Allowlisted read-only workspace root (repeatable, max 16)
  --list-tools               Display available tools for the active profile and exit
  --help, -h                 Show this help message and exit
  --version, -v              Show version and exit

例

# Start default safe server on stdio
high-performance-mcp-server

# List tools available under the workspace profile
high-performance-mcp-server --profile=workspace --list-tools

# Run Streamable HTTP transport on port 8080 with workspace profile
high-performance-mcp-server --transport=http --port=8080 --profile=workspace --root=./project

HTTPトランスポートの詳細

--transport=http で起動すると、サーバーはNode.js組み込みの node:http を使用してStreamable HTTPトランスポートを起動します:

  • エンドポイント: http://127.0.0.1:<port>/mcp

  • セキュリティ: サーバーは厳密に 127.0.0.1 にバインドし、DNSリバインディングとクロスサイトリクエストフォージェリを防ぐために Host ヘッダーと Origin ヘッダーを検証します。

  • 警告: 認証用のリバースプロキシやゲートウェイなしで、HTTPトランスポートを信頼できないネットワークに直接公開しないでください。

環境変数

変数

型

デフォルト

説明

MCP_PROFILE

string

safe

デフォルトのツールプロファイルの上書き値（safe、workspace、diagnostics、benchmark、admin、all）

PORT

number

3000

デフォルトのHTTPポートの上書き値（1〜65535の厳密な整数）

MCP_ROOTS_JSON

string

（なし）

ワークスペースルートのJSON配列（例：["/home/user/project", "/home/user/docs"]）

MCP_WORKER_COUNT

number

4

プール内で生成されるワーカースレッドの数（1〜16）

MCP_CACHE_MAX_ENTRIES

number

256

LRUキャッシュの最大エントリ数（1〜10000）

MCP_CACHE_TTL_MS

number

300000

LRUキャッシュエントリの有効期限（ミリ秒単位）（5分）

開発

# Install dependencies
npm install

# Run code generator and TypeScript typecheck
npm run typecheck

# Execute unit, security, search, and modern protocol integration test suites
npm test

# Build production bundle
npm run build

# Validate npm package payload without publishing
npm run pack:check

# Run package payload security & privacy scan
npm run security:package

# Run end-to-end tarball installation smoke test
npm run smoke:package

アーキテクチャ

MCP Clients (Claude Desktop, Cursor, Custom SDK Clients)
                       │
       ┌───────────────┴───────────────┐
       ▼                               ▼
  Stdio Transport             Streamable HTTP Transport
(process.stdin / stdout)         (127.0.0.1:3000/mcp)
       │                               │
       └───────────────┬───────────────┘
                       ▼
                McpServer Instance
      (Profile-Aware Server Instructions)
                       │
       ┌───────────────┴───────────────┐
       ▼                               ▼
  Tool & Prompt Profiles       Internal Telemetry
(safe, workspace, diag, ...)    (Metrics & Stderr Logger)
       │                               │
       ├──────► Read-Only Workspace, Search, Resources & Prompts (Allowlisted Roots, Host Privacy)
       │
       ├──────► In-Memory LRU Cache (Single-Flight Stampede Protection)
       │
       └──────► Reusable Worker Thread Pool (CPU Offloading)

セキュリティ

  • デフォルトのセキュリティプロファイル（safe）は、明示的なオプトインなしにはファイルシステムやハードウェアの検査が公開されないことを保証します。

  • 読み取り専用のワークスペースアクセスは、ホストのファイルシステムの絶対パスを明かすことなく、設定された--rootディレクトリへのファイルアクセスを厳密に分離します。

  • サーバーの指示とプロンプトは、文字エスケープにより、安全なツールの実行順序と明確なタスク境界を強化します。

  • StdioトランスポートはJSON-RPCメッセージ専用にstdoutを予約し、内部のデバッグログとテレメトリログはすべてstderrに送信されます。

  • HTTPトランスポートは、厳格なlocalhostオリジンとホストヘッダーの検証を強制します。

詳細については、SECURITY.mdを参照してください。

コントリビューションとリリース

コントリビューションとフィードバックを歓迎します！コードスタイル、ツール開発の規約、テスト要件、メンテナーによるリリースワークフローの詳細については、CONTRIBUTING.mdをお読みください。

ライセンス

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

Available Tools

2 tools
echoEcho ToolA

Echoes back the provided message

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesThe message to echo back

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It accurately states that the tool returns the provided message, which is the only meaningful behavioral trait. No side effects, auth, or rate limits are relevant for this simple operation.

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 a single, front-loaded sentence that contains zero filler. Every word earns its place, and the structure is ideal for such a minimal tool.

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

Completeness5/5

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

Given the tool's extreme simplicity—one parameter, no output schema, no annotations—the description fully covers the operation. There is nothing missing that an agent would need to select and invoke this tool correctly.

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%, and the 'message' parameter is already fully documented in the schema. The tool description adds no additional semantic value beyond the schema, meeting the baseline for high 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?

The description uses a specific verb 'Echoes' with a clear object 'the provided message', making the tool's function obvious. It distinguishes from sibling 'ping' by implication (echo vs. connectivity check), but does not explicitly differentiate.

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 use case is implied by the simple definition—'if you need to echo a message, use this tool'—but there is no explicit when-to-use guidance or mention of the sibling tool 'ping'. For such a trivial tool, the implication is adequate but not stated.

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

pingPingA

Checks whether the MCP server is responsive

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, and the description does not explicitly mention side effects or whether the operation is read-only. However, the nature of a ping implies a non-destructive check, so it is somewhat transparent.

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 a single, concise sentence that is easy to understand and directly conveys the purpose.

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?

The description covers the primary purpose but does not specify the return value or output format, which might be ambiguous without a schema. It could be improved by indicating the type of response expected.

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?

There are no parameters, so the schema covers all aspects. No additional parameter explanation is needed.

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's function as a server responsiveness check, distinguishing it from the sibling 'echo' tool which likely echoes input.

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 implies when to use it (for health checks), and the context of only one sibling ('echo') makes the usage scenario unambiguous, though it does not explicitly state alternatives.

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.9/5.0
Disambiguation5/5

The two tools have entirely distinct purposes: echo returns a message, while ping checks server responsiveness. There is no overlap or ambiguity in their functionality.

Naming Consistency5/5

Both tool names are single, lowercase verbs (echo, ping) that clearly describe their actions. The naming style is perfectly consistent and predictable.

Tool Count3/5

With only 2 tools, the server is at the lower boundary of what feels minimal. While each tool serves a purpose, the set is extremely thin for a server named 'high-performance', which typically implies broader functionality.

Completeness2/5

The tool surface is almost nonexistent for a general-purpose server. While echo and ping are fully realized for their narrow functions, there are no operations that would support meaningful workflows, leaving significant gaps in coverage for any real domain.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • ts-mcp-server

    AndyLiner13
    A
    license
    A
    quality
    D
    maintenance
    A lightweight MCP server that provides 40 tools for TypeScript/JavaScript refactoring and code intelligence, directly mapping to TypeScript's tsserver protocol commands for accurate structural changes and workspace analysis.
    40
    34
    3
    MIT

Latest Blog Posts

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/AnIayana/high-performance-mcp-server'

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