Skip to main content
Glama
Amana03

Universal MCP Server

by Amana03

Universal MCP Server

OpenAIとClaude両対応のModel Context Protocolサーバー実装

特徴

  • マルチモード対応

    • STDIOモード: Claude Desktop統合

    • HTTPモード: OpenAI、ngrok、外部アクセス対応

  • ✅ OpenAI & Claude 完全対応

  • ✅ ファイルの読み込み・書き込み・削除・検索機能

  • ✅ MCP仕様に厳密に準拠(SDK v1.18.1)

  • ✅ SSE (Server-Sent Events) サポート

  • ✅ APIキー認証(オプション)

  • ✅ CORS対応

  • ✅ 包括的なロギング(Winston使用)

  • ✅ 非同期書き込み制御(ロック機構)

  • ✅ TypeScript完全型安全

  • ✅ モジュール化された設計

Related MCP server: MCP Complete Implementation Guide

プロジェクト構造

universal-mcp-server/
├── src/
│   ├── index.ts             # メインサーバー実装(STDIOモード)
│   ├── index-multimode.ts   # マルチモード対応版
│   ├── http-server.ts       # HTTP/SSEサーバー実装
│   ├── logger.ts            # ロギングモジュール
│   └── storage.ts           # ストレージモジュール
├── build/                   # ビルド出力
├── data/                    # データストレージ
├── logs/                    # ログファイル
├── .env.example             # 環境設定例
├── NGROK.md                 # ngrok設定ガイド
├── OPENAI.md                # OpenAI統合ガイド
├── package.json
├── tsconfig.json
└── README.md

インストール

npm install
npm run build

クイックスタート

詳細は QUICKSTART.md を参照してください。

Claude Desktop(STDIOモード)

npm start

OpenAI / Web統合(HTTPモード)

# 認証なし(開発用)
MCP_MODE=http npm run dev:http

# 認証あり(推奨)
export MCP_API_KEY=$(openssl rand -hex 32)
./start-http.sh

ngrokで外部公開

最も簡単な方法(オールインワン)

# MCPサーバー + ngrokを同時起動
./start-all.sh

個別起動

# ターミナル1: MCPサーバー
./start-http.sh

# ターミナル2: ngrok
./start-ngrok.sh

手動起動

ngrok http 3000

詳細: NGROK.md, OPENAI.md

使用方法

STDIOモード(Claude Desktop用)

# 開発モード
npm run dev

# 本番実行
npm start

HTTPモード(OpenAI、ngrok対応)

# 開発モード(認証なし)
MCP_MODE=http npm run dev:http

# 本番実行(認証なし)- 開発用のみ
MCP_MODE=http npm start:http

# 本番実行(認証あり)- 推奨
MCP_MODE=http MCP_HTTP_PORT=3000 MCP_API_KEY=your-secret-key npm start:http:auth

環境変数設定

# .envファイルを作成
cp .env.example .env

# .envファイルを編集
# MCP_MODE=http
# MCP_HTTP_PORT=3000
# MCP_HTTP_HOST=0.0.0.0
# MCP_API_KEY=your-secret-api-key

ngrokでの外部公開

# 別のターミナルでngrokを起動
ngrok http 3000

詳細は NGROK.md を参照してください。

OpenAIとの統合

詳細は OPENAI.md を参照してください。

デバッグ・インスペクター

npm run inspect

Claude Desktopでの設定

~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "universal-mcp": {
      "command": "node",
      "args": ["/path/to/universal-mcp-server/build/index.js"]
    }
  }
}

HTTPモードのエンドポイント

エンドポイント

メソッド

説明

認証

/health

GET

ヘルスチェック

不要

/info

GET

サーバー情報

必要*

/sse

GET

SSE接続(MCP通信)

必要*

/message

POST

メッセージ送信

必要*

*APIキーが設定されている場合のみ

認証ヘッダー

curl -H "Authorization: Bearer your-api-key" \
     http://localhost:3000/info

停止方法

# すべてのプロセスを停止
./stop-all.sh

# ngrokのみ停止
./stop-ngrok.sh

# または個別に停止
pkill -f "node build/index"
pkill -f "ngrok"

トラブルシューティング

プロセスが停止できない、ポートが専有されているなどの問題は TROUBLESHOOTING.md を参照してください。

よくある問題:

  • ngrokが停止できない → ./stop-ngrok.sh

  • ポート3000が使用中 → lsof -ti:3000 | xargs kill -9

  • "endpoint already online"エラー → 既存のngrokトンネルを停止

機能

Resources(読み込み)

  • file:///{key} - キーでファイルを読み込む

  • file:///list - すべてのファイル一覧を取得

Tools(書き込み・操作)

  • write_file - ファイルに内容を書き込む

  • delete_file - ファイルを削除

  • search_files - テキスト検索

ログ

すべての操作は詳細にログ記録されます:

  • logs/combined.log - すべてのログ

  • logs/error.log - エラーのみ

  • stderr - リアルタイム出力

