OneUptime

Update Alert State

update_alert_state

DestructiveIdempotent

Update one Alert State by ID: only the fields sent change. Fields: oneuptime_describe_resource.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "update_alert_state"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	ID.
`name`	No
`color`	No
`order`	No
`isArchived`	No
`description`	No
`isCreatedState`	No
`isResolvedState`	No
`isAcknowledgedState`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026
- changedInput schema / properties / id / description
```
Previous value: -"ID (UUID) of the Alert State to update."New value: +"ID."
```

Changed19 schema fields changedNov 4, 2026

removedInput schema / properties / color / description

Removed value: -"Color of this resource in Hex (#32a852 for example)."

removedInput schema / properties / color / example

Removed value: -{
-  "_type": "Color",
-  "value": "#ff0000"
-}

addedInput schema / properties / color / properties

Added value: +{
+  "_type": {
+    "enum": [
+      "Color"
+    ],
+    "type": "string"
+  },
+  "value": {
+    "type": "string"
+  }
+}

addedInput schema / properties / color / required
```
Added value: +[
+  "_type",
+  "value"
+]
```

removedInput schema / properties / description / description

Removed value: -"Friendly description that will help you remember."

removedInput schema / properties / description / example

Removed value: -"This is an example of longer text content that might be stored in this field."

changedInput schema / properties / id / description

Previous value: -"The unique identifier (UUID) of the Alert State to update. Required. Use list_alert_states to find IDs."New value: +"ID (UUID) of the Alert State to update."

removedInput schema / properties / isAcknowledgedState / description
```
Removed value: -"Is it the acknowledged state of the alert?"
```
removedInput schema / properties / isAcknowledgedState / example
```
Removed value: -true
```

removedInput schema / properties / isArchived / description

Removed value: -"Archived states stay on the alerts and episodes that are in them, but can't be picked again. The created, acknowledged and resolved states can't be archived."

removedInput schema / properties / isArchived / example
```
Removed value: -true
```
removedInput schema / properties / isCreatedState / description
```
Removed value: -"Is it the created state of the alert?"
```
removedInput schema / properties / isCreatedState / example
```
Removed value: -true
```
removedInput schema / properties / isResolvedState / description
```
Removed value: -"Is it the resolved state of the alert?"
```
removedInput schema / properties / isResolvedState / example
```
Removed value: -true
```

removedInput schema / properties / name / description

Removed value: -"Any friendly name of this object."

removedInput schema / properties / name / example
```
Removed value: -"Example short text"
```

removedInput schema / properties / order / description

Removed value: -"Where this state sits in the project's list of alert states: 1 is the top. Alerts only ever move down the list, and an alert in a state at or below the acknowledged (or resolved) state counts as acknowledged (or resolved), so the created, acknowledged and resolved states have to stay in that order. A new state without a number goes just above the resolved state. Setting a number moves the state to that place, and the ones in between shift by one. In the dashboard, drag the rows to reorder them."

removedInput schema / properties / order / example
```
Removed value: -10
```

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / isArchived

Added value: +{
+  "default": false,
+  "description": "Archived states stay on the alerts and episodes that are in them, but can't be picked again. The created, acknowledged and resolved states can't be archived.",
+  "example": true,
+  "type": "boolean"
+}

First observedOct 19, 2026

TDQS

C2.8/5.0

Behavior3/5

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

The annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, and the description usefully adds that this is a partial update where unsent fields are preserved. It does not disclose which fields are risky to change (e.g. isArchived, isCreatedState) or how destructive an update is, so it adds some but not rich behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first clause is tight and front-loads the ID-plus-partial-update contract, but the second sentence ("Fields: oneuptime_describe_resource") is a meaningless artifact that consumes space without conveying information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutation with a nested object, no output schema, and near-zero schema coverage, the definition is materially incomplete: an agent cannot know allowed values for the state booleans or the shape of the color object from the description. The dangling reference to another tool leaves the caller to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 11% across 9 parameters, so the description should compensate and instead offers a dangling "Fields: oneuptime_describe_resource" pointer that names a sibling tool rather than any actual field. None of name, color (a nested object requiring _type/value), order, isArchived, description, or the is*State booleans are explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ("Update one Alert State by ID") and its singular target distinguishes it from list/get siblings. It does not, however, separate it from the closely-named update_alert_state_timeline or explain how it relates to update_alert.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance: nothing says when to patch an alert state versus using update_alert_state_timeline, create_alert_state, or delete_alert_state. The only usage-like statement is the patch semantics ("only the fields sent change"), which is behavioral rather than a selection rule.

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

All OneUptime tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.