로깅 및 모니터링 시스템과 상호작용하기 위한 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 사용자: "Connection closed" 오류를 방지하려면
npx -y mcp-seq를cmd /c npx -y mcp-seq로 바꾸세요.
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
