Skip to main content
Glama
becketthayes

runtime-mcp-server

by becketthayes

Runtime Diagnostic MCP Server (runtime-mcp-server)

CI

A local Model Context Protocol (MCP) server that provides AI coding agents (like OpenAI Codex CLI) with real-time runtime diagnostics, process monitoring, and log analysis for local development environments.

🎯 Purpose

AI coding agents are great at inspecting static code, but blind to runtime execution state. This server bridges that gap by giving AI agents programmatic, read-only tools to observe running processes, analyze crash logs, inspect active ports, and monitor system resources.

Related MCP server: Harbor MCP Server

🛠️ Core Tools (v1 Features)

  1. tail_app_logs

    • Description: Reads the most recent lines from an explicitly provided local application log file.

    • Goal: Hands recent stack traces and error output to Codex without manual copy-pasting.

  2. inspect_ports

    • Description: Scans active local network ports (e.g., 3000, 8080) and identifies occupying process IDs (PIDs).

    • Goal: Automatically resolves EADDRINUSE / "Port already in use" errors and can safely signal zombie processes.

  3. get_process_metrics

    • Description: Reports per-core CPU and memory usage for an already-running local process. A process using one fully utilized core reports approximately 100%; multi-threaded processes may exceed 100%.

    • Goal: Helps Codex detect infinite loops, memory leaks, and runaway background scripts in real time.

  4. diagnose_runtime

    • Description: Combines port, process, and log evidence into a single deterministic runtime diagnosis.

    • Goal: Gives Codex a concise health report and evidence-backed next steps for a local application.

  5. capture_network_errors

    • Description: Inspects local failed HTTP/gRPC responses, CORS headers, and status codes.

    • Goal: Pinpoints root causes for broken frontend-to-backend local API connections.

🏗️ Technical Stack

  • Language: TypeScript / Node.js

  • Protocol: Model Context Protocol (MCP) via @modelcontextprotocol/sdk

  • Transport: Standard Input/Output (stdio)

  • System APIs: child_process, fs/promises, psutil / system process utilities

🚀 Getting Started

Install dependencies and compile the TypeScript source:

npm install
npm run build

Run the automated process-metrics tests:

npm test

Start the MCP server:

npm start

The server connects over stdio and currently provides port inspection, explicit log-file reading, live process metrics, and a combined runtime diagnosis tool.

Start the optional local dashboard:

npm run dashboard

Open the printed http://127.0.0.1:3847 URL to add one or more local application targets. The dashboard is read-only, polls each configured port every five seconds, and stores target settings in the browser only. It runs separately from the MCP server and is not started automatically by Codex.

🚀 Codex CLI Integration

Configured in ~/.codex/config.json (or Codex client settings):

{
  "mcpServers": {
    "runtime-diagnostics": {
      "command": "node",
      "args": ["/Users/USERNAME/Documents/Codex/runtime-mcp-server/build/index.js"]
    }
  }
}

📋 Development Roadmap

  • Initialize TypeScript & @modelcontextprotocol/sdk project

  • Implement inspect_ports tool

  • Implement tail_app_logs tool

  • Implement get_process_metrics tool

  • Implement diagnose_runtime tool

  • Add integration tests with Codex CLI

Available Tools

1 tool
inspect_portsA

Inspects active local network ports to determine which process ID (PID) and application are occupying a port.

ParametersJSON Schema
NameRequiredDescriptionDefault
portNoOptional local port to inspect. Must be an integer from 1 to 65535.

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the full transparency burden. 'Inspects' signals a non-destructive read, and the result (PID/application) is stated. However, it does not disclose what happens when port is omitted, what output shape to expect, or whether elevated privileges are required.

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 focused sentence that states the action, target resource, and purpose without filler or repetition. Every phrase contributes useful information.

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?

The tool is simple, but with no output schema and no annotations, the description should clarify omitted-port behavior and return contents more precisely. Mentioning PID and application is likely enough for basic use, but some interpretation remains.

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 schema already fully describes the port parameter, including optionality and range. The description adds no new parameter semantics beyond the association between port being and PID/application resolution, so the baseline score 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 uses a specific verb ('Inspects'), names the resource ('active local network ports'), and states the outcome (identify PID and application). It clearly distinguishes itself from any generic or unknown tool, and no sibling tools are provided to confuse selection.

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 gives clear context: use this tool when you need to map a local port to the process and app using it. It does not explicitly state when not to use it or name alternatives, but the absence of sibling tools makes that less necessary.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev1.0.0
    • First observedinspect_ports

TDQS

A3.7/5.0
Disambiguation5/5

With only one tool available, there is no possibility of confusing it with other tools. The tool's purpose is clearly defined and stands alone.

Naming Consistency5/5

The single tool name follows a clear verb_noun pattern. Since there is only one tool, there are no inconsistencies or competing naming conventions to evaluate.

Tool Count2/5

The server is named 'runtime-mcp-server,' suggesting broad runtime management capabilities, but it exposes only a single port inspection tool. This feels severely undersized for the stated scope.

Completeness1/5

The tool surface is limited to inspecting ports, with no support for managing processes, terminating processes, or interacting with runtime state in any other meaningful way. The server's purpose appears very narrow, leaving significant gaps for any real runtime management workflow.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI agents to discover, configure, and manage local development servers. Provides tools for app registration, port allocation, lifecycle control, and log access without manual config editing.
    254
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables LLM clients to inspect local dev environments—Docker container health, pnpm workspace integrity, and stuck process detection—without manual terminal copy-pasting.
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    Provides AI coding agents with structured, evidence-based diagnostics about the local development environment, detecting tech stack, runtime mismatches, dependency state, services, ports, and Git status without exposing secrets or using network calls.
    10
    Apache 2.0

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/becketthayes/runtime-mcp-server'

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