Skip to main content
Glama
vmware-skills

vmware-aria

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

end_resource_maintenance

Idempotent

Take a resource out of maintenance mode to resume alerting and data collection. Preview the blast radius, then confirm to apply the change.

Instructions

[WRITE] Take one resource out of maintenance so Aria resumes alerting on it and collecting its data.

Without confirm=True this only previews: it reads the resource and returns blast_radius (resource name and kind, each adapter's state, the maintenance mode it is in) and changes nothing. Show that to the user and get their explicit decision. Do not set confirm=True on your own because the user asked earlier: they have not seen what it changes yet. Refused with confirm=True: a resource known not to be in maintenance (an adapter reports a state such as STARTED or STOPPED — nothing to end), and a resource whose state is unknown (unreadable, or reported as UNKNOWN / NONE) — end that one from the Aria UI or the CLI after checking it.

Acting returns the state before and after, confirmed (true / false / null when unknown) and a note. Undo: start_resource_maintenance (re-enters as manual maintenance), recorded only when the resource was known to be in maintenance before.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoAria target name from config; default when omitted.
confirmNoFalse (default) returns the blast radius and changes nothing. True applies it.
confirmedNoDeprecated alias for confirm; removed in the next minor release. confirmed=False holds even when confirm=True.
resource_idYesResource UUID from list_resources (not the resource name).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.16.0
    • addedInput schema / properties / confirm
      Added value: +{
+  "default": false,
+  "description": "False (default) returns the blast radius and changes nothing. True applies it.",
+  "title": "Confirm",
+  "type": "boolean"
+}
    • addedInput schema / properties / confirmed / anyOf
      Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / confirmed / default
      Previous value: -falseNew value: +null
    • changedInput schema / properties / confirmed / description
      Previous value: -"Must be True to actually end maintenance. Default False = preview only."New value: +"Deprecated alias for confirm; removed in the next minor release. confirmed=False holds even when confirm=True."
    • removedInput schema / properties / confirmed / type
      Removed value: -"boolean"
  2. Addedv1.15.0

TDQS

A4.8/5.0
Behavior5/5

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

The description goes far beyond the annotations: it explains the preview mode (confirm=False) returns blast_radius and changes nothing, that confirm=True applies the change, that acting returns before/after state and a confirmed flag, and that undo is start_resource_maintenance. It also discloses refusal conditions. This is rich behavioral context that annotations alone (readOnlyHint=false, idempotentHint=true) do not provide.

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?

The description is dense but well-organized: it front-loads the core action, then explains preview mode, refusal conditions, return values, and undo. Every sentence earns its place, though the refusal paragraph is slightly long and could be tightened. Overall it is efficient and structured for an agent to parse.

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

Completeness5/5

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

For a mutation tool with no output schema, the description covers the essential context: what the tool does, what preview returns, what acting returns, when it refuses, and how to undo. The parameter semantics are fully covered by the schema plus description. Nothing an agent needs to call this tool correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the confirm parameter's role in preview vs. apply, and by clarifying that resource_id is a UUID from list_resources. It also mentions the deprecated confirmed alias and its precedence, which is valuable. It doesn't elaborate on target, but the schema already covers it.

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?

The description opens with a specific verb and resource: 'Take one resource out of maintenance so Aria resumes alerting on it and collecting its data.' This clearly distinguishes it from the sibling start_resource_maintenance, and the [WRITE] prefix plus the preview/confirm distinction make the tool's core function unmistakable.

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

Usage Guidelines5/5

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

The description explicitly states when to use the tool (to end maintenance), when not to use it (resource not in maintenance or unknown state), and names the alternative (start_resource_maintenance for undo). It also gives a strong directive: do not set confirm=True on your own because the user hasn't seen the blast radius yet. This is exemplary usage guidance.

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

Deploy Server

Other Tools