Skip to main content
Glama
nerdit-ai

Nerdit

Official
by nerdit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

restart_daemon

Restart the daemon to apply restart-required configuration, allowing in-flight builds and runs to drain first; confirm completion when uptime resets.

Instructions

Restart the daemon to apply restart-required config (admin-scoped, audited).

    Returns 202 with drain counts. **Over the HTTP MCP transport this kills
    the connection serving this call**: a dropped response after issuing it
    means the restart most likely started. Confirm with ``capabilities``
    (``uptime_s`` resets); retrying with the same idempotency key answers
    ``409 daemon.restart_in_progress`` or a fresh 202, never a second
    restart mid-drain.

Input Schema

NameRequiredDescriptionDefault
drain_timeout_sNoSeconds to let in-flight builds, runs and releases drain before the daemon self-execs, clamped server-side to [0, 300]; omit for 60. At 0 the SIGTERM can beat the 202 response.
idempotency_keyNoCaller-chosen key; the daemon REQUIRES one and the MCP tool mints a fresh uuid4 when you omit it. A retry with the same key is safe: it answers ``409 daemon.restart_in_progress`` (or replays the first 202), never a second restart mid-drain.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does: it declares admin scope and auditing, the 202 response with drain counts, and the critical caveat that over HTTP the call kills its own connection (so a dropped response means success, not failure). It also fully specifies retry behavior with an idempotency key (409 daemon.restart_in_progress or replayed 202, 'never a second restart mid-drain').

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?

Front-loaded: the action and its purpose come first, then the return contract, then the failure/recovery caveat. Slightly noisy from leaked reStructuredText backticks (``capabilities``, ``uptime_s``) and multi-line wrapping, but no sentence is wasted.

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?

There is no output schema, and the description compensates with the status code, the transport-specific failure mode, and the exact recovery/verification procedure. For a daemon-killing mutation with no annotations, this is everything an agent needs to call it and interpret an ambiguous result.

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 value by framing why drain_timeout_s and idempotency_key matter in the failure scenario the agent will actually hit (a dropped response, then a safe retry). It reinforces rather than duplicates the schema's own parameter prose.

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?

Specific verb+resource ('Restart the daemon') plus the condition that motivates it ('to apply restart-required config') and its scoping ('admin-scoped, audited'). The phrase 'the daemon' distinguishes it from the sibling restart_service without needing to name it, so an agent can select correctly.

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?

Clearly states when to use it (config marked restart-required) and states the admin scope prerequisite, plus it names capabilities as the post-hoc verification path. It does not explicitly exclude or compare against restart_service for the case where only a single service changed, which is the main remaining inference.

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