MCP server for querying and interacting with Seq structured logging server
The Seq MCP server defines 4 tools with complete input schemas and reasonable descriptions. Naming conventions are clear (verb-prefixed: SeqSearch, SeqWaitForEvents, SignalList, SeqConvertFilter). All tools have descriptions exceeding 20 characters, and all parameters include type information and descriptions. However, output schemas are not documented, the source shows EventEntity and SignalEntity as return types but does not provide JSON schema definitions visible in the tool registration. Parameter constraints are well-specified (e.g., count 1-1000, timeoutSeconds 1-300 with [Range] attributes), meeting baseline standards for numeric ranges. Error handling includes validation (e.g., invalid date format, signal not found) with actionable messages. The tool composition is sound: each tool has a single clear responsibility, and parameter naming (filter, count, signalId, workspace) is consistent and unambiguous. No security issues detected, no credentials or secrets in parameters. Descriptions are moderately detailed (100-200 chars range), approaching the LLM-optimized sweet spot. Main gap: output schema documentation is absent, preventing LLMs from planning downstream operations with confidence.
Normalize common filter patterns to Seq's expected format and convert fuzzy filter expressions to strict Seq filter syntax
Search Seq events with filters, date ranges, signals, pagination, and optional timeout. Pass an empty filter (the default) or "*" to return all events. For date filtering, use fromDateUtc/toDateUtc parameters instead of @Timestamp in the filter expression. For pagination, use afterId with the last event ID from previous results.
Wait for and capture live events from Seq (times out after 5 seconds, returns captured events as a snapshot)
List all available signals in Seq for use with signal-based filtering
Output schemas not documented in tool definitions. Source shows return types (EventEntity, SignalEntity, SeqConvertFilterResult) but no JSON schema structure is visible. LLMs cannot reliably plan downstream operations or extract specific fields without knowing the response shape.
SeqWaitForEvents description lacks detail on what 'captured as snapshot' means, does it return raw events or a summary? Also does not clarify timeout behavior (does it return early if timeout is reached, or error?). Ambiguity may cause LLM misuse.
SeqSearch accepts 'workspace' parameter (optional) but no documentation explains when or how to use it. No guidance on multi-tenant scenarios, workspace resolution, or fallback behavior if workspace is invalid.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
SignalList has minimal description (49 chars). LLMs need guidance on when to call it (e.g., 'Call this first to discover available signals before filtering') and what structure the response has.
SeqConvertFilter returns a SeqConvertFilterResult record with fields (StrictExpression, MatchedAsText, ReasonIfMatchedAsText), but the source does not show how this maps to JSON or what the LLM should expect. No output schema documentation.