OpenUptime
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_workspacesA | List the workspaces and projects this connection can use, with their ids. Pass an id as |
| create_workspaceA | Create a new workspace (with a first project) owned by the user. Only works when the user authorized access to all workspaces. Use the returned id as |
| create_projectA | Create a project in a workspace (pass |
| list_monitorsA | List the monitors of the current project with status, uptime and latency. |
| get_monitorB | Get one monitor with its recent checks and uptime. |
| create_monitorB | Create a monitor. type is http, tcp, dns, heartbeat, postgres, mysql or redis; target is the URL, host:port or hostname. Omitted fields take defaults (60 s interval, expect HTTP 200). regions defaults to ["auto"]; name other regions (see list_regions) to check http and tcp monitors from several places. |
| update_monitorC | Change fields of a monitor; only the named fields are modified. Set paused to pause or resume it. |
| pause_monitorA | Pause a monitor: no checks run and no alerts are sent until it is resumed. |
| resume_monitorB | Resume a paused monitor. |
| run_checkA | Run a check for a monitor right now and record the result. With |
| list_regionsA | List the regions checks can run from on this deployment ( |
| delete_monitorA | Permanently delete a monitor and its history. |
| list_incidentsB | List incidents (open ones first), automatic and manual. |
| get_incidentB | Get an incident (number, root cause, postmortem) with its update timeline, internal updates included, and the failed checks around it. |
| create_incidentB | Open a manual incident, optionally tied to a monitor. Appears on status pages that include that monitor; without a monitor it appears on the status pages of the project. |
| update_incidentA | Set or clear an incident's root cause (short, up to 500 characters) and postmortem (up to 20000, markdown). They stay private until you set publishPostmortem to true; then they appear on the public status page once the incident is resolved (false takes them back). An empty string clears a field. |
| post_incident_updateA | Post a status update on an incident. status resolved closes it and must be public. A public update (the default) shows on status pages and is emailed to subscribers; an internal one is visible to the team only. |
| acknowledge_incidentB | Acknowledge an incident as the API key's owner. |
| list_status_pagesB | List the status pages of the current project. |
| create_status_pageB | Create a public status page at /status/ showing the given monitors (monitorIds). The slug is 3-40 lowercase letters, digits or hyphens and must be unused. |
| update_status_pageB | Change a status page's title, theme, latency display or the monitors it shows (monitorIds replaces the list). |
| list_channelsA | List alert channels (email, webhook, Slack…) with their ids, to attach to monitors. |
| list_maintenanceB | List scheduled maintenance windows. |
| status_page_overviewA | Current state of a public status page: overall status, each component with its status and 90-day uptime, and active incidents. No credentials needed. |
| status_page_incidentsA | Recent incidents of a public status page with their updates, newest first. No credentials needed. |
| status_page_maintenanceA | Scheduled and ongoing maintenance windows of a public status page. No credentials needed. |
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 26 tools
Most tools map to a distinct resource plus action, and the monitor/incident/status-page clusters are clearly separable. Minor overlap exists: pause_monitor/resume_monitor versus update_monitor's `paused` field do the same thing, and status_page_maintenance versus list_maintenance both concern maintenance windows but differ only by public vs. authenticated context.
The bulk of the surface follows a clean verb_noun snake_case pattern (list_monitors, create_incident, update_status_page). However, the three public-status-page tools (status_page_overview, status_page_incidents, status_page_maintenance) use a noun-prefixed form with no verb, breaking the convention and blurring whether they are readers or mutators.
At 26 tools the set is on the heavy side, though the domain genuinely spans several resource types (workspaces, projects, monitors, incidents, status pages, regions, channels, maintenance). Several tools are thin single-purpose wrappers (pause_monitor, resume_monitor, list_regions) that arguably could fold into broader operations.
Monitors and incidents have solid create/read/update coverage, but there are notable gaps: no delete for workspaces, projects, incidents, or status pages, and maintenance windows and alert channels are read-only (list only, no create/update/delete). Agents can monitor and publish but cannot fully manage the ancillary resources.