Enables posting monitoring notifications and alerts to Slack channels, with support for listing workspace users (coming soon feature).
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., "@Uptime Agent MCP Server show me all active monitors and any recent incidents"
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.
Connect your Uptime Agent monitoring system directly to AI assistants like Claude through the Model Context Protocol (MCP).
Real-time Monitoring Access: Allow AI assistants to check your system's uptime status
Incident Management: View and analyze downtime incidents through natural conversation
Monitor Creation: Set up new monitoring endpoints with simple voice or text commands
Secure Integration: Enterprise-grade security for your monitoring infrastructure
Related MCP server: GetMonitor MCP Server
Uptime Agent is a powerful monitoring solution that tracks your websites and API endpoints, alerting you when they go down. This MCP server extends Uptime Agent's capabilities by letting you interact with your monitoring system through AI assistants.
Node.js 18 or higher
An active Uptime Agent account
Your Uptime Agent API key
To obtain your Uptime Agent API key:
Log in to your Uptime Agent Dashboard
Navigate to Account → API Keys
Create a new API key with appropriate permissions
Copy the generated key for use with the MCP server
The fastest way to get started is with our setup command:
npx uptime-agent-mcp setupThis command will:
Install the MCP server
Configure it for use with Claude Desktop
Prompt you for your Uptime Agent API key
Set up all necessary configurations automatically
To install using Smithery.ai:
Create an account at smithery.ai
Get your personal key from your Smithery account
Run the following command:
npx -y @smithery/cli@latest install @AVIMBU/uptime_agent_mcp --client claude --key <personal_key>Replace <personal_key> with your actual Smithery personal key.
For advanced users who want more control:
# Clone the repository
git clone https://github.com/AVIMBU/uptime_agent_mcp.git
cd uptime_agent_mcp
# Install dependencies
npm install
# Build the project
npm run buildConfigure with your API key by creating a .env file:
UPTIME_API_KEY=your-api-key-here
PORT=3000 # Optional, defaults to 3000Start the server:
npm start
# or directly with
node dist/index.jsAfter installing using one of the methods above, your MCP server is automatically configured for Claude Desktop.
If you installed manually, add the following to your claude_desktop_config.json:
{
"mcpServers": {
"uptime-agent": {
"command": "npx",
"args": [
"-y",
"uptime-agent-mcp"
],
"env": {
"UPTIME_API_KEY": "<YOUR_API_KEY>"
}
}
}
}Alternatively, you can use Docker:
{
"mcpServers": {
"uptime-agent": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"UPTIME_API_KEY",
"uptime-agent-mcp"
],
"env": {
"UPTIME_API_KEY": "<YOUR_API_KEY>"
}
}
}
}Checking Monitors:
"Claude, show me all my active uptime monitors."
Creating a New Monitor:
"Please create a new monitor for our API endpoint at https://api.mycompany.com/v2/health"
Analyzing Incidents:
"What incidents happened on our production servers last week, and what was the average downtime?"
Function | Description | Parameters |
| Get a complete list of all monitoring endpoints | None required |
| Retrieve detailed information about a specific monitor |
|
| Set up a new endpoint to monitor |
|
Function | Description | Parameters |
| View all detected downtime incidents | None required |
| Get detailed information about a specific incident |
|
| See all incidents for a particular endpoint |
|
Function | Description | Parameters |
| Create public tracking without authentication |
|
Function | Description | Parameters |
| List all users in connected Slack workspace |
|
| Post notifications to Slack |
|
We provide Docker support for easy deployment:
# Build the Docker image
docker build -t uptime-agent-mcp .
# Run the container
docker run -p 3000:3000 -e UPTIME_API_KEY=your-api-key uptime-agent-mcpIf you have questions or need assistance:
Open an issue on GitHub
Contact us through our website: AVIMBU
This project is licensed under the MIT License - see the LICENSE file for details.
Create an anonymous tracking (doesn't require authentication)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to monitor | |
| name | No | Name of the monitor |
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 mentions that authentication isn't required, which is useful, but fails to describe other critical aspects such as what 'anonymous tracking' entails, whether it's a read or write operation, potential side effects, or response format. This leaves significant gaps in understanding the tool's behavior.
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—a single sentence that directly states the tool's purpose and key behavioral trait (no authentication required). It's front-loaded with essential information and contains no unnecessary words, making it highly efficient.
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 for a tool that likely performs a write operation ('Create'). It doesn't explain what 'anonymous tracking' means, how it differs from 'createMonitor', what the tool returns, or any error conditions. For a tool with potential complexity and no structured support, more context is needed.
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, so it fully documents the 'url' and 'name' parameters. The description adds no additional semantic context beyond what the schema provides, such as examples or constraints, but this is acceptable given the high schema coverage, resulting in a baseline score of 3.
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 a specific verb ('Create') and resource ('anonymous tracking'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'createMonitor', leaving some ambiguity about when to choose one over the other.
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 like 'createMonitor', nor does it mention any prerequisites or exclusions beyond the lack of authentication requirement. This leaves the agent without clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new monitor
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the monitor | |
| url | Yes | URL to monitor | |
| tracking_type | No | Type of monitoring (http, ping, etc.) | |
| http_method | No | HTTP method to use for HTTP monitors | |
| expected_status_code | No | Expected HTTP status code for HTTP monitors | |
| check_frequency | No | Frequency to check in seconds | |
| timeout | No | Timeout in seconds | |
| follow_redirects | No | Whether to follow HTTP redirects | |
| ssl_verification | No | Whether to verify SSL certificates |
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 but provides minimal information. 'Create a new monitor' implies a write/mutation operation but doesn't disclose permission requirements, rate limits, side effects, or what happens on success/failure. For a creation tool with 9 parameters and no annotation coverage, this is a significant gap in behavioral 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 maximally concise at just three words: 'Create a new monitor'. Every word earns its place - 'Create' specifies the action, 'new' distinguishes from updates, and 'monitor' identifies the resource. There's zero waste or redundancy in this description.
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 creation tool with 9 parameters, no annotations, and no output schema, the description is insufficiently complete. While concise, it doesn't provide the context needed for an agent to understand behavioral aspects, usage scenarios, or what to expect upon successful creation. The description should do more to compensate for the lack of structured metadata.
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 the schema already documents all 9 parameters thoroughly with descriptions and enums. The description adds no additional parameter semantics beyond what's in the schema. According to the scoring 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 ('Create') and resource ('a new monitor'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'getMonitor' or 'listMonitors', but the verb 'Create' distinguishes it from read operations. The purpose is specific enough to understand what the tool does without being tautological.
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's no mention of prerequisites, when this tool is appropriate versus other monitoring tools, or any contextual constraints. The agent must infer usage from the tool name and parameters alone without explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific incident
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the incident to retrieve |
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 states the tool retrieves details but doesn't cover aspects like authentication requirements, rate limits, error handling, or response format. This leaves significant gaps for a tool that likely involves data access.
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 without any 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. It doesn't explain what details are returned, error conditions, or behavioral traits like idempotency. For a tool with one parameter but no structured output information, more context is needed to guide 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?
The schema description coverage is 100%, with the 'id' parameter fully documented in the schema. The description adds no additional parameter details beyond implying retrieval of a single incident, so it meets the baseline score of 3 where the schema handles 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 clearly states the tool's purpose with a specific verb ('Get details') and resource ('for a specific incident'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'listIncidents' or 'listIncidentsByMonitor', which prevents a perfect score.
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 sibling tools like 'listIncidents' for multiple incidents or clarify prerequisites such as needing an incident ID, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific monitor
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the monitor to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal insight. It implies a read operation ('Get') but doesn't specify permissions required, rate limits, error handling, or what happens if the ID is invalid. For a tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
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 front-loads the core purpose without unnecessary words. Every part ('Get details for a specific monitor') directly contributes to understanding the tool's function, making it optimally concise and well-structured.
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 no annotations and no output schema, the description is incomplete for a tool that likely returns structured monitor details. It doesn't explain what 'details' include, response format, or potential side effects. For a read operation with zero structured metadata, more context is needed to guide 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%, with the single parameter 'id' documented as 'The ID of the monitor to retrieve'. The description adds no additional meaning beyond this, such as ID format, sourcing, or examples. Baseline 3 is appropriate since the schema adequately covers the parameter semantics.
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 verb ('Get') and resource ('details for a specific monitor'), making the purpose immediately understandable. It distinguishes from siblings like listMonitors by specifying retrieval of a single monitor rather than listing multiple. However, it doesn't explicitly mention what 'details' include or differentiate from other get-like tools like getIncident.
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., needing a monitor ID), contrast with listMonitors for browsing, or specify scenarios where detailed monitor information is required versus summary data from listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all incidents for the authenticated team
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves a list but does not specify details like pagination, sorting, rate limits, authentication requirements beyond 'authenticated team', or what happens if no incidents exist. This leaves significant gaps in understanding the tool's behavior.
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 without unnecessary words. It is front-loaded with the core action and resource, making it easy 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 tool has 0 parameters and no output schema, the description is minimally adequate for a simple list operation. However, without annotations, it lacks details on behavioral aspects like error handling or response format, which could be important for an agent to use it correctly in complex scenarios.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate here, but it implies a scope ('for the authenticated team') that could be considered semantic context, though not strictly parameter-related.
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 ('Get a list') and resource ('incidents for the authenticated team'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'listIncidentsByMonitor', which could cause confusion about when to use each.
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 such as 'listIncidentsByMonitor' or 'getIncident'. It lacks any mention of prerequisites, exclusions, or specific contexts for usage, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get incidents for a specific monitor
| Name | Required | Description | Default |
|---|---|---|---|
| monitor_id | Yes | The ID of the monitor to retrieve incidents for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves data ('Get incidents'), implying a read-only operation, but doesn't cover important aspects like authentication requirements, rate limits, pagination, error conditions, or what 'incidents' entail. The description is too minimal for a mutation-free tool with zero annotation coverage.
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 with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool with one parameter.
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 tool with no annotations, no output schema, and sibling tools that suggest a rich context (incident management), the description is inadequate. It doesn't explain what 'incidents' are, how results are structured, or behavioral constraints, leaving significant gaps for agent understanding.
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 the schema fully documents the single parameter 'monitor_id'. The description adds no additional parameter context beyond implying filtering by monitor, which the schema already covers. This meets the baseline for high schema coverage.
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 ('Get incidents') and target resource ('for a specific monitor'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'listIncidents' or 'getIncident', but it's specific enough to understand the core function.
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 like 'listIncidents' or 'getIncident'. It doesn't mention prerequisites, exclusions, or comparative contexts, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all monitors for the authenticated team
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves a list, implying a read-only operation, but doesn't specify whether it returns all monitors at once (vs. paginated), what data fields are included, or if there are rate limits or authentication requirements beyond 'authenticated team'. This leaves significant gaps for an agent to understand the tool's behavior.
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 without redundancy. It's front-loaded with the core action ('Get a list'), making it easy to parse. Every word earns its place, with no wasted verbiage.
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 for a list operation. It doesn't explain what the return value looks like (e.g., array of monitor objects, pagination details), nor does it address behavioral aspects like error handling or performance constraints. For a tool with zero structured metadata, more context is needed to guide an agent effectively.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. A baseline of 4 is applied since the schema fully handles parameters, and the description doesn't add unnecessary details.
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 ('Get a list') and resource ('all monitors for the authenticated team'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'getMonitor' (singular) or 'listIncidentsByMonitor', which could cause confusion about when to choose this specific list operation.
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 like 'getMonitor' (for a single monitor) or 'listIncidentsByMonitor' (for incidents filtered by monitor). It mentions the scope ('for the authenticated team'), but offers no explicit when/when-not rules or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0createAnonymousTrackingcreateMonitorgetIncidentgetMonitorlistIncidentslistIncidentsByMonitorlistMonitorsMost tools have distinct purposes targeting different resources (monitors vs. incidents) and actions (create, get, list). However, listIncidents and listIncidentsByMonitor could cause some confusion as they both list incidents, though the latter is more specific. Overall, the overlap is minimal and descriptions help clarify.
All tools follow a consistent verb_noun pattern (e.g., createMonitor, getMonitor, listMonitors). The naming is uniform across the set, using camelCase consistently without any deviations or mixed conventions, making it predictable and readable.
With 7 tools, the count is well-scoped for an uptime monitoring server. It covers core operations (create, get, list) for monitors and incidents, which aligns with the domain's typical needs without being overly sparse or bloated.
The toolset provides good coverage for reading and creating monitors and incidents, but there are notable gaps in update and delete operations for both resources. This could lead to dead ends for agents needing to modify or remove existing entries, though basic workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Monitor websites, APIs, and servers: create monitors, triage incidents, and query uptime stats.
Agent-native uptime monitoring. Create, inspect, and assert monitor health. Free 50-monitor tier.
Set up uptime monitoring from your editor: create checks, configure alerts, query uptime history.
Connect AI assistants to Xitoring monitoring: servers, uptime, incidents, metrics, SSL, and alerts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AVIMBU/uptime_agent_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
