super-log
Related Servers
Alternatives to super-log
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityAmaintenanceA terminal live-tail and a browser dashboard — one process, one event stream, served from localhost. Unified timeline across Claude Code, Codex, Gemini CLI, Cursor, Hermes, and OpenClaw. Token + cost accounting, compaction + anomaly detection, hybrid search, SVG call graphs, monaco-style diff attribution, agent-aware replay ("what would the agent say if I edited the prompt?"), policy editor, MCP s11 npm15MIT
- FlicenseNot gradedqualityNot gradedmaintenanceCaptures and stores console output from any process in SQLite with full-text search, enabling AI assistants to search logs, monitor errors, and analyze multi-process activity through natural language queries.-
- AlicenseNot gradedqualityCmaintenanceMetered log ingestion server for autonomous agents, allowing NDJSON log posting with USDC payment per line on Base L2. Agents can freely tail and search their own logs with configurable retention tiers.MIT
- AlicenseNot gradedqualityAmaintenanceEnables natural-language querying and investigation of homelab logs from syslog, Docker, OTLP, and AI transcripts, with SQLite full-text search, timeline correlation, incident clustering, and fleet topology insights.3AGPL 3.0
- FlicenseNot gradedqualityCmaintenanceA local-first MCP server that gives AI coding agents runtime visibility and AI-managed debug logging. It replaces blind print() debugging by turning runtime execution into causal chains, allowing agents to instantly locate bugs by finding missing .success events in Python and TypeScript code. Single binary with MCP, CLI, and HTTP interfaces.-
- AlicenseNot gradedqualityDmaintenanceA 100% local development monitoring tool that captures browser console logs, network requests, and backend server output for analysis by AI assistants via MCP. It enables LLMs to debug applications by providing structured, real-time access to full-stack log data and persistent local storage.2 npm7MIT
TDQS
Scored across 9 tools
Most tools have clearly distinct purposes: listing, tailing, searching live vs. searching history, blocking, and status are all separable. The only mild ambiguity is between search_logs and search_history, whose names and descriptions are close enough that an agent might need to read carefully to pick the right one.
There is a recognizable pattern with list_webhooks/list_streams and search_logs/search_history, but other names break it: stream_guide, hub_status, agent_report, and wait_for use different structures. The mix is readable and not chaotic, but it lacks the uniform verb_noun style of the best server sets.
Nine tools is well-scoped for a logging and monitoring server. Each tool covers a distinct operation without padding or duplication, and the count feels right for the domain.
The surface covers the full read/monitoring lifecycle: orientation, live tailing, text search, historical search, blocking waits, webhook discovery, hub health, and a deliberate status heartbeat write. Since the server is intentionally otherwise read-only, there are no obvious dead ends or missing core operations.