Gracefully reload a service's main process with SIGHUP to apply config changes (e.g., gunicorn or nginx); explicit confirmation is required.
Send HUP to a service's main process (graceful reload, e.g. gunicorn/nginx; requires confirm=true).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| confirm | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description adds genuinely new behavioral detail beyond that: the exact signal (HUP) and that it targets the service's main process. It still doesn't say what a service does with HUP if it has no handler, or whether the call verifies the reload succeeded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and mechanism, then parenthetically adds examples and the precondition. No filler, nothing repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and the confirm precondition is stated. For a destructive, non-idempotent operation on a named target, though, the description leaves the identifier format and the failure/confirmation behavior undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It does explain that confirm must be true, which the bare boolean schema does not convey as a requirement, but it says nothing about the required 'name' parameter (systemd unit name? container name? display name?) or what a failed/missing confirm produces.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and mechanism: 'Send HUP to a service's main process' with the qualifier 'graceful reload' and concrete examples (gunicorn/nginx). This implicitly separates it from the sibling service_restart (graceful signal vs. full restart), though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'graceful reload' plus the confirm=true requirement implies when to choose this over service_restart, and the confirm gate signals a potentially disruptive operation. However, it never states the exclusion rule directly ('use service_restart instead when X') or what happens for services that don't handle HUP.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.