runtime-mcp-server
This server gives AI coding agents read-only, real-time runtime diagnostics for local development environments.
Inspect ports: Find which PID/process is occupying a local port (e.g., 3000, 8080) to resolve port conflicts.
Tail application logs: Read the most recent lines from a specified local log file to see stack traces and errors.
Get process metrics: View per-core CPU and memory usage of running processes to detect issues like infinite loops or memory leaks.
Diagnose runtime: Combine port, process, and log evidence into a deterministic health report with next steps.
Capture network errors: Inspect failed HTTP/gRPC responses, CORS headers, and status codes to debug local API connection issues.
Allows tailing stdout/stderr and crash logs from Docker-based dev servers so AI agents can inspect stack traces and runtime errors directly.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@runtime-mcp-serverCheck what process is using port 3000 and tail its logs."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Runtime Diagnostic MCP Server (runtime-mcp-server)
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)
tail_app_logsDescription: 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.
inspect_portsDescription: 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.
get_process_metricsDescription: 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.
diagnose_runtimeDescription: 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.
capture_network_errorsDescription: 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/sdkTransport: 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 buildRun the automated process-metrics tests:
npm testStart the MCP server:
npm startThe 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 dashboardOpen 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/sdkprojectImplement
inspect_portstoolImplement
tail_app_logstoolImplement
get_process_metricstoolImplement
diagnose_runtimetoolAdd integration tests with Codex CLI
Available Tools
1 toolinspect_portsA
Inspects active local network ports to determine which process ID (PID) and application are occupying a port.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Optional local port to inspect. Must be an integer from 1 to 65535. |
TDQS
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.
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.
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.
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.
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.
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 tool update
v1.0.0- First observed
inspect_ports
TDQS
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.
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.
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.
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
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
Monitoring that agents set up for themselves — cron jobs, CI/CD pipelines and AI agent runs.
Your team's shipping standards, org map and delivery metrics, inside your coding agent.
1- SuperlogOAuthsh.superlog
Open-source agent that observes and fixes your application. Query logs, traces, metrics, incidents.
AI agent observability for production traces, natural-language insights, and improvement loops.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceGives AI agents real-time access to system metrics, process management, and container orchestration.-
- AlicenseNot gradedqualityAmaintenanceEnables 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.254MIT
- AlicenseNot gradedqualityCmaintenanceEnables LLM clients to inspect local dev environments—Docker container health, pnpm workspace integrity, and stuck process detection—without manual terminal copy-pasting.MIT
- AlicenseAqualityBmaintenanceProvides 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.10Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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