OneUptime

Create Scheduled Maintenance State

create_scheduled_maintenance_state

Destructive

Create a Scheduled Maintenance State. projectId comes from your credentials. 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": {
      "name": "<name>",
      "color": "<color>"
    },
    "name": "create_scheduled_maintenance_state"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Any friendly name of this object.
`color`	Yes	Color of this resource in Hex (#32a852 for example).
`order`	No
`projectId`	No
`isArchived`	No
`description`	No
`isEndedState`	No
`isOngoingState`	No
`isResolvedState`	No
`isScheduledState`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed20 schema fields changedNov 4, 2026

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."

removedInput schema / properties / isArchived / description

Removed value: -"Archived states stay on the maintenance events that are in them, but can't be picked again. The scheduled, ongoing, ended and completed states can't be archived."

removedInput schema / properties / isArchived / example
```
Removed value: -true
```
removedInput schema / properties / isEndedState / description
```
Removed value: -"Is this state a ended state?"
```
removedInput schema / properties / isEndedState / example
```
Removed value: -true
```
removedInput schema / properties / isOngoingState / description
```
Removed value: -"Is this state a ongoing state?"
```
removedInput schema / properties / isOngoingState / example
```
Removed value: -true
```
removedInput schema / properties / isResolvedState / description
```
Removed value: -"Is this state a resolved state?"
```
removedInput schema / properties / isResolvedState / example
```
Removed value: -true
```
removedInput schema / properties / isScheduledState / description
```
Removed value: -"Is this state a scheduled state?"
```
removedInput schema / properties / isScheduledState / example
```
Removed value: -true
```
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 scheduled maintenance states: 1 is the top. Events only ever move down the list, so the scheduled, ongoing, ended and completed states have to stay in that order. A new state without a number goes just above the completed 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
```

removedInput schema / properties / projectId / description

Removed value: -"ID of your OneUptime Project in which this object belongs."

removedInput schema / properties / projectId / example

Removed value: -"123e4567-e89b-12d3-a456-426614174000"

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / isArchived

Added value: +{
+  "default": false,
+  "description": "Archived states stay on the maintenance events that are in them, but can't be picked again. The scheduled, ongoing, ended and completed states can't be archived.",
+  "example": true,
+  "type": "boolean"
+}

First observedOct 19, 2026

TDQS

C2.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=false, so the description is not obligated to restate that this mutates data. Beyond annotations it contributes only that projectId is derived from credentials and a pointer to a describe tool; it never says what state is created by default, whether defaults like isArchived=false take effect, or what happens to the returned object.

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?

It is short and front-loaded, which is good, but the fragment "Fields: oneuptime_describe_resource" is cryptic and ungrammatical, reading like an unfilled template slot rather than a sentence. Two of three sentences are utility notes that don't describe the tool itself.

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 10-parameter mutation with 20% schema coverage, nested color object, no output schema, and destructiveHint=true, this definition is far too thin. An agent could call it with only name and color but would have no idea what the six boolean state flags do or what the safe pattern for creating vs updating a maintenance state is.

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 20% across 10 parameters, so the description carries most of the burden and largely fails to. It clarifies exactly one parameter (projectId being implicit from credentials) and offloads the rest via "Fields: oneuptime_describe_resource"; the semantics of order, isArchived, isEndedState, isOngoingState, isResolvedState and isScheduledState — the flags that determine the state's actual behavior — are never explained.

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

Purpose3/5

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

The first sentence names a verb and a resource ("Create a Scheduled Maintenance State"), which is enough to place it among the create_scheduled_maintenance_* siblings, but it is a near verbatim restatement of the tool name and title with no further scoping. Nothing explains what a 'Scheduled Maintenance State' represents versus a Scheduled Maintenance Event or State Timeline.

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?

"projectId comes from your credentials" is a useful setup note, but there is no guidance on when to create a state versus using update_scheduled_maintenance_state or create_scheduled_maintenance_state_timeline. The only procedural pointer is "Fields: oneuptime_describe_resource", which tells the agent how to discover fields rather than when this tool is the right choice.

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.