Model Context Protocol server implementation for Last9 observability platform, providing tools for logs, traces, metrics, alerts, dashboards, profiles, and Grafana integration
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The Last9 MCP server exposes 56 tools with READ_ONLY, WRITE, and DESTRUCTIVE risk levels. However, critical definition quality gaps severely limit usability. Tool descriptions are extremely sparse (most 3-10 words, far below the 10-1024 character baseline of 194 chars average). The majority of tools lack visible input parameter schemas entirely, only 4 tools show explicit schema definitions (get_logs, get_traces, get_trace_waterfall, validate_dashboard, create_dashboard, update_dashboard, delete_dashboard). Parameter descriptions are almost completely absent across the 56 tools. Without schema documentation, LLMs cannot understand what inputs each tool accepts, forcing hallucination or tool misuse. Tool names follow a reasonable verb_noun pattern (get_, prometheus_, list_, etc.) but descriptions are insufficient to disambiguate tools or guide selection. Error handling guidance is not evident. Output schemas are not documented. The server appears feature-complete for Last9's use case but violates core MCP tool definition patterns.
Tools (56)
add_drop_rulewriteauthsource verified38/100
Add a new log drop rule to filter logs
create_dashboardwriteauthsource verified68/100
Create a new dashboard with the provided configuration
52 of 56 tools lack visible input schemas. Parameter definitions are absent or inferred, violating the critical requirement that LLMs know what inputs a tool accepts before calling it.
Add explicit input schemas with typed fields and descriptions for all 56 tools. Minimum: tool_name, type object, properties object with at least one field describing each parameter. Example: {'type': 'object', 'properties': {'service_name': {'type': 'string', 'description': 'The Last9 service name to query'}}, 'required': ['service_name']}
Expand all tool descriptions to 50-200 characters, following pattern: [WHAT] Get metrics for a service. [WHEN] Use this when you need performance data, request rates, or error rates for debugging. [PREREQUISITE] Requires service name from get_service_profile(). Example for get_service_summary: 'Get APM metrics for a service: latency (p50/p95/p99), error rate, throughput. Call this first to assess service health before diving into traces or logs.'
Document every parameter with type, constraint, and purpose. Example: 'service_name (string, required): The exact service name from get_service_profile(). E.g. "user-auth" or "payment-api".' Replace vague param names like 'type' with 'filter_type' or 'metric_type' to avoid ambiguity.
Document output schemas for each tool, specifying field names, types, and what they mean. Example for get_service_summary: 'Returns: {service_name, latency_p50_ms, latency_p95_ms, latency_p99_ms, error_rate_pct, requests_per_sec, timestamp_utc}'. Include which fields downstream tools (like add_drop_rule) will accept.
Add dry-run or confirmation parameters to destructive tools (delete_dashboard, delete_dashboard_snapshot). Example: 'delete_dashboard(id, dry_run=true)' returns what would be deleted; then agent can confirm with 'delete_dashboard(id, dry_run=false)'.
Spec posture evidence
Inferred effective spec: 2026-07-28+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Tool descriptions are critically sparse (3-10 words on average, far below the 194-char baseline). Descriptions lack WHAT the tool does, WHEN to use it instead of similar tools, and any prerequisites. Examples: 'Get exceptions from traces' (4 words), 'Get service environments and deployment information' (6 words).
Parameter descriptions are almost completely absent across all 56 tools. Only 6 tools show any parameter documentation in their schemas (get_logs, get_traces, get_trace_waterfall, validate_dashboard, create_dashboard, update_dashboard). LLMs cannot infer parameter meaning from names alone, 'status' could mean HTTP status, project status, or boolean flag. This violates pattern:tool-description requirement that every parameter must have a non-empty description.
All tools except get_logs, get_traces, get_trace_waterfall, validate_dashboard, create_dashboard, update_dashboard
Output schemas are not documented for any of the 56 tools. LLMs cannot plan downstream tool calls or extract relevant data without knowing what fields to expect. This violates the critical requirement that all A+ tools have documented return types (100% baseline).
Destructive operations (delete_dashboard, delete_dashboard_snapshot) lack confirmation/dry-run patterns. Agents can inadvertently delete resources without user approval. Per pattern:confirmation-request, irreversible operations should support a dry-run step or explicit confirmation.
No error handling guidance is documented. Tools do not indicate what errors are retryable, user-fixable, or fatal. Per pattern:recovery-guide, error responses must tell the LLM what to do next; a raw error code gives the agent nothing to act on.
Many tools returning lists (list_dashboards, list_datasources, prometheus_labels, get_databases, etc.) lack pagination documentation. If these tools return hundreds of items, context windows can be exhausted. Per pattern:paginated-result, list tools must document limit, offset/cursor, and total count behavior.
Tool composition is not designed for chat data model. Users say 'Get logs for the payment service', not 'Call get_logs with service_name=payment'. Tools like get_logs, get_traces, prometheus_range_query accept complex query objects (logjsonQuery, tracesQuery arrays) that require users to understand Last9's proprietary query syntax rather than natural language.
Wrap complex query parameters into simpler, composable inputs. Instead of 'get_logs(logjsonQuery: [{...}], lookbackMinutes, limit, index)', offer 'get_logs(service_name, error_pattern, lookback_minutes=60, limit=20)' and translate to LogJSON internally.
For list tools, document pagination: 'Returns max 50 items. Use limit (1-100) and offset (0-based) to paginate. Response includes total_count so agent can plan multi-page requests.'
Add error messages that guide recovery. Example: 'If service not found, call get_service_profile() to list available services.' Reference pattern:recovery-guide.
Mark read-only tools with a 'readOnlyHint' annotation and destructive tools with a 'destructiveHint' annotation in the tool definition, per current MCP spec. This helps agents reason about side effects.
Consider accepting both system IDs and human-friendly names for service_name, dashboard_id, etc. This matches the chat data model where users say 'user-auth' not 'svc_12345'. Implement name→ID resolution inside the tool.