Skip to main content
Glama
Sign In

Phare

by io.phare.mcp
OverviewDiscussionsAdmin

Complete a maintenance window

complete_maintenance_window
DestructiveIdempotent

Complete an in-progress maintenance window by ID and trigger the uptime.maintenance_window.completed alert rules, the monitors it paused are resumed and ends_at is set to the current time if it is in the future. Only in-progress maintenance windows can be completed.

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": {
      "project_id": "<project_id>",
      "maintenance_window_id": "<maintenance_window_id>"
    },
    "name": "complete_maintenance_window"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_idYesID of the project to act on, see whoami
maintenance_window_idYesID of the maintenance window to complete

Output Schema

NameRequiredDescriptionDefault
idNoMaintenance window ID
tagsNoResource tags, made of lowercase letters, numbers, `.`, `_`, `:` and `-`. An organization can have up to 200 tags.
stateNoMaintenance window state
titleNoMaintenance window title
ends_atNoDate and time when the maintenance window ends, with minute precision (seconds must be `00`). Must be after `starts_at` and within the next year.
monitorsNoList of monitor IDs linked to the maintenance window
starts_atNoDate and time when the maintenance window starts, with minute precision (seconds must be `00`). Must be within the next year.
created_atNoDate of creation for the entity
project_idNoParent project ID
updated_atNoDate of last update for the entity
descriptionNoDescription of the maintenance window
status_pagesNoList of status page IDs linked to the maintenance window
monitoring_modeNoMonitoring mode during maintenance

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "created_at": {
+      "description": "Date of creation for the entity",
+      "format": "date-time",
+      "type": "string"
+    },
+    "description": {
+      "description": "Description of the maintenance window",
+      "examples": [
+        "Planned database upgrade and maintenance"
+      ],
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "ends_at": {
+      "description": "Date and time when the maintenance window ends, with minute precision (seconds must be `00`). Must be after `starts_at` and within the next year.",
+      "format": "date-time",
+      "type": "string"
+    },
+    "id": {
+      "description": "Maintenance window ID",
+      "examples": [
+        1
+      ],
+      "type": "integer"
+    },
+    "monitoring_mode": {
+      "description": "Monitoring mode during maintenance",
+      "enum": [
+        "pause",
+        "mute",
+        "normal"
+      ],
+      "type": "string"
+    },
+    "monitors": {
+      "description": "List of monitor IDs linked to the maintenance window",
+      "examples": [
+        [
+          1,
+          2,
+          3
+        ]
+      ],
+      "items": {
+        "type": "integer"
+      },
+      "type": "array"
+    },
+    "project_id": {
+      "description": "Parent project ID",
+      "examples": [
+        1
+      ],
+      "type": "integer"
+    },
+    "starts_at": {
+      "description": "Date and time when the maintenance window starts, with minute precision (seconds must be `00`). Must be within the next year.",
+      "format": "date-time",
+      "type": "string"
+    },
+    "state": {
+      "description": "Maintenance window state",
+      "enum": [
+        "scheduled",
+        "in_progress",
+        "completed",
+        "cancelled"
+      ],
+      "type": "string"
+    },
+    "status_pages": {
+      "description": "List of status page IDs linked to the maintenance window",
+      "examples": [
+        [
+          1,
+          2
+        ]
+      ],
+      "items": {
+        "type": "integer"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "tags": {
+      "description": "Resource tags, made of lowercase letters, numbers, `.`, `_`, `:` and `-`. An organization can have up to 200 tags.",
+      "items": {
+        "examples": [
+          "environment:production"
+        ],
+        "type": "string"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "title": {
+      "description": "Maintenance window title",
+      "examples": [
+        "Database upgrade"
+      ],
+      "type": "string"
+    },
+    "updated_at": {
+      "description": "Date of last update for the entity",
+      "format": "date-time",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the annotations, the description discloses concrete side effects: alert rules named `uptime.maintenance_window.completed` are triggered, previously paused monitors are resumed, and `ends_at` is pulled forward only when it lies in the future. That is meaningful state-change detail annotations cannot convey. It does not cover permissions required or what happens if the window is already ended (beyond rejection), leaving a small gap.

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

Conciseness4/5

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

Everything is packed into one front-loaded sentence with no filler, and the action leads. The middle clause is a run-on listing three effects, which slightly hurts scanability but not comprehension.

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

Completeness4/5

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

With an output schema available and annotations covering mutation/idempotency/open-world characteristics, the description supplies the missing pieces: precondition, side effects, and timestamp behavior. Only secondary details such as permission requirements or error conditions on a non-in-progress window are absent.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters are already documented, and the description only reinforces that the window is addressed "by ID" with an in-progress requirement. No additional syntax, formatting, or relationship detail about project_id versus maintenance_window_id is added, so the baseline 3 applies.

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 opens with a specific verb and resource ("Complete an in-progress maintenance window by ID"), so an agent knows exactly what action is performed. It clearly differs in intent from delete_maintenance_window or cancel_maintenance_window, but it never names those siblings to make the distinction explicit.

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

Usage Guidelines4/5

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

"Only in-progress maintenance windows can be completed" gives an explicit precondition that excludes ended or scheduled windows, which is real usage guidance. It stops short of routing the agent between complete, cancel, and delete for a window that should not run.

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

All Phare toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources