Skip to main content
Glama

find_zombies

Detect abandoned dev servers using uptime, CPU, and memory thresholds, automatically excluding IDE, LSP, agent, and database processes. Returns candidates with reasons for manual review.

Instructions

Find dev servers that look abandoned: uptime>6h AND cpu<1% AND mem>100MB. Excludes IDE/LSP/agent/DB noise (vscode-server, language-servers, MCPs, postgres, sidekiq, etc) by default. Returns candidates with reasons. Does not auto-kill. Set include_excluded=true to also list noise that meets the heuristic.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
include_excludedNoInclude IDE/LSP/agent/DB processes that match the zombie heuristic. Default false.

Implementation Reference

  • The main handler function for find_zombies. Calls listDevServers(), filters by zombie heuristic (uptime > 6h, cpu < 1%, mem > 100MB), optionally excludes IDE/LSP/agent processes, and returns ZombieCandidate with reasons.
    export async function findZombies(opts: { include_excluded?: boolean } = {}): Promise<ZombieCandidate[]> {
      const all = await listDevServers();
      const out: ZombieCandidate[] = [];
      for (const s of all) {
        const excluded = isExcludedFromZombie(s.cmdline);
        if (excluded && !opts.include_excluded) continue;
        const oldEnough = s.uptime_seconds > 6 * 3600;
        const idle = s.cpu_pct < 1;
        const heavy = s.memory_mb > 100;
        if (oldEnough && idle && heavy) {
          const tag = excluded ? " [excluded:IDE/LSP/agent]" : "";
          out.push({
            ...s,
            reason: `uptime ${(s.uptime_seconds / 3600).toFixed(1)}h, cpu ${s.cpu_pct}%, mem ${s.memory_mb}MB${tag}`,
          });
        }
      }
      return out;
    }
  • ZombieCandidate interface extending DevServer with a 'reason' string field explaining why it's a zombie candidate.
    export interface ZombieCandidate extends DevServer {
      reason: string;
    }
  • src/index.ts:47-60 (registration)
    Tool registration/definition for 'find_zombies' including its name, description, and inputSchema (optional 'include_excluded' boolean).
      name: "find_zombies",
      description: "Find dev servers that look abandoned: uptime>6h AND cpu<1% AND mem>100MB. Excludes IDE/LSP/agent/DB noise (vscode-server, language-servers, MCPs, postgres, sidekiq, etc) by default. Returns candidates with reasons. Does not auto-kill. Set include_excluded=true to also list noise that meets the heuristic.",
      inputSchema: {
        type: "object",
        properties: {
          include_excluded: {
            type: "boolean",
            description: "Include IDE/LSP/agent/DB processes that match the zombie heuristic. Default false.",
            default: false,
          },
        },
        additionalProperties: false,
      },
    },
  • The MCP CallToolRequestSchema handler case that extracts include_excluded arg, calls findZombies(), and returns the results.
    case "find_zombies": {
      const include_excluded = Boolean((args as any)?.include_excluded);
      const data = await findZombies({ include_excluded });
      return ok({ count: data.length, candidates: data });
    }
  • ZOMBIE_EXCLUDE_PATTERNS regex list and isExcludedFromZombie helper function that filters out IDE/LSP/agent/DB processes from zombie detection.
    // Cmdline patterns that look dev-server-shaped but are noise (IDEs, LSPs, agents,
    // daemons, in-process MCPs). Never zombie-flag these.
    const ZOMBIE_EXCLUDE_PATTERNS: RegExp[] = [
      /vscode-server|\.vscode-server/,
      /vscode\.js-debug/,
      /[-_]language[-_]server\b/,
      /\b(pyright|pylsp|gopls|rust-analyzer|clangd|metals|jdtls|solargraph|sorbet|tailwindcss-language-server)\b/,
      /\bmcp-server[-_]/,
      /\b(copilot|continue-dev|cursor-agent|claude-code)\b/i,
      /\b(sidekiq|celery|resque|delayed_job|hangfire)\b/,
      /\b(redis-server|postgres|mysqld|mongod|memcached|elasticsearch)\b/,
      /\bnvim\b|\bvim\b|\bemacs\b/,
      /\bjupyter\b|\bipykernel_launcher\b/,
    ];
    
    function isExcludedFromZombie(cmdline: string): boolean {
      return ZOMBIE_EXCLUDE_PATTERNS.some((re) => re.test(cmdline));
    }
Behavior4/5

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

With no annotations, the description discloses that the tool does not auto-kill and returns candidates with reasons. It is clear about the heuristic and defaults, indicating a read-only behavior.

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?

The description is a single, well-structured sentence that front-loads the purpose and includes key details (heuristic, exclusions, behavior) without unnecessary words.

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?

The description covers the main functionality, exclusions, parameter, and output nature (candidates with reasons). Lacks output format details but is sufficient given the tool's simplicity and single parameter.

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 coverage is 100% with a parameter description. The tool description adds context about the parameter's effect (including IDE/LSP/agent/DB noise), but largely overlaps with schema description. Baseline of 3 is appropriate.

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?

The description clearly states the tool finds dev servers based on specific heuristic criteria (uptime>6h, cpu<1%, mem>100MB) and excludes certain processes, distinguishing it from siblings like kill_server and list_dev_servers.

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?

The description indicates when to use the tool (to find abandoned servers) and what it does not do (auto-kill). It also explains the include_excluded parameter. However, it does not explicitly mention alternatives among siblings.

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/HasanJahidul/localhost-mcp'

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