The Seq MCP Server provides comprehensive access to Seq's API features for logging and monitoring through the Model Context Protocol. You can:
Signals Management: Fetch signals with filters by owner ID, shared/private status, and partial matches
Event Management: Retrieve and analyze log events with rich filtering options (signal IDs, custom expressions, time/date ranges, and configurable count up to 100)
Alert Management: Check the current state of alerts
Type Safety: Benefit from static and runtime type checking via TypeScript and Zod schema validation
Allows management of Seq signals including fetching, filtering by owner ID, and filtering shared/private signals
Used for static type checking in the server implementation
Used for runtime type checking through schema validation
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Seq MCP Server show me error events from the last hour"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Server for Seq's API endpoints for interacting with your logging and monitoring system. This server provides comprehensive access to Seq's API features through the Model Context Protocol.
get_signals - Fetch signals with filtering options
Filter by owner ID
Filter shared/private signals
Support for partial matches
get_events - Retrieve events with extensive filtering options
Filter by signal IDs
Custom filter expressions
Configurable event count (max 50)
Flexible time range options
Date range filtering
get_alert_state - Retrieve the current state of alerts
signals - List all shared signals with detailed information
Signal ID
Title
Description
Sharing status
Owner information
Related MCP server: Overwatch MCP
The server requires the following environment variables:
SEQ_BASE_URL (optional): Your Seq server URL (defaults to 'http://localhost:8080')
SEQ_API_KEY (required): Your Seq API key
This repo includes a Claude skill for Seq log analysis and incident investigation. Once the MCP server is connected, the skill guides Claude through structured investigations — health checks, incident triage, post-deployment monitoring — and produces consistent, actionable reports.
Install the skill:
# From the releases page, download seq-ops.skill, then:
claude skill install seq-ops.skillOr install directly from this repo:
npx skills add ahmad2x4/mcp-server-seqThe skill automatically activates when you ask things like "morning health check", "something is broken in prod", "check the logs for timeouts", or "investigate the PPSR integration".
Run the following command to add the server:
claude mcp add --transport stdio \
--env SEQ_BASE_URL=http://localhost:5341 \
--env SEQ_API_KEY=your-api-key \
seq -- npx -y mcp-seqTo share the configuration with your team, use the --scope project flag (saves to .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 users: Replace
npx -y mcp-seqwithcmd /c npx -y mcp-seqto avoid "Connection closed" errors.
Verify the server is connected by running /mcp inside Claude Code.
Add to your 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"
}
}
}
}Install dependencies:
npm installBuild the server:
npm run buildFor development with auto-rebuild:
npm run devRun tests:
npm run test-scriptThe get-events tool supports the following time range options:
1m - Last minute
15m - Last 15 minutes
30m - Last 30 minutes
1h - Last hour
2h - Last 2 hours
6h - Last 6 hours
12h - Last 12 hours
1d - Last day
7d - Last 7 days
14d - Last 14 days
30d - Last 30 days
Install globally via npm:
npm install -g mcp-seqOr use directly with npx — no installation required (as shown in the configuration examples above).
Since MCP servers communicate over stdio, debugging can be challenging. The server implements proper error handling and logging for all operations. You can run the test script to verify functionality:
npm run test-scriptThe server implements comprehensive type safety using:
TypeScript for static type checking
Zod schema validation for runtime type checking
Proper error handling and response formatting
| 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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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 secureFlows: token-free URL builders and integration-linting tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ahmad2x4/mcp-server-seq'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
