Uptime Agent MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Optional port number for the server | 3000 |
| UPTIME_API_KEY | Yes | Your Uptime Agent API key. Obtain from your Uptime Agent Dashboard under Account → API Keys |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| listMonitorsB | Get a list of all monitors for the authenticated team |
| getMonitorC | Get details for a specific monitor |
| createMonitorC | Create a new monitor |
| listIncidentsB | Get a list of all incidents for the authenticated team |
| getIncidentC | Get details for a specific incident |
| listIncidentsByMonitorC | Get incidents for a specific monitor |
| createAnonymousTrackingC | Create an anonymous tracking (doesn't require authentication) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Most 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.