Skip to main content
Glama
natashanajdovski

Service Health MCP Server

Service Health MCP Server

πŸš€ A universal service health monitoring tool for Claude Desktop and MCP-compatible AI assistants

TypeScript MCP Compatible MIT License Security AI Built

A professional-grade MCP server that enables AI assistants to monitor web services, APIs, and HTTP endpoints with enterprise-level security. Perfect for DevOps, monitoring, and ensuring your services are running smoothly.


πŸŽ“ Transparency & Learning

πŸ€– Built with AI Assistance: This project was created by Natasha in collaboration with Claude Sonnet 4 as a learning exercise. No prior MCP server development experience was required!

πŸ“š Learning Goals Achieved:

  • βœ… MCP Protocol Implementation - From zero to working server

  • βœ… TypeScript Best Practices - Professional code structure

  • βœ… Security-First Development - Enterprise-grade SSRF protection

  • βœ… Open Source Standards - Community-ready documentation

  • βœ… Real-World Problem Solving - Filling a genuine gap in the MCP ecosystem

πŸ’‘ For Fellow Learners: If you're new to MCP development or curious about AI-assisted programming, this project demonstrates what's possible when learning with AI guidance. See our development process and contributing guidelines for insights!


Related MCP server: MCP HTTP Client Server

✨ Why This Exists

The Goal: While learning MCP development, I wanted to build something that would be genuinely useful for monitoring services through AI conversations. This MCP server provides a convenient way for Claude (and other AI assistants) to check service health naturally through chat.

What Makes It Useful:

  • πŸ” Conversational monitoring - Check services through natural language

  • πŸ›‘οΈ Security-first design with comprehensive SSRF protection

  • ⚑ Fast and reliable with detailed diagnostics

  • 🎯 Easy to use - works out of the box with Claude Desktop

  • πŸ“Š Professional output with actionable information


πŸš€ Quick Start

Step 1: Install

git clone https://github.com/natashanajdovski/service-health-mcp.git
cd service-health-mcp
npm install
npm run build

Step 2: Configure Claude Desktop

Find your config file:

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

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

  • Linux: ~/.config/Claude/claude_desktop_config.json

Add this configuration:

{
  "mcpServers": {
    "service-health": {
      "command": "node",
      "args": ["C:\\path\\to\\service-health-mcp\\dist\\server.js"],
      "cwd": "C:\\path\\to\\service-health-mcp"
    }
  }
}

Step 3: Restart & Test

  1. Completely close and reopen Claude Desktop

  2. Test with: "Check if google.com is healthy"

  3. See professional health reports instantly! πŸŽ‰


🎯 Usage Examples

Basic Health Monitoring

πŸ“ "Check if google.com is healthy"
πŸ“ "Is api.github.com responding properly?"
πŸ“ "Test if my-website.com is up"

Advanced Configurations

πŸ“ "Check if api.example.com/health is healthy with a 15 second timeout"
πŸ“ "Test httpbin.org/post using POST method"
πŸ“ "Check if my-api.com returns 201 status code"

DevOps & Monitoring

πŸ“ "Check if our production API is responding normally"
πŸ“ "Test all our microservices for health"
πŸ“ "Monitor our CDN endpoints"

πŸ“Š Sample Output

βœ… **Health Check Result**

**URL:** https://api.github.com
**Status:** HEALTHY
**Response Time:** 127ms  
**HTTP Status:** 200 (OK)
**Message:** Endpoint is healthy (200) - 127ms response time
**Checked At:** 2024-07-24T21:30:00.000Z

**Interpretation:**
πŸŽ‰ The endpoint is working perfectly! No issues detected.

For unhealthy services:

❌ **Health Check Result**

**URL:** https://down-service.com
**Status:** UNHEALTHY
**Response Time:** 5000ms
**Message:** Network error: Connection timeout
**Checked At:** 2024-07-24T21:30:00.000Z

**Interpretation:**
🚨 The endpoint has issues and may be down or misconfigured. Investigation needed.

