Cloud Spanner MCP server gives an agent programmatic reach into Google Cloud Spanner, a distributed relational database built to serve globally consistent SQL workloads at scale. Through Neotask, an agent can manage Spanner instances and databases, inspect and adjust schemas, and run data operations against the database directly. That spans both administrative work, creating a new database, resizing an instance's compute capacity, reviewing a schema before a migration, and operational data work such as running a query to check the result of a recent change. Because Spanner is often the backbone of a system that can't tolerate downtime, having an agent that can inspect current schema and instance configuration before proposing a change reduces the chance of a mistake reaching a live, globally distributed database. Instead of an engineer manually connecting to check table structure or instance sizing across regions, the agent handles that inspection and, once approved, the actual schema or configuration change, reporting back exactly what it applied.
| Create instance | Provision a new Spanner instance with a defined node or processing unit count and configuration. |
| Create database | Set up a new database within an existing Spanner instance, ready for its own schema. |
| Inspect schema | Retrieve the current table and index definitions for a database before proposing a change. |
| Apply schema change | Run a DDL statement to add or modify a table, column, or index. |
| Run query | Execute a SQL query against a Spanner database and return the results for review. |
| Resize instance | Adjust the compute capacity of an existing instance to meet current or projected load. |
Before adding a new column to a table used by several services, the team asks the agent to confirm nothing else depends on conflicting column names or index definitions that might collide with the change. The agent inspects the current schema, checks for existing indexes that might be affected, and cross-references the table against the services listed as consumers. It reports back that the change looks safe apart from one index that will need updating afterward. Once confirmed, it applies the schema change, updates the index, and runs a quick query to verify the new column is present and populated as expected across a sample of rows.
When query latency creeps up during a traffic spike, an engineer asks the agent to check whether the Spanner instance is under-provisioned for current load. The agent inspects the instance's current processing unit count, reviews recent query patterns to see whether the slowdown correlates with volume, and recommends a specific resize based on what it finds, along with the reasoning behind the number. After the team approves, it resizes the instance, confirms the change is reflected in the instance's configuration, and checks that latency has returned to expected levels over the following hour, noting the before-and-after numbers in case the same instance needs a similar review during the next seasonal traffic increase.
It can run schema changes when instructed to, but given how disruptive a bad DDL statement can be on a live distributed database, most teams have it inspect and propose changes before applying them for a second look.
This integration focuses on instance, database, and schema management along with running data operations. Backup and recovery may depend on additional Spanner capabilities beyond what's described here.
Yes, running SQL queries against a Spanner database is part of what it can do, subject to the same performance characteristics and query planning any client would experience.
Yes, Spanner itself is built for globally distributed SQL workloads, and the agent's instance and schema management applies at that same scale across regions.
The database itself will reject or fail an incompatible change the same way it would through any other client, so the agent's proposed change still has to pass Spanner's own validation before it takes effect.
It can report current capacity and load, which informs a resizing decision, though a full cost projection depends on how Spanner's pricing is being tracked separately by the team.
Yes, running queries that check row counts or table size over time, and comparing that against previous checks, is a reasonable way to catch unexpected growth before it turns into a capacity problem.