Tags: pvoo/bigquery-mcp
Tags
chore: bump fastmcp + google-cloud-bigquery, pin packaging<26 in build ( #12) Three small changes in one PR: - Bump fastmcp 2.13.0 → 3.3.1. Major version; our surface area (FastMCP, @mcp.tool, mcp.run, Annotated/Field) is unchanged. No code changes required. - Bump google-cloud-bigquery 3.31.0 → 3.41.0. Minor. - Pin packaging<26 in [build-system].requires. packaging==26.2 ships a broken wheel (missing requirements.py and other submodules), so hatchling crashes in PEP 517 isolated builds. Without this pin, 'uv sync', 'uv build', and any 'uv run ...' subprocess fail — including all 9 integration tests that spawn the server. Full suite (52/52) passes including real-BigQuery integration tests. Lint/format/mypy clean.
docs: add BIGQUERY_MAX_BYTES_BILLED to example configs (#8) Surface the per-query spend cap (introduced in #7) in the copy-paste examples so users adopt a safe default. 20 GiB (~USD 0.10/query at $5/TiB) — conservative starting point; the in-code default remains 100 GiB. Co-authored-by: pvoorschot <pvo@domain.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Remove max_results parameter from run_query tool (#4) - Remove max_results parameter from run_query tool completely - Update tool description to recommend using LIMIT clause in SQL queries - Remove all CLI arguments and environment variables related to query max_results - Update tests to remove max_results usage and use LIMIT in SQL instead - Improve list tools documentation to clarify max_results is optional integer The run_query tool now relies on SQL LIMIT clause for result control, making it more explicit and giving users full control over result size. Co-authored-by: pvoorschot <pvo@domain.com>