πŸ› οΈ Features

πŸ” Health Monitoring

  • βœ… HTTP/HTTPS endpoint testing

  • βœ… Response time measurement

  • βœ… Status code validation

  • βœ… Custom headers support

  • βœ… Multiple HTTP methods

  • βœ… Configurable timeouts (1-30s)

πŸ›‘οΈ Enterprise Security

  • βœ… SSRF attack prevention

  • βœ… Internal network blocking

  • βœ… Input validation & sanitization

  • βœ… Protocol restrictions (HTTP/HTTPS only)

  • βœ… Port filtering & safe defaults

  • βœ… Zero credential exposure

⚑ Performance

  • βœ… Sub-second response times

  • βœ… Efficient connection handling

  • βœ… Minimal resource usage

  • βœ… Non-blocking async operations

  • βœ… Optimized error handling

  • βœ… Smart retry logic

πŸ”§ Developer Experience

  • βœ… Full TypeScript support

  • βœ… Professional error messages

  • βœ… Comprehensive logging

  • βœ… Easy MCP integration

  • βœ… Hot reload development

  • βœ… Extensive documentation


πŸ›‘οΈ Security

This MCP server implements enterprise-grade security to prevent attacks:

🚨 SSRF (Server-Side Request Forgery) Protection

❌ BLOCKED: localhost, 127.0.0.1
❌ BLOCKED: 192.168.x.x, 10.x.x.x, 172.16-31.x.x  
❌ BLOCKED: 169.254.169.254 (cloud metadata)
❌ BLOCKED: Non-HTTP protocols (ftp, file, etc.)
βœ… ALLOWED: Public HTTP/HTTPS endpoints only

πŸ”’ Input Validation

  • URL Format: RFC-compliant validation

  • Parameter Types: Strict type checking with Zod

  • Timeout Bounds: 1-30 second limits

  • Method Restrictions: GET, POST, PUT, DELETE only

  • Port Filtering: Standard web ports (80, 443, 8080, 8443)

πŸ›‘οΈ Safe Defaults

  • 10-second timeout (prevents hanging)

  • GET method (least intrusive)

  • No credential storage (stateless operation)

  • Minimal error details (no information leakage)


πŸ”§ Development

Prerequisites

  • Node.js 18+

  • TypeScript 5+

  • npm or yarn

Development Commands

npm run dev    # πŸ”„ Hot reload development
npm run build  # πŸ—οΈ Production build  
npm run start  # πŸš€ Run built version
npm run clean  # 🧹 Clean build files

Testing with MCP Inspector

npx @modelcontextprotocol/inspector src/server.ts

Project Structure

service-health-mcp/
β”œβ”€β”€ src/
β”‚   β”œβ”€β”€ server.ts           # 🎯 Main MCP server
β”‚   β”œβ”€β”€ health/
β”‚   β”‚   └── http-checker.ts # πŸ” Core health logic  
β”‚   β”œβ”€β”€ security/
β”‚   β”‚   └── url-validator.ts # πŸ›‘οΈ SSRF protection
β”‚   └── tools/
β”‚       └── check-http.ts   # πŸ› οΈ MCP tool interface
β”œβ”€β”€ dist/                   # πŸ“¦ Compiled JavaScript
β”œβ”€β”€ docs/                   # πŸ“š Documentation
└── package.json           # πŸ“‹ Project config

πŸ“š API Reference

check_http_endpoint

Description: Check if an HTTP/HTTPS endpoint is healthy and responsive.

Parameters

Parameter

Type

Required

Default

Description

url

string

βœ… Yes

-