各ログエントリには以下が含まれます:

  • タイムスタンプ

  • セッションID

  • リクエストID

  • 操作タイプ

  • コンテキスト情報

ライセンス

MIT

Available Tools

3 tools
delete_fileC

Delete a file

ParametersJSON Schema
NameRequiredDescriptionDefault
keyYesThe file key/name to delete

TDQS

C2.5/5.0
Behavior1/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 of behavioral disclosure. 'Delete a file' implies a destructive mutation, but it doesn't specify whether deletion is permanent or reversible, what permissions are required, if there are rate limits, or what happens on success/failure. For a destructive tool with zero annotation coverage, this is a critical gap in transparency.

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 'Delete a file' is extremely concise—three words that directly state the action. It's front-loaded with the core purpose and has zero wasted words, making it efficient and easy to parse. This is an example of optimal brevity for a simple tool.

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 tool's complexity (a destructive operation with no annotations and no output schema), the description is incomplete. It doesn't address behavioral aspects like safety, permissions, or outcomes, which are crucial for a deletion tool. The high schema coverage helps with parameters, but overall context is lacking for informed use.

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 input schema has 100% description coverage, with the single parameter 'key' documented as 'The file key/name to delete'. The description adds no additional meaning beyond this, as it doesn't elaborate on parameter usage, format, or examples. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.

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

Purpose3/5

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

The description 'Delete a file' states a clear verb ('Delete') and resource ('a file'), providing basic purpose. However, it lacks specificity about what type of file or system is involved, and doesn't distinguish from sibling tools like 'write_file' or 'search_files' beyond the obvious action difference. It's not tautological but remains vague in scope.

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. There are sibling tools like 'search_files' and 'write_file', but no indication of prerequisites, dependencies, or scenarios where deletion is appropriate versus other operations. Usage is implied by the action name alone, with no explicit context or exclusions.

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

search_filesC

Search for files containing specific text

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe text to search for

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 full burden for behavioral disclosure. The description only states what the tool does ('Search for files'), but doesn't disclose any behavioral traits like whether this is a read-only operation, what permissions are required, how results are returned (pagination, format), rate limits, or error conditions. For a search tool with zero annotation coverage, this is inadequate.

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, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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 lack of annotations and output schema, the description is incomplete. While the purpose is clear, it doesn't provide enough context about behavioral aspects (permissions, result format, limitations) that would help an agent use the tool effectively. For a search operation with no structured metadata, the description should do more to compensate.

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%, with the single parameter 'query' fully documented in the schema. The description adds no additional meaning about parameters beyond what the schema provides ('The text to search for'). According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

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 clearly states the action ('Search for files') and target resource ('files containing specific text'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling tools (delete_file, write_file), which are clearly different operations, so it doesn't reach the highest score for sibling differentiation.

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. While the purpose is clear, there's no mention of when-not-to-use scenarios or how this differs from other search operations that might exist in the broader context. The agent must infer usage from the tool name alone.

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

write_fileC

Write content to a file

ParametersJSON Schema
NameRequiredDescriptionDefault
keyYesThe file key/name
contentYesThe content to write

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic action. It lacks critical behavioral details: whether this overwrites existing files, requires permissions, has side effects, or handles errors. For a mutation tool, this is a significant gap in transparency.

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 with a single sentence ('Write content to a file') that directly states the core function without any fluff. It's front-loaded and wastes no words, making it efficient for quick understanding.

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 and no output schema, the description is incomplete. It doesn't explain what happens on success/failure, return values, or behavioral nuances like overwriting. Given the complexity and lack of structured data, more context is needed for effective use.

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 'key' and 'content' are fully documented in the schema. The description adds no additional meaning beyond implying 'content' is written to 'key', which the schema already covers. Baseline 3 is appropriate as 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?

The description 'Write content to a file' clearly states the action (write) and resource (file), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'delete_file' or 'search_files' beyond the obvious verb difference, missing explicit scope or resource distinctions.

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. It doesn't mention prerequisites (e.g., file existence), exclusions, or comparisons to siblings like 'delete_file' or 'search_files', leaving usage context entirely implicit.

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

TDQS

B3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: delete_file removes files, search_files finds files based on content, and write_file creates or modifies files. There is no overlap in functionality, making it easy for an agent to select the correct tool without confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (delete_file, search_files, write_file) using snake_case throughout. This predictability enhances readability and usability for agents.

Tool Count3/5

With only 3 tools, the server feels thin for a 'Universal MCP Server' name, suggesting it might lack broader functionality. However, for basic file operations, the count is borderline but manageable, as it covers core actions without being excessive.

Completeness2/5

The tool set is significantly incomplete for file operations, missing essential actions like read_file or list_files, which are critical for a comprehensive file management system. This gap will likely cause agent failures when trying to access or list file contents.

Maintenance

ActivityInactive
ResponsivenessSyncing

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

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/Amana03/universal-mcp-server'

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