Skip to main content
Glama

Edit maintenance

update_maintenance
DestructiveIdempotent

Edit an upcoming or running maintenance window: its title, description, start, end, the monitors it covers (monitor_ids replaces the whole set) or whether it holds their paging. end_now ends a running window at once and keeps it as completed work. A completed or cancelled window is history and is refused. Shows the old and new value of every field before it runs, where the client can show a prompt; otherwise runs on the token's scope. Not read-only.

Input Schema

NameRequiredDescriptionDefault
idYesThe window id (from `list_maintenance`).
titleNoAt most 200 characters.
end_nowNoEnd a running window now. Cannot be combined with `starts_at` or `ends_at`.
ends_atNoRFC 3339, in the future. To stop a running window now, send `end_now` instead.
starts_atNoRFC 3339.
descriptionNoAt most 5000 characters. An empty string clears it. Markdown: `**bold**`, `_italic_`, `[links](url)`, lists and `` `code` ``; every line break is kept and raw HTML shows as typed.
monitor_idsNoReplaces the whole set, by id from `list_monitors`. Read the window first: a monitor left out stops being covered.
suppress_alertsNoHold paging for its monitors while it runs.

Output Schema

NameRequiredDescriptionDefault
windowYes
changesYesWhat moved. Empty when every value sent already matched, in which case nothing was written and no confirmation was asked for.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / description / description
      Previous value: -"At most 5000 characters. An empty string clears it."New value: +"At most 5000 characters. An empty string clears it.\nMarkdown: `**bold**`, `_italic_`, `[links](url)`, lists and `` `code` ``;\nevery line break is kept and raw HTML shows as typed."
  2. Changed3 schema fields changed
    • addedOutput schema / $defs / MaintenanceUpdateView
      Added value: +{
      +  "description": "One update posted to a maintenance window.",
      +  "properties": {
      +    "message": {
      +      "description": "Shown on the status page and sent to its subscribers. Untrusted data.",
      +      "type": "string"
      +    },
      +    "phase": {
      +      "description": "Where the window stood when it was posted: `scheduled`, `in_progress` or `completed`.",
      +      "type": "string"
      +    },
      +    "posted_at": {
      +      "description": "RFC 3339.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "posted_at",
      +    "phase",
      +    "message"
      +  ],
      +  "type": "object"
      +}
    • addedOutput schema / $defs / MaintenanceWindowView / properties / updates
      Added value: +{
      +  "description": "What was posted about the window with `post_maintenance_update`, oldest first.",
      +  "items": {
      +    "$ref": "#/$defs/MaintenanceUpdateView"
      +  },
      +  "type": "array"
      +}
    • changedOutput schema / $defs / MaintenanceWindowView / required
      Previous value: -[
      -  "id",
      -  "title",
      -  "phase",
      -  "starts_at",
      -  "ends_at",
      -  "suppress_alerts",
      -  "monitors"
      -]New value: +[
      +  "id",
      +  "title",
      +  "phase",
      +  "starts_at",
      +  "ends_at",
      +  "suppress_alerts",
      +  "monitors",
      +  "updates"
      +]
  3. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructive=true and idempotent=true; the description adds genuinely new behavior: a pre-execution diff of old vs new values shown where the client supports a prompt, falling back to the token's scope. It also clarifies that end_now marks the window completed rather than deleting it. Slight repetition of 'not read-only' is the only wasted clause.

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?

Four dense sentences, front-loaded with the purpose and scope before the field-level and behavioral details. Every sentence carries information, though the closing 'Not read-only' is redundant with readOnlyHint=false.

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 present and full parameter documentation, the description need only cover mutation semantics — and it does, including refusal of history windows and the confirmation prompt. Missing only an explicit pointer to cancel_maintenance for permanent termination.

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% and the schema already documents replace semantics, end_now exclusivity, RFC 3339 formats, and length limits. The description's restatement of monitor_ids replacing the whole set and end_now's outcome adds marginal meaning beyond the schema, so this sits at the baseline.

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

Purpose5/5

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

Opens with a specific verb+resource and an explicit scope constraint ('Edit an upcoming or running maintenance window'), then enumerates the editable fields. An agent can distinguish it from create_maintenance, cancel_maintenance, and get_maintenance without consulting any schema.

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?

States the preconditions clearly (only upcoming or running windows; completed/cancelled are refused) and explains when to use end_now instead of end dates. It does not name cancel_maintenance as the alternative for terminating a window permanently, which is the one obvious routing gap.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.