Mcp Tool Server

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

... View full README on GitHub