Skip to main content
Glama
enesjakozh
amitdeshmukh

stdout-mcp-server

by amitdeshmukh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

标准输出 mcp 服务器

模型上下文协议 (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：在 Cursor 中安装

  1. 打开 Cursor 并导航至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.

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