Skip to main content
Glama
enesjakozh
amitdeshmukh

stdout-mcp-server

by amitdeshmukh
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

stdout-mcp-server

A Model Context Protocol (MCP) server that captures and manages stdout logs through a named pipe system. This server is particularly useful for:

  • Capturing logs from multiple processes or applications and making them available for debugging in Cursor IDE.

  • Monitoring application output in real-time and providing a MCP interface to query, filter, and analyze logs

How It Works

  1. The server creates a named pipe at a specific location (/tmp/stdout_pipe on Unix/MacOS or \\.\pipe\stdout_pipe on Windows)

  2. Any application can write logs to this pipe using standard output redirection. For example:

your_application | tee /tmp/stdout_pipe # or
your_application > /tmp/stdout_pipe

  1. The server monitors the pipe, captures all incoming logs, and maintains a history of the last 100 entries

  2. Through MCP tools, you can query, filter, and analyze these logs

Related MCP server: @lex-tools/codebase-context-dumper

System Requirements

Before installing, please ensure you have:

  • Node.js v18 or newer

Installation Options

Option 1: Installation in Cursor

  1. Open Cursor and navigate to Cursor > Settings > MCP Servers

  2. Click on "Add new MCP Server"

  3. Update your MCP settings file with the following configuration:

name: stdout-mcp-server
type: command
command: npx stdout-mcp-server

Option 2: Installation in other MCP clients

Installation in other MCP clients

For macOS/Linux:

{
  "mcpServers": {
    "stdio-mcp-server": {
      "command": "npx",
      "args": [
        "stdio-mcp-server"
      ]
    }
  }
}

For Windows:

{
  "mcpServers": {
    "mcp-installer": {
      "command": "cmd.exe",
      "args": ["/c", "npx", "stdio-mcp-server"]
    }
  }
}

Usage Examples

Redirecting Application Logs

To send your application's output to the pipe:

# Unix/MacOS
your_application > /tmp/stdout_pipe

# Windows (PowerShell)
your_application > \\.\pipe\stdout_pipe

Monitoring Multiple Applications

You can redirect logs from multiple sources:

# Application 1
app1 > /tmp/stdout_pipe &

# Application 2
app2 > /tmp/stdout_pipe &

Querying Logs

Your AI will use the get-logs tool in your MCP client to retrieve and filter logs:

// Get last 50 logs
get-logs()

// Get last 100 logs containing "error"
get-logs({ lines: 100, filter: "error" })

// Get logs since a specific timestamp
get-logs({ since: 1648675200000 }) // Unix timestamp in milliseconds

Features

  • Named pipe creation and monitoring

  • Real-time log capture and storage

  • Log filtering and retrieval through MCP tools

  • Configurable log history (default: 100 entries)

  • Cross-platform support (Windows and Unix-based systems)

Named Pipe Locations

  • Windows: \\.\pipe\stdout_pipe

  • Unix/MacOS: /tmp/stdout_pipe

Available Tools

get-logs

Retrieve logs from the named pipe with optional filtering:

Parameters:

  • lines (optional, default: 50): Number of log lines to return

  • filter (optional): Text to filter logs by

  • since (optional): Timestamp to get logs after

Example responses:

// Response format
{
  content: [{
    type: "text",
    text: "[2024-03-20T10:15:30.123Z] Application started\n[2024-03-20T10:15:31.456Z] Connected to database"
  }]
}

License

MIT License

Available Tools

1 tool
get-logsC

Retrieve logs from the named pipe with optional filtering

ParametersJSON Schema
NameRequiredDescriptionDefault
linesNoNumber of log lines to return
filterNoText to filter logs by
sinceNoTimestamp to get logs after

TDQS

C2.9/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 burden of behavioral disclosure. It states the tool retrieves logs but doesn't cover critical aspects like whether it's read-only, destructive, requires authentication, has rate limits, or what the return format looks like. This leaves significant gaps for a tool with no annotation coverage.

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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a tool with 3 parameters. It lacks details on behavioral traits, return values, and usage context, which are essential for effective tool invocation. The high schema coverage helps but doesn't compensate for these gaps.

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 description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds minimal value by mentioning 'optional filtering' but doesn't provide additional syntax, format details, or meaning beyond what the schema already specifies. This meets the baseline for high schema coverage.

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 clearly states the action ('Retrieve logs') and resource ('from the named pipe'), providing a specific verb+resource combination. However, it doesn't differentiate from siblings since there are none, so it cannot earn the full 5 points for sibling differentiation.

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?

The description mentions 'optional filtering' but provides no guidance on when to use this tool versus alternatives, prerequisites, or specific contexts. With no sibling tools, it lacks explicit when/when-not instructions, resulting in minimal usage guidance.

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 update
    • First observedget-logs
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool 'get-logs' has a single, clearly defined purpose, so an agent cannot misselect between non-existent alternatives.

Naming Consistency5/5

The tool name 'get-logs' follows a verb_noun pattern, which is a consistent naming convention. Since there is only one tool, there are no deviations or mixed styles to evaluate, making it perfectly consistent.

Tool Count2/5

A single tool is too few for most server purposes, as it limits functionality and suggests a narrow scope. While it might be appropriate for a minimal logging utility, it lacks the breadth typically expected for an MCP server, making it borderline inadequate.

Completeness3/5

Inferring the domain as log retrieval, the tool 'get-logs' covers the core read operation but lacks other typical functionalities like clearing logs, setting log levels, or managing log sources. This creates notable gaps that could hinder agent workflows, though the basic retrieval is present.

Maintenance

ActivityInactive
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

Appeared in Searches

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/amitdeshmukh/stdout-mcp-server'

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