Skip to main content
Glama
Sign In
>sdcraft-mcp

>sdcraft-mcp

by TimkoNZT
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

restart_server

Force-restarts sd-server by stopping and starting it, with an option to launch a different profile instead of the current active one.

Instructions

Force-restart sd-server (stop+start). Optionally on another profile.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "restart_server"
  }
}

Input Schema

NameRequiredDescriptionDefault
profileNoProfile to start (default: current active)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden. It does say the restart is forced and implemented as stop+start, but omits permissions, downtime, impact on running jobs, and whether the restart is graceful or immediate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short clauses, front-loaded with the core action, with no wasted text. The optional profile note is placed after the main operation.

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

Completeness3/5

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

For a simple one-parameter operation with no output schema, the core invocation is clear. However, with no annotations and no safety or alternative-use guidance, important context for a force-restart operation is missing.

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?

The single parameter has 100% schema description coverage, and the schema already states "Profile to start (default: current active)." The description's "Optionally on another profile" is consistent but adds no format, constraint, or default detail beyond the schema.

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?

The description gives a specific verb and resource: "Force-restart sd-server" with the parenthetical "(stop+start)" clarifying the operation. It does not explicitly contrast itself with the stop_server/start_server siblings, but the combined restart behavior is clear from the text.

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

Usage Guidelines2/5

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

It states only that the operation is optionally on another profile. There is no guidance on when to restart versus using stop_server and start_server separately, no exclusions, and no prerequisites or alternatives named.

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