Skip to main content
Glama
enesjakozh
amitdeshmukh

stdout-mcp-server

by amitdeshmukh
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

stdout-mcp-server

名前付きパイプシステムを介して標準出力ログをキャプチャおよび管理するモデルコンテキストプロトコル（MCP）サーバー。このサーバーは特に以下の用途に役立ちます。

  • 複数のプロセスまたはアプリケーションからログをキャプチャし、Cursor IDE でデバッグできるようにします。

  • アプリケーションの出力をリアルタイムで監視し、ログを照会、フィルタリング、分析するための MCP インターフェースを提供します。

仕組み

  1. サーバーは特定の場所に名前付きパイプを作成します (Unix/MacOS の場合は/tmp/stdout_pipe 、Windows の場合は\\.\pipe\stdout_pipe )

  2. どのアプリケーションも、標準出力リダイレクトを使用してこのパイプにログを書き込むことができます。例:

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

  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

利用可能なツール

ログを取得する

オプションのフィルタリングを使用して名前付きパイプからログを取得します。

パラメータ:

  • 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.

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