Service Health MCP Server
The Service Health MCP Server enables AI assistants like Claude to monitor the health and responsiveness of HTTP/HTTPS endpoints through natural language conversations.
Core Capabilities:
Health Monitoring: Test connectivity, measure response times in milliseconds, and validate HTTP status codes for web services, APIs, and websites
Customizable Checks: Support for GET, POST, PUT, and DELETE methods with custom headers, adjustable timeouts (1-30 seconds), and expected status code validation (100-599)
Enterprise Security: Built-in SSRF protection that blocks internal networks, localhost, cloud metadata endpoints, and non-HTTP/HTTPS protocols
Professional Reports: Detailed health reports with status (healthy, unhealthy, warning), response time, HTTP status codes, and actionable interpretations
AI Integration: Seamless integration with Claude Desktop and other MCP-compatible assistants for natural language health checks
DevOps Ready: Monitor production APIs, microservices, CDN endpoints, validate deployments, and troubleshoot connectivity issues with comprehensive diagnostics
Allows checking GitHub API health with examples specifically mentioning api.github.com endpoint monitoring
Provides health checking capabilities for Google services with examples specifically mentioning google.com monitoring
Planned future support for checking MongoDB health and connectivity status
Planned future support for checking MySQL/MariaDB database health and connectivity status
Planned future support for checking PostgreSQL database health and connectivity status
Planned future support for exporting metrics to Prometheus as part of enterprise features
Planned future support for checking Redis connectivity and health status
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., "@Service Health MCP Servercheck if our production API at api.company.com/health is responding normally"
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.
Service Health MCP Server
π A universal service health monitoring tool for Claude Desktop and MCP-compatible AI assistants
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 buildStep 2: Configure Claude Desktop
Find your config file:
Windows:
%APPDATA%\Claude\claude_desktop_config.jsonmacOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonLinux:
~/.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
Completely close and reopen Claude Desktop
Test with:
"Check if google.com is healthy"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 filesTesting with MCP Inspector
npx @modelcontextprotocol/inspector src/server.tsProject 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 |
|
| β Yes | - | The URL to check (e.g., https://google.com) |
|
| β No |
| HTTP method to use |
|
| β No |
| Request timeout in milliseconds (1000-30000) |
|
| β No |
| Expected HTTP status code (100-599) |
|
| β 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:
Verify config syntax: Use a JSON validator
Check file paths: Use absolute paths in config
Restart completely: Close Claude Desktop entirely, then reopen
Test build: Run
npm run buildand check for errorsCheck permissions: Ensure Node.js can read the files
π Network Connection Issues
Problem: Getting network errors or timeouts.
β Network error: Client network socket disconnectedSolutions:
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 allowedThis is intentional! The security system is working correctly:
For local testing: Use browser or
curldirectlyFor 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
Fork the repository
Clone your fork:
git clone https://github.com/yourusername/service-health-mcp.gitCreate branch:
git checkout -b feature/amazing-featureMake changes and test thoroughly
Commit:
git commit -m "Add amazing feature"Push:
git push origin feature/amazing-featureOpen 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
Quick Start Guide - Complete installation instructions
Development Setup - For developers new to MCP
API Reference - Complete technical documentation
Security Details - Security considerations and best practices
π¬ Get Help
π Issues - Bug reports and feature requests
π Discussions - Community Q&A and ideas
π Connect
π©βπ» GitHub Profile - Follow for updates
π Built with β€οΈ, TypeScript, and Claude AI | Making service monitoring accessible to everyone
β Star this repo if it helped you! β
Available Tools
1 toolcheck_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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to check (e.g., https://google.com) | |
| method | No | HTTP method to use | GET |
| timeout | No | Request timeout in milliseconds | |
| expectedStatus | No | Expected HTTP status code | |
| headers | No | Optional HTTP headers to include |
TDQS
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.
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.
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.
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.
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.
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
With only one tool, there is no possibility of ambiguity or overlap with other tools, making disambiguation perfect.
The single tool name follows a clear verb_noun pattern (check_http_endpoint), and with no other tools to compare, consistency is inherently perfect.
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.
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
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
AI-powered incident management and server monitoring via MCP.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnterprise-grade MCP server for intelligent task management with 0-100 evaluation scoring, session-based workflow tracking, and real-time status monitoring for AI assistants.163MIT
- AlicenseNot gradedqualityCmaintenanceA powerful MCP server for making HTTP requests, GraphQL queries, and TCP/Telnet connections from AI assistants.7MIT
- AlicenseNot gradedqualityDmaintenanceA 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
- AlicenseNot gradedqualityBmaintenanceMCP server providing domain name checking and other web tools, accessible via MCP, REST API, and CLI for AI assistants.MIT
Appeared in Searches
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/natashanajdovski/service-health-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server