Open-source Go MCP server that turns LLM agents into a Trino performance copilot. Speaks the Model Context Protocol over stdio, fetches data from Trino's REST/UI APIs, projects it into compact agent-friendly DTOs, and exposes tools for per-query deep dive. Read-only by default; never submits or cancels SQL.
Two tools with clear, detailed descriptions (194 - 250 chars each) and proper input schemas. Both are READ_ONLY and well-scoped. However, output schemas are not formally documented in the visible code, descriptions mention return structure (headline, tables, findings, facts) but no JSON Schema is provided. Parameter descriptions are minimal (single short phrase). No error handling guidance, no parameter constraints (enums, ranges), and no recovery hints. Naming is verb-forward (analyze_, get_) and unambiguous. Composition is sound: two separate concerns, no overlapping functionality.
Measurements + threshold checks for one query. Returns: headline (the loudest signal), tables (enriched table objects with catalog, schema, table name, and connector_type), findings (evidence-bearing bullets with severity, details, and remediation hints), facts (the underlying numbers including per-stage operator pipelines, optimizer rule results, and dynamic filter stats)
The full SQL text, up to 64 KiB. When the query uses a prepared statement, the response contains two fields: sql (the EXECUTE statement with literal parameter values) and prepared_query (the parameterized SQL template with ? placeholders). To understand what the query actually does you MUST read the prepared_query — the sql field alone is just an opaque EXECUTE call.
Output schemas not formally documented. Descriptions mention return fields (headline, tables, findings, facts for analyze_query; sql, prepared_query for get_query_sql) but no JSON Schema is visible in source code. LLMs cannot reliably parse unstructured output or plan downstream calls without explicit schema.
Input parameter descriptions are minimal. 'The Trino query ID to analyze' and 'The Trino query ID to fetch SQL for' lack format guidance, constraints, or examples. No indication of valid ID format, length, or character restrictions.
No error handling guidance. Descriptions do not explain what happens if query_id is invalid, not found, or the Trino cluster is unreachable. No recovery hints (e.g., 'Try list_recent_queries() to find a valid ID').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
No tool annotations. Neither tool declares readOnlyHint, destructiveHint, or idempotentHint. Both are READ_ONLY and idempotent, but this is not formally signaled to the MCP client.
No pagination or result limits documented. analyze_query may return large findings/facts arrays; get_query_sql may return up to 64 KiB of SQL. No guidance on truncation, streaming, or chunking for context window management.