Skip to main content
Glama
enesjakozh
amitdeshmukh

stdout-mcp-server

by amitdeshmukh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

stdout-mcp-서버

명명된 파이프 시스템을 통해 stdout 로그를 캡처하고 관리하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버는 특히 다음과 같은 경우에 유용합니다.

  • 여러 프로세스나 애플리케이션의 로그를 캡처하여 Cursor IDE에서 디버깅에 사용할 수 있도록 합니다.

  • 실시간으로 애플리케이션 출력을 모니터링하고 로그를 쿼리, 필터링, 분석하기 위한 MCP 인터페이스 제공

작동 원리

  1. 서버는 특정 위치(Unix/MacOS에서는 /tmp/stdout_pipe , Windows에서는 \\.\pipe\stdout_pipe )에 명명된 파이프를 생성합니다.

  2. 모든 애플리케이션은 표준 출력 리디렉션을 사용하여 이 파이프에 로그를 기록할 수 있습니다. 예:

지엑스피1

  1. 서버는 파이프를 모니터링하고 모든 수신 로그를 캡처하며 마지막 100개 항목의 기록을 유지합니다.

  2. MCP 도구를 통해 이러한 로그를 쿼리, 필터링 및 분석할 수 있습니다.

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

시스템 요구 사항

설치하기 전에 다음 사항을 확인하세요.

  • Node.js v18 이상

설치 옵션

옵션 1: 커서에 설치

  1. 커서를 열고 Cursor > Settings > MCP Servers 로 이동합니다.

  2. "새 MCP 서버 추가"를 클릭하세요.

  3. 다음 구성으로 MCP 설정 파일을 업데이트하세요.

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

옵션 2: 다른 MCP 클라이언트에 설치

다른 MCP 클라이언트에 설치

macOS/Linux의 경우:

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

Windows의 경우:

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

사용 예

애플리케이션 로그 리디렉션

애플리케이션의 출력을 파이프로 보내려면:

# Unix/MacOS
your_application > /tmp/stdout_pipe

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

여러 애플리케이션 모니터링

여러 소스에서 로그를 리디렉션할 수 있습니다.

# Application 1
app1 > /tmp/stdout_pipe &

# Application 2
app2 > /tmp/stdout_pipe &

로그 쿼리

AI는 MCP 클라이언트의 get-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

특징

  • 명명된 파이프 생성 및 모니터링

  • 실시간 로그 캡처 및 저장

  • MCP 도구를 통한 로그 필터링 및 검색

  • 구성 가능한 로그 기록(기본값: 100개 항목)

  • 크로스 플랫폼 지원(Windows 및 Unix 기반 시스템)

명명된 파이프 위치

  • Windows: \\.\pipe\stdout_pipe

  • Unix/MacOS: /tmp/stdout_pipe

사용 가능한 도구

get-logs

선택적 필터링을 사용하여 명명된 파이프에서 로그를 검색합니다.

매개변수:

  • lines (선택 사항, 기본값: 50): 반환할 로그 줄 수

  • filter (선택 사항): 로그를 필터링할 텍스트

  • since (선택 사항): 이후 로그를 가져올 타임스탬프

응답 예시:

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

특허

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