A FastMCP server for securely accessing BigQuery datasets with support for HTTP and Stdio transport, featuring intelligent caching, schema evolution tracking, and query analytics via Supabase.
This server presents 9 well-intentioned tools with reasonable naming conventions and mostly complete schemas. However, there are significant gaps in parameter descriptions, missing output schema documentation, and limited error handling guidance. The tools are read-only (except manage_cache), which reduces risk but also limits the domain. Tool names follow verb_noun conventions well (execute_, get_, analyze_, etc.), but descriptions are generic and do not guide LLM selection. Parameter descriptions are present but terse. Output schemas are completely undocumented, the rubric requires explicit documentation of what fields each tool returns so LLMs can plan downstream calls. The manage_cache tool violates the single-responsibility principle by bundling 'clear', 'refresh', and 'inspect' actions under one tool. Overall, this server is above the median for community tools but falls short of production grade due to missing output schemas and weak error guidance.
Analyze query performance metrics and provide optimization recommendations.
Execute a read-only SQL query on BigQuery with intelligent caching, performance tracking, and automatic schema detection.
Get detailed explanation of a table including schema, documentation, and usage statistics.
Retrieve the list of all datasets in the current project with metadata.
AI-powered query recommendations based on schema and usage patterns.
Retrieve schema change history for a table with impact analysis.
Output schemas completely undocumented. No visible documentation of what fields each tool returns. LLMs cannot plan downstream tool calls without knowing output structure.
manage_cache bundles three distinct operations (clear, refresh, inspect) under one tool with an untyped 'action' string parameter. Violates single-responsibility principle and invites hallucinated action values.
Parameter descriptions are terse and lack format guidance. E.g., 'query_context' has no examples; 'action' in manage_cache is undefined (enum vs. free-form?); 'time_range_hours' lacks min/max bounds.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Retrieve schema details for a specific table.
Retrieve all tables within a specific dataset with metadata and documentation.
Manage query result caching with actions to clear, refresh, or inspect cache entries.
No error handling guidance. Tools do not document what to do if dataset/table not found, SQL invalid, or quota exceeded. LLMs receive raw errors with no recovery path.
Tool descriptions lack differentiation guidance. get_query_suggestions vs. analyze_query_performance are similar; descriptions don't clarify when to use each. Same for explain_table vs. get_table_schema.
Result limits not documented. Does get_datasets return all datasets or capped at N? Does get_tables paginate? Missing pagination guidance for tools that could return large result sets.
No mention of cost implications. execute_bigquery_sql defaults maximum_bytes_billed to 314MB, but no description explains cost impact or guidance on setting it. LLMs may not understand the financial consequences.