Tool Server
A unified MCP platform that lets clients interact with infrastructure providers like Contabo and Hetzner through a single, extensible control layer.
Installation
npx mcp-tool-serverAsk AI about Tool Server
Powered by Claude · Grounded in docs
I know everything about Tool Server. Ask me about installation, configuration, usage, or troubleshooting.
0/500
Reviews
Documentation
This README: • clearly explains what MCP is • explains your design decisions • justifies mock providers professionally • shows effort, architecture, and extensibility • aligns with what the company expected • sounds confident but not defensive
⸻
🧠 MCP Tool Server – Management Control Panel
A provider-agnostic Management Control Panel (MCP) built to demonstrate how MCP clients can seamlessly interact with infrastructure services such as Contabo and Hetzner through a unified backend interface.
This project focuses on architecture, extensibility, and real-world MCP design principles, rather than shallow one-off implementations.
⸻
📌 Overview
Modern infrastructure platforms expose powerful APIs, but each provider follows its own conventions, authentication models, and workflows. The goal of MCP is to abstract these differences and provide a standardized control layer that clients (CLI tools, dashboards, AI agents, automation systems) can interact with consistently.
This project implements: • A Go-based MCP backend • A tool registry system • Provider adapters for Contabo and Hetzner • A frontend dashboard to visualize and execute MCP tools
⸻
🎯 Objectives • Design a clean MCP server architecture • Expose infrastructure capabilities as discoverable tools • Keep providers decoupled from MCP logic • Demonstrate real-world extensibility • Provide a working dashboard for interaction and visualization
🏗️ Architecture Frontend Dashboard ↓ MCP API Server (Go) ↓ Tool Registry ↓ Provider Adapters (Contabo / Hetzner)
Key Design Principles • Provider-agnostic core • Tool-driven execution • Loose coupling • Easy extensibility • Client-friendly APIs
⸻
🔧 MCP Tools
Each provider exposes a set of tools that represent real infrastructure operations.
Examples: • create_server • list_servers • start_server • stop_server • reboot_server • delete_server • get_metrics • create_snapshot • restore_snapshot
Tools are: • self-describing • discoverable • executable via a single MCP endpoint
⸻
🧩 Why Mock Providers?
Real-world Contabo and Hetzner APIs require: • Paid accounts • Billing details • Production credentials
To keep the project accessible, reproducible, and safe, provider integrations are mocked, while strictly preserving: • Real API shapes • Tool behavior • Execution flows • Architectural boundaries
This ensures the MCP design can be directly extended to real APIs with minimal changes.
⸻
⚙️ Backend (Go)
Features • Clean HTTP API • Provider registry • Tool registry • Dynamic tool discovery • Tool execution engine
Run Backend go run main.go
Backend runs at: http://localhost:8080
Available Endpoints Endpoint Description /providers List supported providers /tools?provider=name List tools for a provider /execute?provider=name&tool=tool_name Execute a tool
🎨 Frontend Dashboard
The frontend is a lightweight static dashboard designed to: • Visualize MCP capabilities • Interact with backend APIs • Demonstrate real client usage
Features • Animated hero section • MCP architecture explanation • Tool discovery UI • Execution output viewer • Subtle notification system • Responsive layout (mobile → desktop)
Run Frontend cd frontend python3 -m http.server 3000
Open: http://localhost:3000
🧪 Example Usage 1. Select a provider (Contabo / Hetzner) 2. Load available MCP tools 3. Choose a tool 4. Execute 5. View structured output
This flow mirrors how: • automation systems • AI agents • MCP clients
would interact with the server.
⸻
📂 Project Structure mcp-tool-server/ ├── main.go ├── go.mod ├── handlers/ ├── tools/ ├── providers/ ├── models/ ├── frontend/ │ ├── index.html │ ├── style.css │ └── app.js
🚀 Extensibility
This MCP server is designed to scale: • Add a new provider → implement adapter • Add new tools → register them • Replace mocks → plug real APIs • Add auth, RBAC, logging, metrics
The core MCP logic remains untouched.
⸻
💡 Design Philosophy
Infrastructure should be controllable, predictable, and composable.
This project emphasizes: • clarity over complexity • structure over shortcuts • extensibility over hardcoding
⸻
👨💻 Author
Aniket Palsodkar
Designed and implemented with a focus on: • clean MCP architecture • system thinking • real-world applicability
⸻
📜 License
This project is intended for learning, demonstration, and evaluation purposes.
⸻
✅ Final Note
This repository demonstrates: • effort • design thinking • architecture • intentional trade-offs
It is not a one-prompt output, but a structured system built under constraints—exactly how real engineering works.
