Every change Wellknown observed on this MCP server, newest first, with what it was before and what it became. Tool-surface changes carry the definition diff. Nothing here is edited after the fact.
Certificate changed, valid to 2026-12-30
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Certificate changed, valid to 2026-12-21
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Certificate changed, valid to 2026-12-11
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Changed the definition of "get_index" and "list_indexes"
⟨1427 unchanged words⟩ ":{"description":"Optional. The number of physical shards for the index. In Cloud Firestore, data and index entries are stored in contiguous, ordered key ranges called splits. While document keys within a collection are hashed to distribute write traffic across splits, secondary index entries are ordered lexicographically by their indexed field values. When an index contains fields with sequential or monotonically increasing or decreasing values (such as timestamps or auto-incrementing IDs), every incoming index write targets the boundary of the index keyspace on a single split. Because sequential writes continuously advance to the newest split at the edge of the range, automatic load-based splitting cannot divide the write traffic across storage servers. Under high write rates, this concentration creates an append hotspot on that single split, resulting in elevated write latency, contention errors, and transaction aborts. Sharded indexes solve this write bottleneck by hash partitioning the secondary index keyspace. When `shard_count` is configured to N, Firestore automatically prepends a virtual computed shard field (with values from 0 to N-1) as the leading field of the index. This splits a single sequential key range into N independent key ranges, uniformly scattering adjacent writes across distinct splits and storage servers to enable linear write scaling. Query trade-offs: Hash partitioning trades query performance for write throughput. Because matching index entries are scattered across all shards, queries executing against a sharded index cannot read from a single contiguous range. The query engine must fan out parallel seeks across all N shards and merge the ordered results. Even index point lookups and queries with `LIMIT 1` must seek across all N shards. Sizing and best practices: - Indexes cannot be updated in-place. `shard_count` is immutable once an index is created; to \"reshard\" an index, create a new index with the desired `shard_count` and delete the original index. - Use sharded indexes only for indexes experiencing write bottlenecks (typically exceeding 500-1,000 writes/sec) on sequential or timestamp fields. - Do not shard indexes on uniformly distributed fields (such as UUIDs or hash tokens), where writes naturally spread across splits without sharding. Sharding uniform indexes adds query overhead without improving write throughput. - Do not shard read-heavy or low-write collections. - Size `shard_count` based on expected peak write throughput. Because a single split sustains roughly 500-1,000 writes/sec on sequential keys, estimate `shard_count ≈ ceil(peak_write_qps / 500)`. - e.g., 4 for up to ~2,000-4,000 writes/sec, 16 for up to ~10,000+ writes/sec. - Setting an excessively high shard count produces diminishing write returns while needlessly increasing read latency and seek costs. If <= 1, the index is unsharded (1 physical shard).
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Certificate changed, valid to 2026-12-03
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Certificate changed, valid to 2026-11-27
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Authorization not required, issuer https://accounts.google.com
Removed "query_collection" and "run_aggregation_query" (25 tools before, 23 now)
Run a query against a Firestore database. Executes a structured query and returns the matching documents. Required Parameters: - `parent`: The parent resource name in `projects/{project_id}/databases/{database_id}/documents` format (e.g., `projects/my-project/databases/(default)/documents`). - `structured_query`: A `StructuredQuery` object defining the query to execute. Example usage: ```json { "parent": "projects/my-project/databases/(default)/documents", "structured_query": { "from": [{"collection_id": "users"}], "where": { "field_filter": { "field": {"field_path…
Run an aggregation query against a Firestore database. Executes an aggregation query (such as COUNT, SUM, or AVG) over a structured query and returns the aggregated results. Required Parameters: - `parent`: The parent resource name in `projects/{project_id}/databases/{database_id}/documents` format (e.g., `projects/my-project/databases/(default)/documents`). - `structured_aggregation_query`: A `StructuredAggregationQuery` object defining the aggregation query to execute. Example usage (COUNT and AVG): ```json { "parent": "projects/my-project/databases/(default)/documents", "structured_a…
Added "query_collection" and "run_aggregation_query" (23 tools before, 25 now)
Run a query against a Firestore database. Executes a structured query and returns the matching documents. Required Parameters: - `parent`: The parent resource name in `projects/{project_id}/databases/{database_id}/documents` format (e.g., `projects/my-project/databases/(default)/documents`). - `structured_query`: A `StructuredQuery` object defining the query to execute. Example usage: ```json { "parent": "projects/my-project/databases/(default)/documents", "structured_query": { "from": [{"collection_id": "users"}], "where": { "field_filter": { "field": {"field_path…
Run an aggregation query against a Firestore database. Executes an aggregation query (such as COUNT, SUM, or AVG) over a structured query and returns the aggregated results. Required Parameters: - `parent`: The parent resource name in `projects/{project_id}/databases/{database_id}/documents` format (e.g., `projects/my-project/databases/(default)/documents`). - `structured_aggregation_query`: A `StructuredAggregationQuery` object defining the aggregation query to execute. Example usage (COUNT and AVG): ```json { "parent": "projects/my-project/databases/(default)/documents", "structured_a…
Authorization not required, issuer https://accounts.google.com
Removed "query_collection" and "run_aggregation_query" (25 tools before, 23 now)
Run a query against a Firestore database. Executes a structured query and returns the matching documents. Required Parameters: - `parent`: The parent resource name in `projects/{project_id}/databases/{database_id}/documents` format (e.g., `projects/my-project/databases/(default)/documents`). - `structured_query`: A `StructuredQuery` object defining the query to execute. Example usage: ```json { "parent": "projects/my-project/databases/(default)/documents", "structured_query": { "from": [{"collection_id": "users"}], "where": { "field_filter": { "field": {"field_path…
Run an aggregation query against a Firestore database. Executes an aggregation query (such as COUNT, SUM, or AVG) over a structured query and returns the aggregated results. Required Parameters: - `parent`: The parent resource name in `projects/{project_id}/databases/{database_id}/documents` format (e.g., `projects/my-project/databases/(default)/documents`). - `structured_aggregation_query`: A `StructuredAggregationQuery` object defining the aggregation query to execute. Example usage (COUNT and AVG): ```json { "parent": "projects/my-project/databases/(default)/documents", "structured_a…
Added "query_collection" and "run_aggregation_query" (23 tools before, 25 now)
Run a query against a Firestore database. Executes a structured query and returns the matching documents. Required Parameters: - `parent`: The parent resource name in `projects/{project_id}/databases/{database_id}/documents` format (e.g., `projects/my-project/databases/(default)/documents`). - `structured_query`: A `StructuredQuery` object defining the query to execute. Example usage: ```json { "parent": "projects/my-project/databases/(default)/documents", "structured_query": { "from": [{"collection_id": "users"}], "where": { "field_filter": { "field": {"field_path…
Run an aggregation query against a Firestore database. Executes an aggregation query (such as COUNT, SUM, or AVG) over a structured query and returns the aggregated results. Required Parameters: - `parent`: The parent resource name in `projects/{project_id}/databases/{database_id}/documents` format (e.g., `projects/my-project/databases/(default)/documents`). - `structured_aggregation_query`: A `StructuredAggregationQuery` object defining the aggregation query to execute. Example usage (COUNT and AVG): ```json { "parent": "projects/my-project/databases/(default)/documents", "structured_a…
Removed "query_collection" and "run_aggregation_query" (25 tools before, 23 now)
Run a query against a Firestore database. Executes a structured query and returns the matching documents. Required Parameters: - `parent`: The parent resource name in `projects/{project_id}/databases/{database_id}/documents` format (e.g., `projects/my-project/databases/(default)/documents`). - `structured_query`: A `StructuredQuery` object defining the query to execute. Example usage: ```json { "parent": "projects/my-project/databases/(default)/documents", "structured_query": { "from": [{"collection_id": "users"}], "where": { "field_filter": { "field": {"field_path…
Run an aggregation query against a Firestore database. Executes an aggregation query (such as COUNT, SUM, or AVG) over a structured query and returns the aggregated results. Required Parameters: - `parent`: The parent resource name in `projects/{project_id}/databases/{database_id}/documents` format (e.g., `projects/my-project/databases/(default)/documents`). - `structured_aggregation_query`: A `StructuredAggregationQuery` object defining the aggregation query to execute. Example usage (COUNT and AVG): ```json { "parent": "projects/my-project/databases/(default)/documents", "structured_a…
Certificate recorded, valid to 2026-11-02
Authorization not required, issuer https://accounts.google.com
Added "query_collection" and "run_aggregation_query" (23 tools before, 25 now)
Run a query against a Firestore database. Executes a structured query and returns the matching documents. Required Parameters: - `parent`: The parent resource name in `projects/{project_id}/databases/{database_id}/documents` format (e.g., `projects/my-project/databases/(default)/documents`). - `structured_query`: A `StructuredQuery` object defining the query to execute. Example usage: ```json { "parent": "projects/my-project/databases/(default)/documents", "structured_query": { "from": [{"collection_id": "users"}], "where": { "field_filter": { "field": {"field_path…
Run an aggregation query against a Firestore database. Executes an aggregation query (such as COUNT, SUM, or AVG) over a structured query and returns the aggregated results. Required Parameters: - `parent`: The parent resource name in `projects/{project_id}/databases/{database_id}/documents` format (e.g., `projects/my-project/databases/(default)/documents`). - `structured_aggregation_query`: A `StructuredAggregationQuery` object defining the aggregation query to execute. Example usage (COUNT and AVG): ```json { "parent": "projects/my-project/databases/(default)/documents", "structured_a…
First tool surface recorded: 23 tools (server version ESF)
Showing the latest 37 events. The API returns up to 500 and filters by kind: ?kind=tool_surface_changed
⟨856 unchanged words⟩ ":{"description":"Optional. The number of physical shards for the index. In Cloud Firestore, data and index entries are stored in contiguous, ordered key ranges called splits. While document keys within a collection are hashed to distribute write traffic across splits, secondary index entries are ordered lexicographically by their indexed field values. When an index contains fields with sequential or monotonically increasing or decreasing values (such as timestamps or auto-incrementing IDs), every incoming index write targets the boundary of the index keyspace on a single split. Because sequential writes continuously advance to the newest split at the edge of the range, automatic load-based splitting cannot divide the write traffic across storage servers. Under high write rates, this concentration creates an append hotspot on that single split, resulting in elevated write latency, contention errors, and transaction aborts. Sharded indexes solve this write bottleneck by hash partitioning the secondary index keyspace. When `shard_count` is configured to N, Firestore automatically prepends a virtual computed shard field (with values from 0 to N-1) as the leading field of the index. This splits a single sequential key range into N independent key ranges, uniformly scattering adjacent writes across distinct splits and storage servers to enable linear write scaling. Query trade-offs: Hash partitioning trades query performance for write throughput. Because matching index entries are scattered across all shards, queries executing against a sharded index cannot read from a single contiguous range. The query engine must fan out parallel seeks across all N shards and merge the ordered results. Even index point lookups and queries with `LIMIT 1` must seek across all N shards. Sizing and best practices: - Indexes cannot be updated in-place. `shard_count` is immutable once an index is created; to \"reshard\" an index, create a new index with the desired `shard_count` and delete the original index. - Use sharded indexes only for indexes experiencing write bottlenecks (typically exceeding 500-1,000 writes/sec) on sequential or timestamp fields. - Do not shard indexes on uniformly distributed fields (such as UUIDs or hash tokens), where writes naturally spread across splits without sharding. Sharding uniform indexes adds query overhead without improving write throughput. - Do not shard read-heavy or low-write collections. - Size `shard_count` based on expected peak write throughput. Because a single split sustains roughly 500-1,000 writes/sec on sequential keys, estimate `shard_count ≈ ceil(peak_write_qps / 500)`. - e.g., 4 for up to ~2,000-4,000 writes/sec, 16 for up to ~10,000+ writes/sec. - Setting an excessively high shard count produces diminishing write returns while needlessly increasing read latency and seek costs. If <= 1, the index is unsharded (1 physical shard).","format":"int32","type":"integer ⟨778 unchanged words⟩