用于 Seq API 端点的 MCP 服务器，用于与您的日志记录和监控系统进行交互。该服务器通过模型上下文协议 (Model Context Protocol) 提供对 Seq API 功能的全面访问。
get_signals - 获取带有过滤选项的信号
按所有者 ID 过滤
过滤共享/私有信号
支持部分匹配
get_events - 获取带有丰富过滤选项的事件
按信号 ID 过滤
自定义过滤表达式
可配置的事件数量（最多 50 个）
灵活的时间范围选项
日期范围过滤
get_alert_state - 获取警报的当前状态
signals - 列出所有带有详细信息的共享信号
信号 ID
标题
描述
共享状态
所有者信息
Related MCP server: Overwatch MCP
该服务器需要以下环境变量：
SEQ_BASE_URL (可选)：您的 Seq 服务器 URL（默认为 'http://localhost:8080'）
SEQ_API_KEY (必需)：您的 Seq API 密钥
此仓库包含一个用于 Seq 日志分析和事故调查的 Claude 技能。一旦连接了 MCP 服务器，该技能将引导 Claude 完成结构化调查（健康检查、事故分类、部署后监控），并生成一致且可操作的报告。
安装技能：
# From the releases page, download seq-ops.skill, then:
claude skill install seq-ops.skill或者直接从该仓库安装：
npx skills add ahmad2x4/mcp-server-seq当您询问诸如“早晨健康检查”、“生产环境出问题了”、“检查超时的日志”或“调查 PPSR 集成”之类的问题时，该技能会自动激活。
运行以下命令以添加服务器：
claude mcp add --transport stdio \
--env SEQ_BASE_URL=http://localhost:5341 \
--env SEQ_API_KEY=your-api-key \
seq -- npx -y mcp-seq要与您的团队共享配置，请使用 --scope project 标志（保存到 .mcp.json）：
claude mcp add --transport stdio --scope project \
--env SEQ_BASE_URL=http://localhost:5341 \
--env SEQ_API_KEY=your-api-key \
seq -- npx -y mcp-seqWindows 用户： 将
npx -y mcp-seq替换为cmd /c npx -y mcp-seq以避免“Connection closed”错误。
通过在 Claude Code 中运行 /mcp 来验证服务器是否已连接。
添加到您的 claude_desktop_config.json：
{
"mcpServers": {
"seq": {
"command": "npx",
"args": ["-y", "mcp-seq"],
"env": {
"SEQ_BASE_URL": "your-seq-url",
"SEQ_API_KEY": "your-api-key"
}
}
}
}安装依赖：
npm install构建服务器：
npm run build用于自动重新构建的开发模式：
npm run dev运行测试：
npm run test-scriptget-events 工具支持以下时间范围选项：
1m - 最近 1 分钟
15m - 最近 15 分钟
30m - 最近 30 分钟
1h - 最近 1 小时
2h - 最近 2 小时
6h - 最近 6 小时
12h - 最近 12 小时
1d - 最近 1 天
7d - 最近 7 天
14d - 最近 14 天
30d - 最近 30 天
通过 npm 全局安装：
npm install -g mcp-seq或者直接使用 npx —— 无需安装（如上面的配置示例所示）。
由于 MCP 服务器通过 stdio 进行通信，调试可能具有挑战性。该服务器为所有操作实现了适当的错误处理和日志记录。您可以运行测试脚本来验证功能：
npm run test-script该服务器通过以下方式实现了全面的类型安全：
用于静态类型检查的 TypeScript
用于运行时类型检查的 Zod 模式验证
适当的错误处理和响应格式化
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve and analyze a list of event filtered by parameters. Use this tool when you need to:
Investigate events that are being logged in the SEQ server
Details of each event is a structured log and can provide usefull information
Events could be information, error, debug, or critical
Analyze error patterns and frequencies
| Name | Required | Description | Default |
|---|---|---|---|
| signal | No | Comma-separated list of signal IDs | |
| filter | No | Filter expression for events | |
| count | No | Number of events to return (max 20) | |
| fromDateUtc | No | Start date/time in UTC | |
| toDateUtc | No | End date/time in UTC | |
| range | No | Time range (e.g., 1m, 15m, 1h, 1d, 7d) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that events are 'structured logs' and can be of types like 'information, error, debug, or critical,' but fails to specify critical details such as authentication requirements, rate limits, pagination behavior, or whether this is a read-only operation. The description adds some context but leaves significant gaps for a tool with 6 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose but includes a bulleted list that repeats concepts (e.g., 'analyze error patterns' appears twice). Some sentences could be more efficient, and the structure is somewhat repetitive, though it remains reasonably focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations, no output schema), the description is moderately complete. It covers purpose and usage context but lacks details on behavioral traits, output format, and explicit sibling tool differentiation. It's adequate for basic understanding but has clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by implying filtering and analysis capabilities, but doesn't provide additional syntax, format details, or usage examples for parameters. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Retrieve and analyze a list of events filtered by parameters,' which specifies the verb (retrieve/analyze) and resource (events). It distinguishes from sibling tools by focusing on events rather than alerts or signals, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios (investigate logged events, analyze error patterns) and implies context (SEQ server events). However, it lacks explicit guidance on when to use this tool versus sibling tools like 'get-alertstate' or 'get-signals,' and doesn't mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| ownerId | No | Owner ID to filter signals by | |
| shared | No | Whether to include only shared signals (true) or private signals (false) | |
| partial | No | Whether to include partial signal matches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get-alertstate1 field changedInput schema / additionalPropertiesRemoved value: -falseget-events3 fields changedInput schema / properties / count / defaultPrevious value: -100New value: +20Input schema / properties / count / descriptionPrevious value: -"Number of events to return (max 100)"New value: +"Number of events to return (max 20)"Input schema / properties / count / maximumPrevious value: -100New value: +20get-alertstateget-eventsget-signalsScored across 3 tools
The tools appear to target different aspects of a Seq server (alert state, events, signals), but with only one description available for 'get-events', it's unclear how 'get-alertstate' and 'get-signals' differ in purpose. This creates some ambiguity, though the distinct names suggest separate functions.
All three tools follow a consistent 'get-[noun]' naming pattern using kebab-case, which is predictable and readable. There are no deviations in style or verb usage across the tool set.
With only 3 tools, this server feels under-scoped for a logging/monitoring domain like Seq, which typically involves more operations such as creating alerts, filtering logs, or managing signals. The count is too low to cover the apparent scope effectively.
The tool set is severely incomplete for a Seq server, lacking essential operations like creating or updating alerts, sending logs, or configuring signals. Only read-only 'get' operations are provided, which will limit agents to passive monitoring without the ability to interact or modify the system.
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
Analytics and debugging for your MCP server — explore usage and sessions, then root-cause errors.
MCP server for the Seline Analytics API
