Skip to main content
Glama
Sign In
endpoint-aiops-mcp

endpoint-aiops-mcp

by AIops-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

endpoint_reboot

Destructive

Request a managed-endpoint restart and optionally preview with dry_run; it records the prior online state for auditing because the action cannot be undone.

Instructions

[WRITE][risk=medium] Request an endpoint reboot (no safe inverse).

Records the endpoint's prior online state for the audit trail; a reboot cannot be undone, so no undo descriptor is offered. Pass dry_run=True to preview — for an operation with no inverse, knowing whether the endpoint is even online (and how long since it was last seen) before committing is the whole value of asking first.

Args: endpoint_id: Endpoint id as returned by endpoint_list. dry_run: If True, preview without rebooting. target: Endpoint-management target name from config; omit for the default.

Input Schema

NameRequiredDescriptionDefault
targetNo
dry_runNo
endpoint_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.10.3
    • addedInput schema / properties / dry_run
      Added value: +{
+  "default": false,
+  "title": "Dry Run",
+  "type": "boolean"
+}
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuinely new context: prior online state is recorded for the audit trail, the action cannot be undone so no undo descriptor exists, and dry_run provides a preview path. It stops short of stating permission/auth requirements or rate limits.

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 [WRITE][risk=medium] tag is front-loaded and the key constraint ('no safe inverse') appears in the first sentence. The dry_run rationale sentence is somewhat padded ('the whole value of asking first'), but the Args block is tight and earns its space.

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 no output schema, the description would ideally mention the return shape of a dry_run preview (does it report online state and last-seen duration?), but it does cover safety, reversibility, param semantics, and preview behavior adequately for a destructive single-action tool.

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 0%, so the description carries the full burden, and it documents all three parameters: endpoint_id (with provenance 'as returned by endpoint_list'), dry_run (preview semantics), and target (config target name, omit for default). This is a solid compensation for the empty schema, though target's description is terse.

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?

States a specific verb and resource — 'Request an endpoint reboot' — and immediately scopes it ('no safe inverse'). It does not explicitly contrast itself with any sibling that performs a similar action, though its reference to endpoint_list for id provenance ties it into the toolset.

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

Usage Guidelines3/5

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

The description frames when to use dry_run=True ('knowing whether the endpoint is even online before committing'), which is useful implied usage. However, it never states when to reach for endpoint_reboot versus other endpoint-management siblings such as endpoint_assign_profile, so alternative-based guidance is absent.

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