A log aggregation and search MCP server that discovers and queries multiple running logpond instances, merging results across instances with support for text regex, field filters, severity levels, and time ranges.
Logpond exposes 9 tools (with 3 duplicates: search_logs, tail, get_schema, stats appear twice). All tools have descriptions and input schemas with proper JSON structure. However, most parameter descriptions are minimal (10-30 chars), falling below the 72-char baseline for production tools. No output schemas are documented. Error handling is absent, tools return plain text on failure with no recovery guidance. The duplicate tool registrations suggest incomplete refactoring. All tools are read-only (no destructive operations), which reduces risk but also limits utility.
Returns available columns and sample values from recent log entries.
Get column schemas and sample values from all running logpond instances.
List all discovered logpond instances and their status.
Search log entries by text regex, field values, severity level, and time range. All filters are AND-ed. Available fields for filtering: [dynamic based on config]. Set count_only=true to get just the count without entries.
Search log entries across all running logpond instances. Supports text regex, field filters, severity, and time range. Use 'instance' to target a specific instance.
Get a quick overview of log data: total entries, severity breakdown, active field values (e.g. symbols, components), and time range. Use this first to understand what's in the logs before searching.
Duplicate tool registrations: search_logs, tail, get_schema, and stats are registered twice (hub and instance variants). LLMs will be confused by identical names with slightly different descriptions. Consolidate into single tools with optional instance filtering.
No output schemas documented. Tools return JSON or plain text, but LLMs have no formal schema to parse results. Document the structure of stats, search_logs results, and schema responses so agents can extract fields reliably.
Parameter descriptions are too brief (10-30 chars vs 72-char baseline). E.g., 'Regex to match against log body and field values' lacks guidance on case sensitivity, supported regex dialect, or performance implications. Expand to 50-150 chars with actionable context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Get stats from all running logpond instances: total entries, severity breakdown, field values, time range.
Return the last N log entries.
Return the last N log entries merged across all running logpond instances.
No error recovery guidance. When resolveInstances() returns 'No live instances found' or 'Instance not found', the response is plain text with no actionable next step. Add suggestions: 'No instances found. Check that logpond servers are running on configured ports.'
Missing parameter constraints. 'limit' and 'n' are integers with no min/max bounds. LLMs could pass limit=999999 or n=1000000, causing memory exhaustion or timeouts. Add constraints: limit 1-1000 (default 100), n 1-100 (default 10).