Skip to main content
Glama
enesjakozh
amitdeshmukh

stdout-mcp-server

by amitdeshmukh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

servidor stdout-mcp

Un servidor de Protocolo de Contexto de Modelo (MCP) que captura y administra registros de salida estándar mediante un sistema de canalización con nombre. Este servidor es especialmente útil para:

  • Capturar registros de múltiples procesos o aplicaciones y ponerlos a disposición para su depuración en Cursor IDE.

  • Supervisión de la salida de la aplicación en tiempo real y provisión de una interfaz MCP para consultar, filtrar y analizar registros

Cómo funciona

  1. El servidor crea una tubería con nombre en una ubicación específica ( /tmp/stdout_pipe en Unix/MacOS o \\.\pipe\stdout_pipe en Windows)

  2. Cualquier aplicación puede escribir registros en esta tubería mediante la redirección de salida estándar. Por ejemplo:

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

  1. El servidor monitorea la tubería, captura todos los registros entrantes y mantiene un historial de las últimas 100 entradas.

  2. A través de las herramientas MCP, puede consultar, filtrar y analizar estos registros

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

Requisitos del sistema

Antes de instalar, asegúrese de tener:

  • Node.js v18 o más reciente

Opciones de instalación

Opción 1: Instalación en Cursor

  1. Abra Cursor y navegue a Cursor > Settings > MCP Servers

  2. Haga clic en "Agregar nuevo servidor MCP"

  3. Actualice su archivo de configuración MCP con la siguiente configuración:

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

Opción 2: Instalación en otros clientes MCP

Instalación en otros clientes MCP

Para macOS/Linux:

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

Para Windows:

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

Ejemplos de uso

Redirección de registros de aplicaciones

Para enviar la salida de su aplicación a la tubería:

# Unix/MacOS
your_application > /tmp/stdout_pipe

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

Monitoreo de múltiples aplicaciones

Puede redirigir registros desde múltiples fuentes:

# Application 1
app1 > /tmp/stdout_pipe &

# Application 2
app2 > /tmp/stdout_pipe &

Consulta de registros

Su IA utilizará la herramienta get-logs en su cliente MCP para recuperar y filtrar registros:

// 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

Características

  • Creación y monitorización de tuberías con nombre

  • Captura y almacenamiento de registros en tiempo real

  • Filtrado y recuperación de registros mediante herramientas MCP

  • Historial de registro configurable (predeterminado: 100 entradas)

  • Compatibilidad multiplataforma (sistemas basados en Windows y Unix)

Ubicaciones de tuberías con nombre

  • Ventanas: \\.\pipe\stdout_pipe

  • Unix/MacOS: /tmp/stdout_pipe

Herramientas disponibles

obtener registros

Recupere registros de la tubería nombrada con filtrado opcional:

Parámetros:

  • lines (opcional, predeterminado: 50): Número de líneas de registro a devolver

  • filter (opcional): Texto para filtrar los registros

  • since (opcional): marca de tiempo para obtener los registros después

Ejemplos de respuestas:

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

Licencia

Licencia MIT

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.

  1. 1 tool update
    • First observedget-logs
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.2/5.0

Scored across 1 tool

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

Related MCP Connectors

Related MCP Servers

Appeared in Searches