Universal MCP Server
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Universal MCP Serverread the project notes from file:///meeting_minutes.txt"
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.
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 startOpenAI / Web統合(HTTPモード)
# 認証なし(開発用)
MCP_MODE=http npm run dev:http
# 認証あり(推奨)
export MCP_API_KEY=$(openssl rand -hex 32)
./start-http.shngrokで外部公開
最も簡単な方法(オールインワン)
# MCPサーバー + ngrokを同時起動
./start-all.sh個別起動
# ターミナル1: MCPサーバー
./start-http.sh
# ターミナル2: ngrok
./start-ngrok.sh手動起動
ngrok http 3000使用方法
STDIOモード(Claude Desktop用)
# 開発モード
npm run dev
# 本番実行
npm startHTTPモード(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-keyngrokでの外部公開
# 別のターミナルでngrokを起動
ngrok http 3000詳細は NGROK.md を参照してください。
OpenAIとの統合
詳細は OPENAI.md を参照してください。
デバッグ・インスペクター
npm run inspectClaude Desktopでの設定
~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"universal-mcp": {
"command": "node",
"args": ["/path/to/universal-mcp-server/build/index.js"]
}
}
}HTTPモードのエンドポイント
エンドポイント | メソッド | 説明 | 認証 |
| GET | ヘルスチェック | 不要 |
| GET | サーバー情報 | 必要* |
| GET | SSE接続(MCP通信) | 必要* |
| 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 toolsdelete_fileC
Delete a file
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The file key/name to delete |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The text to search for |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The file key/name | |
| content | Yes | The content to write |
TDQS
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceIntegration project for Model Context Protocol (MCP) servers with Claude Desktop App, enabling filesystem operations, development support, and file management through natural language.
- FlicenseBqualityDmaintenanceProvides a complete end-to-end MCP server implementation with file system tools, web scraping capabilities, and system information access. Includes ready-to-use configuration files and integration examples for Claude Desktop, ChatGPT, and other AI models.6
- AlicenseAqualityDmaintenanceMCP server that gives Claude Desktop and other desktop MCP clients filesystem powers—read, write, edit, and manage files like AI coding assistants.17869MIT
- AlicenseNot gradedqualityBmaintenanceA production-ready MCP server enabling Claude and other LLMs to perform intelligent file operations with minimal token usage.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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