Skip to main content
Glama

m9k_restart

Idempotent

Restart the MCP server to load fresh code after building, enabling automatic reconnection with updated builds.

Instructions

Restart the MCP server. Use after npm run build to load fresh code. The server disconnects; next MCP call auto-reconnects with the new build.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoUse SIGKILL instead of SIGTERM (for stuck processes)

Implementation Reference

  • Registration and implementation of the 'm9k_restart' tool, which schedules a process termination (SIGTERM or SIGKILL) to allow for server restart.
    server.registerTool(
      'm9k_restart',
      {
        description:
          'Restart the MCP server. Use after npm run build to load fresh code. ' +
          'The server disconnects; next MCP call auto-reconnects with the new build.',
        inputSchema: {
          force: z
            .boolean()
            .optional()
            .default(false)
            .describe('Use SIGKILL instead of SIGTERM (for stuck processes)'),
        },
        annotations: {
          readOnlyHint: false,
          destructiveHint: false,
          idempotentHint: true,
          openWorldHint: false,
        },
      },
      async ({ force }) => {
        // Detect daemon vs local mode
        let mode: 'daemon' | 'local' = 'local';
        try {
          const pidStr = fs.readFileSync(DAEMON_PID_PATH, 'utf8').trim();
          if (parseInt(pidStr, 10) === process.pid) {
            mode = 'daemon';
          }
        } catch {
          // No PID file → local mode
        }
    
        const signal = force ? 'SIGKILL' : 'SIGTERM';
    
        // Schedule kill after 200ms to let the MCP response flush
        setTimeout(() => {
          process.kill(process.pid, signal);
        }, 200);
    
        return {
          content: [
            {
              type: 'text' as const,
              text: JSON.stringify({
                restarting: true,
                mode,
                graceful: !force,
              }),
            },
          ],
        };
      },
    );
Behavior4/5

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

Annotations cover safety profile (readOnly=false, destructive=false, idempotent=true). Description adds critical operational context not in annotations: the server disconnects and auto-reconnects behavior, which is essential for an agent to handle the interruption gracefully.

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?

Three sentences with zero waste. Front-loaded with action, followed by trigger condition, then behavioral consequence. Every clause earns its place.

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?

Complete for a lifecycle management tool. Combines clear purpose, specific usage trigger, behavioral side effects (disconnect/reconnect), and schema covers the optional force parameter. No output schema required for this operation type.

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?

Schema has 100% description coverage (force parameter fully documented). Description adds no parameter-specific semantics, relying entirely on schema. Baseline 3 is appropriate given schema completeness.

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?

States specific action ('Restart the MCP server') with clear resource target. Distinguished from sibling tools (m9k_config, m9k_save, etc.) which handle data/config operations rather than lifecycle management.

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?

Provides explicit trigger condition ('Use after npm run build to load fresh code') and workflow context. Lacks explicit 'when not to use' or alternative tool comparisons, but effectively guides the primary use case.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/louis49/melchizedek'

If you have feedback or need assistance with the MCP directory API, please join our Discord server