The URL to check (e.g., https://google.com)

method

"GET" | "POST" | "PUT" | "DELETE"

❌ No

"GET"

HTTP method to use

timeout

number

❌ No

10000

Request timeout in milliseconds (1000-30000)

expectedStatus

number

❌ No

200

Expected HTTP status code (100-599)

headers

Record<string, string>

❌ No

{}

Optional HTTP headers

Example Request

{
  "url": "https://api.example.com/health",
  "method": "GET", 
  "timeout": 15000,
  "expectedStatus": 200,
  "headers": {
    "User-Agent": "Health-Checker/1.0",
    "Accept": "application/json"
  }
}

Response Format

{
  status: "healthy" | "unhealthy" | "warning";
  responseTime: number;          // milliseconds
  statusCode?: number;           // HTTP status code
  message: string;               // Human-readable description
  details: {
    url: string;
    timestamp: string;           // ISO 8601 format
    error?: string;              // Error details if applicable
  }
}

πŸ”„ Troubleshooting

❓ Tool Not Appearing in Claude Desktop

Problem: Claude doesn't recognize the health check tool.

Solutions:

  1. Verify config syntax: Use a JSON validator

  2. Check file paths: Use absolute paths in config

  3. Restart completely: Close Claude Desktop entirely, then reopen

  4. Test build: Run npm run build and check for errors

  5. Check permissions: Ensure Node.js can read the files

🌐 Network Connection Issues

Problem: Getting network errors or timeouts.

❌ Network error: Client network socket disconnected

Solutions:

  • Service may be down: Try checking in browser first

  • HTTPS issues: Try HTTP version of the URL

  • Firewall: Check if your network blocks the service

  • DNS: Verify the domain resolves correctly

πŸ”’ Security Restriction Messages

Problem: URLs being blocked for security reasons.

❌ Access to internal networks and localhost is not allowed

This is intentional! The security system is working correctly:

  • For local testing: Use browser or curl directly

  • For monitoring: Use external, publicly accessible URLs only

  • For internal services: Deploy monitoring within your network

⚑ Performance Issues

Problem: Slow response times or timeouts.

Solutions:

  • Increase timeout: Use 15-30 second timeouts for slow services

  • Check network: Test connectivity to the target service

  • Reduce load: Avoid checking too many endpoints simultaneously


🀝 Contributing

We welcome contributors of all skill levels! This project was built by a learner with AI assistance, and we're excited to grow the community.

🌟 Ways to Contribute

  • πŸ› Bug Reports: Found an issue? Please report it!

  • ✨ Feature Requests: Ideas for new capabilities?

  • πŸ“– Documentation: Help improve our guides

  • πŸ”§ Code: Submit pull requests for enhancements

  • πŸŽ“ Learning: Share your experience using this project

πŸš€ Getting Started

  1. Fork the repository

  2. Clone your fork: git clone https://github.com/yourusername/service-health-mcp.git

  3. Create branch: git checkout -b feature/amazing-feature

  4. Make changes and test thoroughly

  5. Commit: git commit -m "Add amazing feature"

  6. Push: git push origin feature/amazing-feature

  7. Open Pull Request with detailed description

πŸ“‹ Contribution Guidelines

  • Code Style: Follow existing TypeScript patterns

  • Security: Maintain SSRF protection standards

  • Tests: Add tests for new features

  • Documentation: Update docs for any changes

  • Commit Messages: Use clear, descriptive commits

See CONTRIBUTING.md for detailed guidelines.


πŸ—ΊοΈ Roadmap

🎯 Phase 1: Core Stability (Current)

  • βœ… HTTP/HTTPS health checking

  • βœ… Enterprise security (SSRF protection)

  • βœ… Claude Desktop integration

  • βœ… Professional documentation

🎯 Phase 2: Database Support (Next)

  • πŸ”„ PostgreSQL health checking

  • πŸ”„ MySQL/MariaDB support

  • πŸ”„ Redis connectivity testing

  • πŸ”„ MongoDB health monitoring

🎯 Phase 3: Advanced Features

  • πŸ“Š Multi-service dashboards

  • πŸ“ˆ Health history tracking

  • πŸ”” Webhook notifications

  • ⏰ Scheduled monitoring

🎯 Phase 4: Enterprise

  • ☁️ Cloud integration (AWS, Azure, GCP)

  • 🐳 Docker containerization

  • πŸ” Authentication support

  • πŸ“Š Prometheus metrics export

πŸ’‘ Community Input Welcome! Open an issue to suggest features or vote on priorities.


πŸ“œ License

MIT License - see LICENSE file for details.

TL;DR: You can use, modify, and distribute this project freely. Just include the license notice.


πŸ™ Acknowledgments

  • πŸ€– Anthropic for Claude AI assistance and the MCP protocol

  • πŸ—οΈ MCP Community for pioneering this ecosystem

  • 🌟 Open Source Contributors who make projects like this possible

  • πŸ“š Learning Community for encouraging AI-assisted development


πŸ“ž Support & Community

πŸ“š Documentation

πŸ’¬ Get Help

  • πŸ› Issues - Bug reports and feature requests

  • πŸ’­ Discussions - Community Q&A and ideas

πŸ”— Connect


πŸš€ Built with ❀️, TypeScript, and Claude AI | Making service monitoring accessible to everyone

⭐ Star this repo if it helped you! ⭐

Available Tools

1 tool
check_http_endpointA

Check if an HTTP/HTTPS endpoint is healthy and responsive. This tool will test connectivity, measure response time, and validate status codes. Perfect for monitoring APIs, websites, and web services.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to check (e.g., https://google.com)
methodNoHTTP method to useGET
timeoutNoRequest timeout in milliseconds
expectedStatusNoExpected HTTP status code
headersNoOptional HTTP headers to include

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool does (connectivity testing, response time measurement, status code validation) but doesn't mention important behavioral aspects like whether it follows redirects, handles authentication, includes request bodies, or what happens on timeout. The description adds value but leaves gaps for a monitoring tool.

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 perfectly concise with two sentences that each earn their place. The first sentence states the core functionality, and the second provides usage context. No wasted words, and the most important information (what the tool does) is front-loaded.

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?

For a monitoring tool with 5 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the 'what' but lacks details about behavioral characteristics, error handling, and output format. The 100% schema coverage helps, but the description should do more to compensate for the lack of annotations and output schema.

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 description doesn't add any parameter-specific information beyond what's already in the schema (which has 100% coverage). It mentions general capabilities like 'measure response time' and 'validate status codes' which relate to the timeout and expectedStatus parameters, but doesn't provide additional semantic context about how these parameters interact or affect the check.

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 purpose with specific verbs ('check', 'test connectivity', 'measure response time', 'validate status codes') and resources ('HTTP/HTTPS endpoint', 'APIs, websites, and web services'). It distinguishes what the tool does from a simple ping by mentioning multiple validation aspects.

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 description provides implied usage context ('Perfect for monitoring APIs, websites, and web services') but doesn't explicitly state when to use this tool versus alternatives. With no sibling tools mentioned, this is adequate but lacks explicit guidance about scenarios where this tool might not be appropriate.

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

TDQS

A3.6/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap with other tools, making disambiguation perfect.

Naming Consistency5/5

The single tool name follows a clear verb_noun pattern (check_http_endpoint), and with no other tools to compare, consistency is inherently perfect.

Tool Count2/5

One tool is too few for a server named 'Service Health MCP Server', which suggests broader health monitoring capabilities beyond just HTTP endpoints, such as checking databases, servers, or other services.

Completeness2/5

The tool surface is severely incomplete for the implied domain of service health monitoring, as it only covers HTTP endpoints and lacks tools for other common health checks like database connectivity, server metrics, or network services.

Maintenance

ActivityInactive
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

  • A
    license
    Not graded
    quality
    D
    maintenance
    A comprehensive MCP server that provides AI assistants with professional-grade network analysis capabilities, combining Wireshark packet analysis, nmap scanning, and threat intelligence for enhanced network troubleshooting and security analysis.
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    MCP server providing domain name checking and other web tools, accessible via MCP, REST API, and CLI for AI assistants.
    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/natashanajdovski/service-health-mcp'

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