Written by: Mike DeAngelo, Developer Relations Engineer @ Google (LinkedIn)

As developers increasingly look to connect AI agents directly to enterprise data platforms like Looker, a significant challenge has emerged: how to handle secure, per-user authentication in a way that diverse MCP clients can understand.

For clients like Claude Desktop, which has more rigid configuration requirements than tools like the Gemini CLI, we needed a standardized way to communicate OAuth requirements. The answer lies in OAuth Protected Resource Metadata (PRM), a standard way to communicate authentication details.

The Challenge of Authentication Discovery

In a standard MCP setup, the client (your AI agent) needs to know how to contact the resource (Looker), initiate an OAuth PKCE flow, and obtain a valid token. MCP Toolbox acts as the bridge here, but the client needs a “map” to find the right authorization servers.

RFC 9728 defines a document called “OAuth Protected Resource Metadata” (PRM). The PRM file acts as that map. When a client doesn’t know how to authenticate, it makes a GET request to /.well-known/oauth-protected-resource. The server responds with a JSON document specifying the supported authorization servers and required scopes.

Setting Up Your PRM Configuration

To enable this in MCP Toolbox, you must first define your PRM file. This file tells the client exactly where to go to get its credentials.

1. Create your prm.json

Your configuration file should follow this structure, replacing the example URLs with your own service endpoints:

{
  "resource": "https://looker-mcp-toolbox.example.com/mcp",
  "authorization_servers": ["https://looker.example.com"],
  "scopes_supported": ["cors_api"]
}

2. Deploying MCPToolbox

When running MCP Toolbox, you use the --mcp-prm-file flag to point to this configuration. For a production-ready setup, particularly for Claude Desktop which requires HTTPS, deploying on a service like Google Cloud Run is ideal as it handles SSL termination automatically. If you are not using Google Cloud Run, set up some sort of reverse proxy to handle this and make sure MCP Toolbox is listening on the port expected by the reverse proxy.

Required Environment Variables:

• LOOKER_BASE_URL: Your Looker instance URL.
• LOOKER_USE_CLIENT_OAUTH: Set to true to enable per-user authentication.

Execution Command:

./toolbox - prebuilt=looker,looker-dev - mcp-prm-file=prm.json - port=8080 - address=0.0.0.0

Alternatively you can run MCP Toolbox without a reverse proxy by using the --tls-cert and --tls-key command line switches to point to the proper PEM encoded certificate and signing key files.

Registering the Client in Looker

Before Claude Desktop can connect, you must register it as an OAuth application within Looker. There is no interface to do this so we use Looker’s “API Explorer” to call the “Register OAuth App” endpoint with the following data:

• Client GUID: claude-desktop
• Redirect URI: https://claude.ai/api/mcp/auth_callback
• Display Name: “Claude Desktop”
• Description: “Claude Desktop”
• Enabled: true

You can set up other clients, Gemini CLI, ChatGPT, etc. by finding out what redirect URI they use and substituting that above with their own Client GUID. For example for Gemini CLI use the following:

• Client GUID: gemini-cli
• Redirect URI: http://localhost:7777/oauth/callback
• Display Name: “Gemini CLI”
• Description: “Gemini CLI”
• Enabled: true

Connecting Claude Desktop

Once your server is live and your PRM file is served at the .well-known path, adding the connector in Claude Desktop is straightforward. In the “Connectors” settings, choose “Add custom connector” and provide the URL of your reverse proxy with the /mcp path. In the advanced settings, simply enter claude-desktop as the OAuth Client ID.

Claude will then automatically detect the PRM metadata and initiate the PKCE authentication flow in your browser.

Connecting Gemini CLI

Add the following stanza to your $HOME/.gemini/settings.json file:

"mcpServers": {
    "looker": {
        "httpUrl": "https://<your mcp server url>/mcp",
        "oauth": {
            "clientId": "gemini-cli",
            "redirectUri": "http://localhost:7777/oauth/callback"
        }
    }
}

Start Gemini CLI and run /mcp auth looker. Gemini CLI will start the authentication flow in your browser.

Why This Matters

This approach allows organizations to maintain strict security standards — ensuring that the AI agent only accesses data the specific user is authorized to see — while providing a seamless “one-click” authentication experience for the end user. It bridges the gap between sophisticated data platforms like Looker and the new generation of agentic AI tools.

For more detailed implementation guides, visit the MCP Toolbox documentation. You can also explore additional ways to authorize connection to various databases at Securing AI agents with MCP Authorization.

Seamless AI-to-Data Integration: Using MCP Toolbox and PRM for Looker OAuth was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Written by: Wenxin Du, Software Engineer @ Google (Linkedin)

When connecting AI agents to enterprise databases, security is the greatest challenge. As agents graduate from sandbox environments into production, they inherit the strict data governance policies of the organization. Ensuring that an agent acts with the exact permissions of the end-user usually forces developers to build bespoke verification layers to intercept requests and inspect tokens.

The latest update to MCP Toolbox introduces generic Model Context Protocol (MCP) authorization support. This feature allows you to gate an entire MCP server or individual database tools behind standard OAuth2 Identity Providers without altering your agentic application logic.

By processing token verification at the configuration layer, Toolbox acts as an automated security perimeter. It validates incoming OAuth2 tokens against external authorization servers, ensuring that your agents strictly maintain the user’s chain of custody.

How It Works

Toolbox server intercepts incoming authorization headers when receiving a client request to its MCP endpoint. After extracting the OAuth2 token from the request header, Toolbox verifies its signature, checks the audience, and confirms that the required scopes are present. If the token is valid, the request proceeds smoothly; otherwise, Toolbox returns a “401 Unauthorized” for token verification failure or “403 Forbidden” error for missing scopes.

Step-by-Step Configuration

Setting up centralized authorization involves defining an identity provider in your configuration file and applying it to your tools.

Step 1: Configure the Identity Provider

You can configure Toolbox to validate tokens from your choice of identity provider. Below are configuration examples for both Google and Okta.

Option A: Setting Up Google OIDC Authorization (ID Token)

When the client is connecting using Google’s OIDC-compliant ID token, Toolbox will validate the token locally. You can configure the following to your authServices section:

kind: authServices
name: google-mcp-auth
type: generic
audience: ${YOUR_TOKEN_AUDIENCE}
authorizationServer: https://oauth2.googleapis.com/tokeninfo
mcpEnabled: true
scopesRequired:
  - openid
  - profile
  - email

The audience parameter must match the OAuth 2.0 Client ID generated in your Google Cloud Console. Enforcing mcpEnabled: true requires a valid Google token before listing or executing tools.

Option B: Setting Up Google Opaque Access Token Authorization

Alternatively, you can also use Google OAuth’s access token. Since access tokens are opaque, Toolbox needs to validate it against Google’s Token Info endpoint:

kind: authServices
name: google-auth
type: generic
audience: ${YOUR_TOKEN_AUDIENCE}
authorizationServer: https://accounts.google.com
introspectionEndpoint: https://www.googleapis.com/oauth2/v3/tokeninfo
introspectionMethod: GET
introspectionParamName: access_token
mcpEnabled: true

Option C: Setting Up Okta Authorization

For architectures relying on other authorization servers like Okta, you can route token verification through an Okta Custom Authorization Server using this configuration:

kind: authServices
name: okta-auth
type: generic
audience: ${YOUR_TOKEN_AUDIENCE}
authorizationServer: https://your-subdomain.okta.com/oauth2/default
mcpEnabled: true
scopesRequired:
  - openid
  - profile

Toolbox automatically discovered the authorization and token introspection endpoints from the `authorizationServer` URL configured. If the authorization server does not use a standard introspection endpoint, you can manually configure the introspection endpoint like the example above in Option B.

Step 2: Enforce Fine-Grained Tool-Level Scopes

Once your authorization service is active, you can also choose to enforce granular tool-level authorization. By adding the scopesRequired block directly to an individual tool configuration, Toolbox ensures the client’s token contains the specific permissions needed for that exact action.

kind: tool
name: update_flight_status
type: postgres-sql
source: my-pg-instance
statement: |
  UPDATE flights SET status = $1 WHERE flight_number = $2
description: Update flight status
authRequired:
  - okta-auth
scopesRequired:
  - execute:sql
  - write:flights

If an agent attempts to execute a tool without the correct privileges, Toolbox safely rejects the request with a structured HTTP “403 Forbidden” response and a challenge identifying the missing permissions.

Conclusion

With native MCP authorization support, Toolbox eliminates the need to build custom security frameworks for your AI applications. It allows you to enforce zero-trust security standards across your enterprise data tools while keeping your focus on building more capable, context-aware agents.

For more information on setting up token verification patterns, check out our Authentication Documentation. For more information on secure integrations with platforms like Looker, see Seamless AI-to-Data Integration: Using MCP Toolbox and PRM for Looker OAuth.

Securing AI agents with MCP Authorization was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Written by:

• Anushka Saxena, Software Engineer Apprentice @ Google (LinkedIn)
• Anubhav Dhawan, Software Engineer @ Google (LinkedIn)

Building multi-step AI agents is a significant milestone, but the path to a production-ready application requires a fundamental shift from informal “vibe checks” to rigorous, automated evaluation. In this post, we share our journey scaling the reliability of the Cymbal Air customer service assistant, an open-source demo designed to handle flight bookings and complex policy queries. By moving beyond manual spot-checks, we established a robust framework to evaluate how our agent reasons through complex, multi-step tasks.

To achieve this reliability, we transitioned our orchestration from LangChain to LangGraph, integrated with MCP Toolbox for unified database connectivity and the Vertex AI Gen AI Evaluation Service. This combination allows us to manage workflows as state machines and track the entire trajectory of an agent’s decision-making process, ensuring consistent and high-quality customer support.

The Architectural Shift

Our early iterations relied on traditional linear chains, which proved insufficient as Cymbal Air grew to handle conditional logic, loops, and human-in-the-loop confirmations. We needed a system that could manage persistent conversation state and cycles, leading us to migrate to LangGraph. By treating the agent’s logic as a state machine rather than a simple sequence, we gained the visibility and control necessary to bridge the gap between simple chat interactions and complex, multi-step tool orchestration.

Using LangGraph state management, we could persist and inspect intermediate execution state throughout the conversation, including:

• message history
• tool calls
• tool outputs
• and transitions between workflow nodes

This persistent workflow state became foundational for building more reliable evaluations, allowing us to inspect intermediate tool interactions rather than relying only on final responses.

Defining a comprehensive evaluation strategy

To move beyond “vibe checks,” we defined three specific pillars for our automated evals (the systematic process of testing AI performance):

• Response Quality: Evaluating whether the final response was helpful, accurate, and grounded in retrieved information.
• Tool Use: Verifying if the agent calls the right tools with the correct parameters.
• Tool Trajectory: Evaluating whether the predicted sequence of tool calls matches the expected execution flow for multi-step tasks. This became particularly important for workflows involving dependent tool calls, where a correct final response alone did not guarantee correct intermediate execution behavior.

Note: What is a Vibe Check? Informal, manual testing where a developer reads a few answers to see if they “feel” right. Automated evals replace vibe checks by testing hundreds of scenarios programmatically using predefined datasets (like eval_golden.py).

Outcomes from the new evaluation workflow

After migrating the evaluation pipeline to LangGraph and expanding evaluation coverage beyond final-response scoring, we were able to evaluate agent behavior at a much deeper level.

The updated workflow gave us:

• Better visibility into intermediate agent behavior
• More reliable evaluation of tool-augmented responses
• Improved validation of parameter extraction
• The ability to evaluate multi-step tool trajectories rather than only final outputs

In practice, this helped surface issues that were previously difficult to detect in the earlier evaluation setup, particularly around:

• Incorrect parameter extraction
• Invoking redundant tools
• Missing tool context during response evaluation
• Executing tool sequences in the wrong order in multi-tool workflows

Overall, the updated evaluation workflow became significantly more effective for debugging orchestration failures and validating multi-step execution behavior.

Lessons learned while improving evals

Handling “no tool required” cases

Generic queries like: “What is Cymbal Air?” correctly required no tool calls. Earlier evaluation flows treated empty trajectories as failures, which incorrectly penalized valid responses. Adding explicit handling for “no action required” cases improved retrieval evaluation reliability.

Detecting incomplete workflows

For the query: “Where can I get a snack near the gate for flight CY 352?”, the expected workflow required:

1. Retrieving the flight gate
2. Then searching nearby amenities

Trajectory evaluation revealed that the agent completed only the first step and skipped the amenities lookup entirely. This was a failure that response-only evaluation would have missed.

Identifying redundant tool calls

For the query: “What are some flights from SFO to Chicago tomorrow?”, the expected trajectory involved resolving the airport followed by a single flight search. The evaluation surfaced an unnecessary additional flight lookup, reducing trajectory precision despite partially correct retrieval behavior.

LangGraph provided the structured execution state needed to capture intermediate tool interactions, while the Vertex AI Gen AI Evaluation Service enabled us to systematically evaluate response quality, tool usage, and multi-step trajectories against expected workflows.

Get started

Ready to build and evaluate your own robust, stateful agents?

• Explore MCP Toolbox for Databases to build agent workflows with standardized and secure database tool integrations.
• Explore the full implementation and evaluation datasets in the Cymbal Air repo.
• Dive into the Vertex AI Gen AI Evaluation Service documentation.
• Master stateful multi-agent coordination with the LangGraph docs.

Beyond the Vibe Check: Scaling Cymbal Air Agent Reliability with LangGraph and Vertex AI Evals was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Written by: Twisha Bansal, Software Engineer @ Google (Linkedin)

There’s a scene every data engineer knows by heart.

It’s 2 PM. You’re deep in flow, building something real. And then — you need to check something in the database. Just a quick thing. How many orders came in this week? Is that index still broken? What does the schema look like on that table?

So you stop. You open a new terminal. You look up the gcloud flag you can never remember. You run the command, parse the output, copy a value, open the SQL client, write the query, check the docs because you always forget the exact syntax for EXPLAIN ANALYZE, get the answer, close everything, and try to remember where you were.

Fifteen minutes gone. For a quick thing.

We think that’s long enough. Today, we’re done with it.

Announcing: Agent Skills for Google Cloud Data Products

What if your AI coding agent already knew your database? not just what SQL is, but what your instances look like, how to provision them, how to read their health metrics, how to troubleshoot their slowest queries, and you could just ask.

That’s what we built.

Starting today, agent skills are available for 12 Google Cloud Data Products, across every major AI coding agent: Gemini CLI, Claude Code, Codex, and Antigravity. These aren’t thin wrappers or glorified autocomplete. They’re deep, domain-specific capability packs that give your agent genuine expertise, the kind that used to live only in the heads of the most experienced people on your team.

One sentence. Any product. Any agent. Just ask.

Twelve Products: One Language

The launch covers the full breadth of what engineering teams run in production on Google Cloud:

Relational Databases

• Cloud SQL for PostgreSQL
• Cloud SQL for MySQL
• Cloud SQL for SQL Server
• AlloyDB for PostgreSQL
• AlloyDB Omni
• Spanner
• Oracle Database

Analytics & Big Data

• BigQuery
• Dataproc

NoSQL

• Firestore

Intelligence & Governance

• Knowledge Catalog
• Looker

Whether you’re querying a transactional database at the edge of the world or orchestrating a petabyte-scale analytics pipeline, your agent is now fluent in it.

What Fluent Actually Looks Like

Forget bullet points for a moment. Here’s what a morning looks like when your agent speaks database:

You notice query latency has spiked overnight.

Which queries are causing the most load right now? Show me their execution plans and flag anything suspicious.

The agent identifies three slow queries, shows the plans, and recommends missing indexes. You ask it to check if those indexes already exist somewhere.

Are there any invalid indexes I should know about on this instance?

Clean. You spin up a new environment to test the fix.

Clone this instance into a staging environment in us-west1.

Done while you pour coffee. You come back, test the fix, and ask for a code artifact to carry it forward.

Generate a Python migration script to add those indexes to the ‘orders’ table.

That used to be an afternoon. It was a conversation.

Skills Go Deep, Not Wide

Each skill pack isn’t trying to do everything. It’s trying to do one product exceptionally well.

Take Cloud SQL for PostgreSQL as an example. Seven distinct skill modules ship in the release:

• Admin: Provision instances, create users, clone environments, and monitor long-running operations.
• Data: Explore schemas, discover stored procedures and views, execute SQL.
• Health: Identify bloat, find invalid indexes, audit autovacuum configuration.
• Lifecycle: Backups, restores, version upgrade compatibility checks.
• Monitor: Performance bottleneck analysis, query execution plans, PromQL metrics
• Replication: Replication health, sync states, role and security auditing
• View Config: Extension management, memory and engine-level tuning.

That’s the pattern across every product in this launch. Breadth comes from covering 12 products. Depth comes from knowing each one properly.

Four Agents, Zero Lock-in

The same skills work across all four major AI coding agents. Pick yours:

Gemini CLI

One command to install, zero friction to configure. The extension discovery system handles the rest.

gemini extensions install https://github.com/gemini-cli-extensions/cloud-sql-postgresql

Claude Code

Native plugin architecture. Add the marketplace, install the plugin, and your database is ready to talk inside the same session you’re already in.

/plugin marketplace add https://github.com/gemini-cli-extensions/cloud-sql-postgresql.git#0.4.0
/plugin install cloud-sql-postgresql@cloud-sql-postgresql-marketplace

Codex

Clone the repo, drop it into ~/.codex/plugins/, wire it into a marketplace.json, and it appears in your plugin menu like it was always there.

Antigravity

Copy skill folders into your global or workspace-scoped skills directory. Antigravity finds them automatically at session start, no configuration required.

Use whichever agent fits how you work. The skills are yours regardless.

For detailed instructions, check out the README.

Still Early: In the Best Way

These skills are in beta. Pre-v1.0, which means two things: some interfaces will evolve before the stable release, and your feedback right now has an outsized impact on what ships.

This is the moment to tell us what’s missing, what’s confusing, and what you wish the agent could do that it can’t yet. We built a feedback form and we’re actually reading it.

More products, more agents, and deeper integrations are already in progress.

The Part That Actually Matters

The goal here isn’t to replace expertise. Senior engineers will still know things agents don’t. Judgment still lives in humans.

But the tax on expertise, the context switches, the doc lookups, the command-line archaeology, the fifteen-minute interruptions to your flow, that’s pure friction. It slows everyone down: the senior engineer who knows exactly what they want but has to look up the flag anyway, and the junior engineer who knows what they want but doesn’t know the right question to ask yet.

Agent skills eliminate that tax. The knowledge is still yours. The friction is gone.

Twelve products. Four agents. One language: yours.

Get started at github.com/gemini-cli-extensions.

Your Databases Finally Speak Human was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cross-Cloud AI Agents: Multi-Source Reasoning with CockroachDB and Google Cloud Databases Using MCP Toolbox

Written by:

• Virag Tripathi, Principal Partner Solutions Architect @ Cockroach Labs (LinkedIn)
• Averi Kitsch, Staff Software Engineer @ Google (LinkedIn)

The Problem: AI Agents Are Trapped in Single-Database Silos

AI agents are reshaping how applications interact with data. They don’t just answer questions — they reason, plan, and act. But here’s the catch: most agent implementations today connect to a single data source. In the real world, enterprise data doesn’t live in one place. Your transactional records might sit in CockroachDB spanning regions across AWS and Azure, your analytics live in BigQuery, and your session metadata resides in a Cloud SQL for PostgreSQL instance on Google Cloud.

When an agent needs to answer a question like “Which of our top-spending customers in EMEA had support tickets last quarter, and how do their order patterns compare to APAC?” — it needs to reason across multiple databases, potentially across multiple clouds.

This is the cross-cloud, multi-source reasoning challenge. And it’s exactly what the new CockroachDB integration for MCP Toolbox for Databases was built to solve.

The Solution: MCP Toolbox for Databases

Think of MCP Toolbox for Databases as a unified control plane that finally makes multi-source data management simple. It is an open-source MCP server from Google that sits right between your AI agent and your databases, solving the headache of cross-source complexity.

Instead of getting tangled up in custom “glue code” for every single integration, you just define your sources and tools in one simple configuration file. A single MCP server instance then exposes all these diverse data sources — whether they are in different clouds or use different engines — through one consistent, unified endpoint.

Right now, it supports over 40 data sources, including favorites like AlloyDB, Spanner, BigQuery, and — most recently — CockroachDB. It handles the heavy lifting like connection pooling and authentication automatically, so your agent can focus on reasoning across your entire data landscape without the friction. Learn more about the cloud native features of CockroachDB.

The CockroachDB Integration

A new CockroachDB source type was added to MCP Toolbox (v0.27.0+), backed by the official cockroach-go/v2 library. It supports:

• Standard username/password authentication
• SSL/TLS configuration (required for CockroachDB Cloud)
• Configurable connection retries with exponential backoff
• Query timeouts and row limits for safety
• Read-only mode enforcement for MCP best practices

The integration includes generic and custom tools to facilitate both exploratory tasks and highly deterministic workflows. The initial integration includes four primary tools:

• cockroachdb-sql: Execute SQL queries as prepared statements
• cockroachdb-execute-sql: Run parameterized SQL statements
• cockroachdb-list-tables: List all tables in a database
• cockroachdb-list-schemas: List schemas in a database

These tools give an AI agent everything it needs to explore, query, and interact with a CockroachDB database — from schema discovery to complex analytical queries.

Tutorial: Building a Cross-Cloud Agent with CockroachDB and Cloud SQL

Now for the exciting part. Let’s build an AI agent that reasons across two databases:

1. CockroachDB (running on CockroachDB Cloud, spanning AWS regions) — holding global order and customer data
2. Cloud SQL for PostgreSQL (on Google Cloud) — holding product catalog and inventory data

The agent will answer questions that require joining insights from both sources — something no single-database agent can do.

Step 1: Configure MCP Toolbox

Create a tools.yaml that defines both data sources and the tools for each:

# === Sources ===
kind: source
name: cockroachdb_orders
type: cockroachdb
host: my-cluster.aws-us-east-1.cockroachlabs.cloud
port: "26257"
user: agent_readonly
password: ${COCKROACHDB_PASSWORD}
database: orders_db
queryParams:
  sslmode: require
  application_name: mcp-toolbox-agent
readOnlyMode: true          # Recommended MCP security setting
enableWriteMode: false      # Recommended MCP security setting
maxRowLimit: 1000           # Recommended MCP security setting
queryTimeoutSec: 30         # Recommended MCP security setting

---
kind: source
name: cloudsql_products
type: cloud-sql-postgres
project: my-gcp-project
region: us-central1
instance: product-catalog
database: products_db
user: agent_readonly
password: ${CLOUDSQL_PASSWORD}

# === CockroachDB Tools (Global Orders) ===
---
kind: tool
name: get_top_customers
type: cockroachdb-sql
source: cockroachdb_orders
description: >
  Get the top N customers by total order value in a given region.
  Returns customer_id, name, email, region, and total_spent.
statement: |
  SELECT c.id, c.name, c.email, c.region,
         SUM(o.total) AS total_spent
  FROM customers c
  JOIN orders o ON c.id = o.customer_id
  WHERE c.region = $1
  GROUP BY c.id, c.name, c.email, c.region
  ORDER BY total_spent DESC
  LIMIT $2
parameters:
  - name: region
    type: string
    description: Customer region (e.g., 'EMEA', 'APAC', 'NA')
  - name: limit
    type: integer
    description: Number of top customers to return

---
kind: tool
name: get_customer_orders
type: cockroachdb-sql
source: cockroachdb_orders
description: >
  Get recent orders for a specific customer, including order items.
statement: |
  SELECT o.id AS order_id, o.created_at, o.total, o.status,
         oi.product_id, oi.quantity, oi.unit_price
  FROM orders o
  JOIN order_items oi ON o.id = oi.order_id
  WHERE o.customer_id = $1
  ORDER BY o.created_at DESC
  LIMIT 50
parameters:
  - name: customer_id
    type: string
    description: The customer's UUID

---
kind: tool
name: get_order_trends
type: cockroachdb-sql
source: cockroachdb_orders
description: >
  Get monthly order trends for a region over the past 12 months.
statement: |
  SELECT DATE_TRUNC('month', o.created_at) AS month,
         COUNT(*) AS order_count,
         SUM(o.total) AS revenue
  FROM orders o
  JOIN customers c ON o.customer_id = c.id
  WHERE c.region = $1
    AND o.created_at > NOW() - INTERVAL '12 months'
  GROUP BY month
  ORDER BY month
parameters:
  - name: region
    type: string
    description: Region to analyze

# === Cloud SQL Tools (Product Catalog) ===
---
kind: tool
name: get_product_details
type: postgres-sql
source: cloudsql_products
description: >
  Get product details including name, category, price, and stock level.
statement: |
  SELECT p.id, p.name, p.category, p.price,
         i.stock_level, i.warehouse_location
  FROM products p
  JOIN inventory i ON p.id = i.product_id
  WHERE p.id = ANY($1::uuid[])
parameters:
  - name: product_ids
    type: string
    description: Comma-separated list of product UUIDs

---
kind: tool
name: search_products
type: postgres-sql
source: cloudsql_products
description: >
  Search products by name or category.
statement: |
  SELECT id, name, category, price
  FROM products
  WHERE name ILIKE '%' || $1 || '%'
     OR category ILIKE '%' || $1 || '%'
  LIMIT 20
parameters:
  - name: query
    type: string
    description: Search term for product name or category

---
kind: tool
name: get_low_stock_products
type: postgres-sql
source: cloudsql_products
description: >
  Get products with stock levels below a given threshold.
statement: |
  SELECT p.id, p.name, p.category, i.stock_level,
         i.warehouse_location
  FROM products p
  JOIN inventory i ON p.id = i.product_id
  WHERE i.stock_level < $1
  ORDER BY i.stock_level ASC
parameters:
  - name: threshold
    type: integer
    description: Stock level threshold

Step 2: Start MCP Toolbox

Download and run MCP Toolbox. You can find all methods for installing MCP Toolbox at Install Toolbox.

# Download the MCP Toolbox binary for Linux
curl -O https://storage.googleapis.com/genai-toolbox/v1.1.0/linux/amd64/toolbox
chmod +x toolbox
# Start the MCP Toolbox server
./toolbox --tools-file tools.yaml

MCP Toolbox is now serving both CockroachDB and Cloud SQL tools from a single MCP endpoint at http://localhost:5000/mcp.

Step 3: Build the Agent with Google ADK — Python

Let’s leverage the Google Agent Developer Kit (ADK) to construct an AI agent capable of orchestrating these cross-cloud tools.

from google.adk.agents import Agent
from toolbox_core import ToolboxClient

# Connect to MCP Toolbox
toolbox = ToolboxClient("http://localhost:5000")
tools = toolbox.load_toolset()

# Create an agent with access to all cross-cloud tools
agent = Agent(
    model="gemini-2.0-flash",
    name="cross_cloud_analyst",
    instruction="""You are a business analyst agent with access to two databases:

    1. CockroachDB (global orders): Customer data, orders, and revenue
       across EMEA, APAC, and NA regions.
    2. Cloud SQL (product catalog): Product details, categories, pricing,
       and inventory levels.

    When answering questions, reason across both data sources. For example,
    if asked about top customers, first query CockroachDB for order data,
    then look up the products they purchased from Cloud SQL to provide
    complete context.

    Always explain your reasoning and which data sources you used.""",
    tools=tools,
)

Step 4: Ask Cross-Cloud Questions

Now the agent can answer questions that span both databases:

“Who are our top 5 EMEA customers, what products are they buying, and are any of those products running low on stock?”

The agent will:

1. Query CockroachDB (get-top-customers) to find the top 5 EMEA customers by spend.
2. Query CockroachDB (get-customer-orders) to get their recent order items and product IDs.
3. Query Cloud SQL (get-product-details) to enrich with product names and categories.
4. Query Cloud SQL (get-low-stock-products) to check inventory status.
5. Synthesize a unified answer with actionable insights.

All of this happens through a single MCP Toolbox instance — no custom glue code, no bespoke API connectors, no data pipeline to maintain.

Why This Matters: The Cross-Cloud Data Future

Enterprise data is inherently distributed. Not just across tables or schemas, but across clouds, regions, and database engines — each chosen for a specific strength.

Data sources, such as globally distributed transactional databases like CockroachDB, and Google Cloud databases (e.g., Cloud SQL, AlloyDB, Spanner, and BigQuery), each serve distinct roles — from managed relational workloads to petabyte-scale analytics.

MCP Toolbox bridges them. By exposing all of these databases as tools through a single MCP server, you create an agent that sees the full picture. It can correlate transactional data in CockroachDB with analytics in BigQuery, match orders against inventory in Cloud SQL, or compare CockroachDB-hosted financial records with Spanner-hosted compliance data.

This is the cross-cloud data source pattern: let your agent be the integration layer, not your application code.

Getting Started

• Explore the Code: Dive into the MCP Toolbox GitHub repository and check out the latest documentation to see how the ecosystem is evolving.
• Get Started: Sign up for CockroachDB Cloud
• Master the Configuration: Consult the CockroachDB Reference Docs for deep dives into cluster setup, performance tuning, and advanced configuration parameters.
• Choose Your Language: Build your way with MCP Toolbox SDKs, featuring robust support and native libraries for Python, Go, JavaScript, and Java
• Connect with Peers: Join the conversation in the MCP Toolbox Discord or the CockroachDB Community Forum to troubleshoot issues, share ideas, and stay updated.

What’s Next

The CockroachDB integration is just the beginning. We’re exploring additional tools — schema introspection, index recommendations, query performance diagnostics — and deeper patterns around multi-source agentic workflows. If you build something with CockroachDB and MCP Toolbox, we’d love to hear about it.

The future of AI agents isn’t about connecting to a database. It’s about connecting to all of them — across clouds, across regions, across engines — and letting the agent reason over the full breadth of your data.

About the Authors

Virag Tripathi is a Principal Solutions Architect at Cockroach Labs, where he works at the intersection of distributed systems, cloud partnerships, and AI-native data architectures. He contributed the CockroachDB integration to Google’s MCP Toolbox for Databases.

Averi Kitsch is a Staff Software Engineer at Google, leading the MCP Toolbox for Databases project.

MCP Toolbox v1.0:
The Open-Source Framework for Secure Agentic Data Access

Written by:

• Kurtis Van Gent, Senior Staff Software Engineer @ Google (Linkedin)
• Averi Kitsch, Staff Software Engineer @ Google (Linkedin)

Building reliable AI agents requires a strict separation between reasoning logic and system execution. Large language models (LLMs) can plan and process information effectively, but their utility in production environments depends entirely on a secure, standardized way to interact with enterprise data.

This is the core problem solved by the Model Context Protocol (MCP). Acting as a universal interface between AI models and external tools, MCP allows developers to connect agents to real-world systems without building bespoke integrations for every new model. The importance of this standard was underscored recently when MCP joined the Agentic AI Foundation (AAIF) under the Linux Foundation, marking a shift toward interoperable agentic infrastructure.

Today, we are announcing that the open-source MCP Toolbox for Databases has reached version 1.0.

Built in the open and hardened by real-world developer feedback, this framework connects your AI agents directly to over 40 enterprise data sources. With the 1.0 release, the Toolbox provides a stable, backwards-compatible foundation for building agentic applications, giving you the strict control and customization required for true production workloads.

What’s New in v1.0: Built for Production Workloads

When we announced the public Beta for MCP Toolbox for Databases just over a year ago, the goal was straightforward: provide a reliable bridge between language models and enterprise data. Since then, the project has evolved into a multi-database MCP framework for customizable tools. The v1.0 release means the Toolbox has reached a stable, backwards-compatible foundation suitable for production workloads.

Here is what is new and hardened in this release:

• Expanded Ecosystem (40+ Data Sources): Driven by community contributions, Toolbox 1.0 now supports over 40 data sources. This includes native connectivity for Google Cloud databases like AlloyDB, Spanner, BigQuery, and Cloud SQL, alongside third-party systems including Oracle, MongoDB, Snowflake, and open-source PostgreSQL.
• Client SDKs & Framework Integrations: Developers can integrate Toolbox natively using our Python, Go, and TypeScript/JavaScript SDKs, and most recently, our Java SDK to cover the most common enterprise backend environments. We’ve also built deeper integrations into popular frameworks, allowing you to connect Toolbox directly to LangChain, LlamaIndex, and the Agent Development Kit (ADK) with minimal boilerplate.
• End-to-End Telemetry: Production environments require observability. Toolbox 1.0 includes built-in OpenTelemetry support adhering to the official MCP semantic conventions. This ensures every agent-to-database interaction is traceable with standardized metrics and logs.
• Skills Autogeneration: This release introduces “Skills,” a modular way to package and reuse operational tasks (like database troubleshooting). The Toolbox can autogenerate Skills, instantly turning any toolset you build into a package of scripts and resources ready to be deployed.
• MCP Authorization Support: Toolbox 1.0 implements MCP’s latest spec for Authorization, functioning as a fully compliant OAuth 2.1 resource server. This provides a standardized way to protect sensitive tools and data through automated discovery and rigorous token validation.

Bridging the Trust Gap with Custom Tools

The open-source MCP Toolbox is designed for developers building custom agentic applications who require full control over system execution. When you deploy the Toolbox — whether locally, in a container, or via services like Cloud Run — you are prioritizing deep customization.

The Toolbox lets you explicitly define which tools are exposed to the agent. You can tightly modify almost everything — including resources the tool can access, descriptions to improve the language model’s prompt routing, or construct highly customized, bounded tools that execute exact, pre-approved business logic against your specific data schemas.

Consider a customer support chatbot. To allow a user to look up their order status, you wouldn’t just hand the language model your raw database connection strings and unfiltered access to your database. Doing so creates a massive “trust gap” between a probabilistic model and your strict, deterministic production database. It opens the door to unoptimized queries, hallucinated table names, and severe security risks.

MCP Toolbox provides a framework for developers to bridge this gap. Instead of granting an agent unrestricted schema access, you use a declarative configuration file to define specific, safe actions.

This framework allows you to wrap complex business logic into fixed SQL queries with precise parameter bindings. The Toolbox acts as a protective gateway — validating inputs and ensuring the agent can only execute the exact logic you’ve pre-approved. This approach keeps the agent flexible during user conversations while keeping your data layer completely locked down.

Practical Example: Secure Tool Definition

Let’s look at a practical example. Consider a multi-tenant SaaS application where users can ask an AI agent to analyze their recent API usage.

The agent needs to fetch usage logs, but you must ensure strict tenant isolation. You absolutely cannot grant the language model generic read access and trust it to filter by the correct tenant ID. With MCP Toolbox, you define the allowed action and its strict boundaries in a config.yaml file:

kind: tool
name: get_tenant_usage
type: postgres-sql
source: postgres-prod
description: "Retrieve API usage statistics for the current billing period."
parameters:
  - name: limit
    type: integer
    default: 10
    maxValue: 50
  - name: tenant_id  # Bound at runtime, not agent-controlled!
    type: string
statement: |
  SELECT endpoint, request_count, error_rate, last_accessed
  FROM api_usage_logs
  WHERE tenant_id = $2
  ORDER BY request_count DESC
  LIMIT $1;

In this configuration, the query structure is entirely fixed. The limit parameter is capped at a maximum value to prevent massive data pulls, and tenant_id is defined as a required parameter.

When you initialize the Toolbox in your backend application using one of our SDKs (like Python), you bind this sensitive parameter server-side so it remains completely outside of the language model’s control:

from toolbox_core import ToolboxClient

# Initialize the client and bind the strict tenant isolation parameter
async with ToolboxClient("http://127.0.0.1:5000") as client:
    tools = await client.load_toolset(
        "tenant_analytics",
        bound_params={
            # This is securely injected by your backend auth layer, not the LLM
            "tenant_id": "org_7b89fA21", 
        }
    )
    
# 'tools' are now securely bounded and ready to be passed to your agent framework

This setup ensures the agent remains flexible during user interactions, while your database layer is securely locked behind deterministic execution.

Conclusion & Next Steps

The v1.0 release of MCP Toolbox is a sign of our stability, and the confidence developers can feel in building their applications on top of it. Engineering teams can now build and deploy secure agentic applications without the risk of upstream breaking changes.

Ready to get started?

• Explore the Code: Star and fork the MCP Toolbox repository on GitHub to see how it works under the hood and explore the growing ecosystem of community-contributed tools.
• Read the Docs: Visit mcp-toolbox.dev for quickstarts, SDK references, and advanced configuration guides.
• Join the Community: Join our Community Discord, file an issue or feature request, or send us a PR.

See us at Google Cloud Next 2026: If you are heading to Las Vegas, don’t miss the session Power Intelligent Agents with AI-Native Databases. Join MCP co-creator David Soria Parra (Anthropic) alongside Amit Ganesh and Yannis Papakonstantinou (Google) to hear what’s next for MCP and how AI-native databases are shaping the future of agentic infrastructure.

MCP Toolbox v1.0:  The Open-Source Framework for Secure Agentic Data Access was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Written by:

• Parth Ajmers & Shubham Palriwala, Agnost AI, Founders
• Yuan Teoh, Google, Software Engineer

Production deployments of MCP servers can sometimes encounter performance challenges, often leaving developers unsure if the cause is the network, a server-side problem, or the database query. Today’s update introduces a solution that significantly simplifies identifying these performance bottlenecks.

In collaboration with Agnost AI, we have integrated comprehensive observability features into MCP Toolbox for Databases. This includes distributed tracing for STDIO, SSE, and HTTP transports, along with latency histograms for both the server and client SDKs. We have also included an UpDown Counter to track active_sessions at any instant. Toolbox has supported OpenTelemetry since its inception; however, we are pleased to announce that we now adhere to the OpenTelemetry MCP Semantic Conventions.

Streamlining Diagnosis for Developers

Consider Alex, a developer who receives an alert for high p95 latency for their Toolbox agent. Previously, Alex would have spent hours manually correlating logs from various systems. Now, end-to-end distributed tracing provides a single, unified view of the slow request.

By evaluating client-side latency (mcp.client.operation.duration) against the server-side span, Alex can quickly eliminate network transit as the cause. Furthermore, the custom toolbox.tool.execution.duration metric isolates raw database processing time, confirming if the bottleneck lies within the query itself. This full-stack visibility shifts the debugging process from tedious “log archaeology” to efficient performance diagnosis.

With comprehensive telemetry features integrated, the operational overhead of managing MCP-based agents is significantly reduced. Developers can leverage high-level metric queries and deep-dive trace lookups to answer critical questions about system health and performance:

• Real-time Capacity & Infrastructure Tracking: Utilize the toolbox.server.mcp.active_sessions gauge to monitor the current count of active sessions. This data can be categorized by transport protocols (SSE or STDIO) to identify saturation points or detect potential session leaks in the system.
• Performance Benchmarking: Analyze how p95 latency varies across different MCP methods (initialize, tools/list, tools/call) using mcp.server.operation.duration. This allows for precise performance comparison between various transports and operations.
• Tool Usage & Hotspots: Identify which specific tools (e.g., execute_sql) are experiencing the highest invocation rates and monitor their specific error rates and primary failure types (such as internal_error or invalid_params) using the gen_ai.tool.name and error.type attributes.
• Root Cause Isolation: When a request fails, determine if the failure originated at the server, within the network, or on the client side. Distributed traces provide a breakdown of latency, distinguishing between raw database execution time (via toolbox.tool.execution.duration), protocol overhead, and network transit.
• Protocol & Compliance Monitoring: Track clients protocol versions using the mcp.protocol.version attribute, ensuring your fleet stays updated with the latest MCP standards
• End-to-End Visibility: Visualize the full call chain for any specific failure. By comparing client-perceived latency (mcp.client.operation.duration) against server-perceived latency, you can pinpoint exactly where delays are introduced in the end-to-end request lifecycle.

Activating Telemetry within Toolbox

Standard server-side configuration applies. To run Toolbox, simply include either the --telemetry-otlp or --telemetry-gcp flag:

./toolbox - telemetry-otlp="https://your-otel-collector:4318"
# Alternatively, utilize GCP Cloud Trace/Monitoring
./toolbox - telemetry-gcp

For SDK integration:

1. Ensure toolbox-core is installed with the telemetry feature enabled:

pip install toolbox-core[telemetry]

2. Configure your ToolboxClient by providing the telemetry endpoint URL:

from toolbox_core import ToolboxClient

client = ToolboxClient(
    url="http://localhost:5000",
    telemetry_url="https://your-otel-collector:4318"
)

Metrics and spans are generated automatically for initialize, tools/list, and tools/call. The SDK manages span creation and traceparent injection. These can be used with any OTLP-compatible backend or integrated directly into Google Cloud Monitoring and Agnost AI for native MCP dashboards.

Seamless SDK-to-Server Connectivity

Great news for users of the Toolbox SDKs: integration is now completely automatic! The Python SDK streamlines the process by activating the client span and injecting the traceparent before any MCP request is dispatched:

# Automatic when telemetry_url is set - no manual instrumentation needed
meta = MCPMeta(traceparent="00-4bf92f...", tracestate="")
params = CallToolRequestParams(name="execute_sql", arguments={...}, field_meta=meta)

On the server side, Toolbox automatically identifies the traceparent within params._meta to establish the server span. This pre-configured synchronization removes the need for manual context passing or modifications to your agent code.

End-to-End Visibility: Unified Spans and Derived Metric

Spans

By updating Toolbox spans to align with the OpenTelemetry MCP semantic convention, we have fully re-engineered our generated spans.

Enabling telemetry during a tools/call now produces a distributed trace that maps the entire path from the client request down to the database. Here are example spans for all various procedures across transport types:

STDIO Initialize

initialize (CLIENT, trace=t1, span=s1) # FROM MCP Client
|
--- toolbox/server/mcp/stdio (SERVER, trace=t1, span=s2, parent=s1) # IN TOOLBOX
    |
    --- initialize (SERVER, trace=t1, span=s3, parent=s2) # IN TOOLBOX

STDIO Tool Call

tools/call get-weather (CLIENT, trace=t1, span=s1) # FROM MCP Client
|
--- toolbox/server/mcp/stdio (SERVER, trace=t1, span=s2, parent=s1) # IN TOOLBOX
    |
    --- tools/call get-weather (SERVER, trace=t1, span=s3, parent=s2) # IN TOOLBOX

SSE Connection

connection (CLIENT, trace=t1, span=s2, parent=s1) # FROM MCP Client
|
--- toolbox/server/mcp/sse (SERVER, trace=t1, span=s3, parent=s2) # IN TOOLBOX

HTTP Initialize

initialize (CLIENT, trace=t1, span=s1) # FROM MCP Client
|
--- toolbox/server/mcp/http (SERVER, trace=t1, span=s2, parent=s1) # IN TOOLBOX
    |
    --- initialize (SERVER, trace=t1, span=s3, parent=s2) # IN TOOLBOX

HTTP Tool Call

tools/call get-weather (CLIENT, trace=t1, span=s1) # FROM MCP Client
|
--- toolbox/server/mcp/http (SERVER, trace=t1, span=s2, parent=s1) # IN TOOLBOX
    |
    --- tools/call get-weather (SERVER, trace=t1, span=s3, parent=s2) # IN TOOLBOX

Through the injection of a W3C traceparent into the MCP request’s params._meta field, server and client spans are now fully integrated, with the server span acting as a child of the client span. This architecture enables the collection of client latency, server latency, and raw database processing time as distinct, correlated signals within a single, unified trace.

The primary advantage of these telemetry traces in the Toolbox is the delivery of end-to-end visibility, which streamlines performance diagnosis across the entire stack. By mapping the complete request path from the client to the database, developers can immediately identify bottlenecks and determine the exact time spent on the network, the server, or raw database execution. These interconnected spans effectively eliminate previous “blind spots” for transports like STDIO and significantly enhance production debugging.

Metrics

We have launched new metrics to provide comprehensive visibility into server performance. While traces offer a granular, single-request perspective, these metrics deliver the aggregate data necessary for a deeper understanding of system health.

Server-side Metrics

• mcp.server.operation.duration: Latency for initialize, tools/list, and tools/call methods across all transports.
• mcp.server.session.duration: Total duration of SSE and STDIO sessions.
• toolbox.server.mcp.active_sessions: A real-time counter of active session counts.
• toolbox.tool.execution.duration: Raw database execution time, excluding protocol overhead.

SDK-side Metrics

• mcp.client.operation.duration: Latency per operation from the client’s perspective.
• mcp.client.session.duration: Lifespan of a client session from start to finish.

By monitoring key aggregate indicators, such as method-specific latency and total session length, users can efficiently evaluate system health. Custom signals like toolbox.server.mcp.active_sessions are essential for real-time capacity planning and detecting session leaks. Additionally, toolbox.tool.execution.duration allows for the isolation of database performance from protocol processing. This telemetry suite shifts operational analysis from tedious log review to streamlined, single-metric queries.

The active_sessions and tool.execution.duration metrics are unique Toolbox enhancements that go beyond standard OTel MCP specifications. The real-time data from the session gauge is vital for infrastructure management, while the execution duration metric is captured within the tool call handler to pinpoint raw database performance.

Note: Histogram recording follows MCP-spec bucket boundaries: [0.01, 0.02, 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 30, 60, 120, 300] seconds.

Telemetry Attributes

To empower users with granular filtering, every span and metric includes a comprehensive set of attributes. These metadata points allow for the differentiation of signals based on transport protocols, specific tool names, and versioning.

Without any additional configuration, you can analyze your telemetry data using the following standard attribute set:

• gen_ai.tool.name: The name of the tool being invoked, if applicable.
• mcp.method.name: The name of the method (e.g., tools/call, tools/list, or initialize).
• toolset.name: The name of the toolset, if applicable.
• network.transport: The transport protocol used for the MCP session (e.g., tcp or pipe).
• network.protocol.name: The name of the network protocol used (e.g., http or stdio).
• mcp.protocol.version: The protocol version (e.g., 2024-11-05, 2025-03-26, 2025-06-18, or 2025-11-25).
• error.type: Type of error occurred, if applicable (e.g., internal_error, invalid_params, or parse_error).

Get Involved!

The MCP governance committee has identified audit trails and observability as an open gap under Enterprise Readiness:

“end-to-end visibility into what a client requested and what a server did, in a form enterprises can feed into their existing logging and compliance pipelines.”

Our upcoming roadmap prioritizes message-level transparency, authentication context, and client identity. In collaboration with Agnost AI, we are building enterprise-ready observability solutions and encourage you to share your thoughts on Discord.

What additional data points are essential for your MCP infrastructure? Connect with us on GitHub, Discord, or via the comments to let us know.

From Lag to Lightning: Optimizing MCP Toolbox with Built-in Observability was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Written by:

• Mike DeAngelo, Developer Relations Engineer @ Google (LinkedIn)
• Nick Acosta, Developer Advocate @ Collate (LinkedIn)

Imagine a dashboard filled with perfectly modeled and tested data, bringing it to your team for the next move, and everyone quickly aligning around an obvious decision. But a few weeks later, the results didn’t match expectations. Data teams are better than ever at collecting, cleaning, and visualizing data, but can still struggle with communicating assumptions, limitations, and conditions present in data’s semantics.

At Kansai Airports, different departments had different definitions of “passengers.” For some teams, a “passenger” was only every paying customer, others included crew and infants. Aligning on a standard definition of this key metric helped make the airport’s data more people-ready, but the jump to AI-ready data is even steeper because an agent will not stop and deliberate when it sees two different “passenger” counts. While OpenMetadata acts as a semantic library storing shared definitions, relationships, and context, MCP Toolbox for Databases empowers AI agents to generate and run application code and tests with a deep understanding of your enterprise data. Together, these open-source tools use semantic intelligence to turn metadata into meaning and allow AI to take action that is trustworthy, explainable, and safe.

In this article, we provide a guide on configuring OpenMetadata alongside MCP Toolbox. We also highlight various use cases currently employed by the open-source community to effectively scale AI operations.

Step-By-Step Guide

OpenMetadata can be set up quickly in a local environment using Docker. Each deployment has an embedded MCP Server already integrated into the OpenMetadata platform. The MCP server leverages the same authorization engine established for OpenMetadata APIs. This enables any MCP client to interface with existing OpenMetadata integrations for read or write operations, while adhering to established roles and policies. Consequently, agents are granted appropriate access to the specific data and functional logic required to automate data operations effectively.

Step 1: Download OpenMetadata

Download Docker and run the following command to get OpenMetadata’s Docker Compose file:

curl -sL -o docker-compose-postgres.yml https://github.com/open-metadata/OpenMetadata/releases/download/1.12.3-release/docker-compose-postgres.yml

Once downloaded, start OpenMetadata and its dependencies by running:

docker compose -f docker-compose-postgres.yml up --d

This will install a OpenMetadata standalone instance on your local machine. OpenMetadata’s embedded MCP Server architecture fully integrates an MCP Server into OpenMetadata by default, enabling AI Agents to act on assets stored in OpenMetadata without any setup and giving agents the proper access to the right data and functional logic to automate data operations.

Step 2: Generate Looker Credentials

You will need an Looker API client_id and client_secret. You can find that information from Looker API authentication. If the “Manage” button is greyed out, contact your Looker administrator for help.

Step 3: Setup MCP Toolbox and OpenMetadata MCP in Gemini CLI

In this section, we will be installing MCP Toolbox with Gemini CLI. Instructions for installing MCP Toolbox with other agents can be found here.

To get started, install the Gemini CLI:

npm install -g @google/gemini-cli

Next, add the MCP Toolbox server and OpenMetadata MCP Server:

gemini mcp add -t stdio looker-toolbox \
  npx -y @toolbox-sdk/server --stdio --prebuilt looker \
  -e LOOKER_BASE_URL=https://looker.example.com \
  -e LOOKER_CLIENT_ID="<YOUR_LOOKER_CLIENT_ID>" \
  -e LOOKER_CLIENT_SECRET="<YOUR_LOOKER_CLIENT_SECRET>" \
  -e LOOKER_VERIFY_SSL=true

gemini mcp add -t stdio OpenMetadata \
  npx -y mcp-remote http://localhost:8585/mcp \
  --auth-server-url=http://localhost:8585/mcp --client-id=OpenMetadata \
  --verbose --clean "--header" "Authorization:${AUTH_HEADER}" \
  -e AUTH_HEADER="Bearer <YOUR_OPENMETADATA_JWT_TOKEN>"

Now, editing ~/.gemini/settings.json will allow you to add Looker and OpenMetadata MCP Servers to Gemini-CLI, your settings.json should contain the following:

{
  "security": {
    "auth": {
      "selectedType": "oauth-personal"
    }
  },
  "ui": {
    "theme": "Default Light"
  },
  "mcpServers": {
    "looker-toolbox": {
      "command": "npx",
      "args": [
        "-y",
        "@toolbox-sdk/server",
        "--stdio",
        "--prebuilt",
        "looker"
      ],
      "env": {
        "LOOKER_BASE_URL": "https://looker.example.com",
        "LOOKER_CLIENT_ID": "<YOUR_LOOKER_CLIENT_ID>",
        "LOOKER_CLIENT_SECRET": "<YOUR_LOOKER_CLIENT_SECRET>",
        "LOOKER_VERIFY_SSL": "true"
      }
    },
    "OpenMetadata": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "http://localhost:8585/mcp",
        "--auth-server-url=http://localhost:8585/mcp",
        "--client-id=OpenMetadata",
        "--verbose",
        "--clean",
        "--header",
        "Authorization:${AUTH_HEADER}"
      ],
      "env": {
        "AUTH_HEADER": "Bearer <YOUR_OPENMETADATA_JWT_TOKEN"
      }
    }
  }
}

To get LookML development tools in addition to the query and content tools, change the line

"args": ["--stdio", "--prebuilt", "looker"],
# to
"args": ["--stdio", "--prebuilt", "looker,looker-dev"],

Note: this guide is running Gemini CLI from the home path (~) and authenticated with a Google Account.

You may have to restart Gemini-CLI for it to pick up these new MCP Servers. Once restarted, type /mcp and you should see a list of available tools like:

Configured MCP servers:

   🟢 looker-toolbox - Ready (10 tools)
     - looker-toolbox__get_models
     - looker-toolbox__query
     - looker-toolbox__get_looks
     - looker-toolbox__get_measures
     - looker-toolbox__get_filters
     - looker-toolbox__get_parameters
     - looker-toolbox__get_explores
     - looker-toolbox__query_sql
     - looker-toolbox__get_dimensions
     - looker-toolbox__run_look
     - looker-toolbox__query_url

🟢 OpenMetadata - Ready (12 tools, 2 prompts)
  Tools:
  - mcp_OpenMetadata_create_glossary
  - mcp_OpenMetadata_create_glossary_term
  - mcp_OpenMetadata_create_lineage
  - mcp_OpenMetadata_create_metric
  - mcp_OpenMetadata_create_test_case
  - mcp_OpenMetadata_get_entity_details
  - mcp_OpenMetadata_get_entity_lineage
  - mcp_OpenMetadata_get_test_definitions
  - mcp_OpenMetadata_patch_entity
  - mcp_OpenMetadata_root_cause_analysis
  - mcp_OpenMetadata_search_metadata
  - mcp_OpenMetadata_semantic_search
  Prompts:
  - create-greeting
  - search_metadata

Step 4: Ingest Looker metadata into OpenMetadata

OpenMetadata ingests metadata from over 120 cloud data services. Adding Looker to OpenMetadata helps to track and manage ownership and lineage of Looker Dashboards, Charts, and LookML Models across data sources and departments. To add Looker to OpenMetadata:

1. In OpenMetadata, click “Settings” at the bottom of the side navigation bar and then “Services”. Looker will be service type: “Dashboards”. After selecting “Dashboards”, select “Add New Service” and look for the Looker icon.

2. After providing a Service Name, OpenMetadata needs the following to connect to Looker:

• Client ID: User’s Client ID to authenticate to the SDK. This user should have privileges to read all the metadata in Looker.
• Client Secret: User’s Client Secret for the same ID provided.
• Host and Port: URL to the Looker instance, e.g., https://my-company.region.looker.com.
• Repository Owner: The owner of a GitHub repository. For example, in https://github.com/open-metadata/OpenMetadata, the owner is “open-metadata”.
• Repository Name: The name of a GitHub repository. For example, in https://github.com/open-metadata/OpenMetadata, the name is “OpenMetadata”.
• API Token: Token to use the API. This is required for private repositories and to ensure we don’t hit API limits. Follow these steps in order to create a fine-grained personal access token. When configuring, give repository access to “Only select repositories” and choose the one containing your LookML files. Then, we only need “Repository Permissions” as read-only for Contents.

With your Looker connector configured, OpenMetadata will start ingesting Looker metadata!

Use Cases

Integrating OpenMetadata, Looker, and MCP Toolbox provides your AI agents with a comprehensive understanding of the semantics within your data stack and Looker environment. To help you scale your operations, we’ve highlighted two key strategies currently being adopted by the community:

1. Automated Tag Synchronization

As different builders and agents produce new data assets across data services, OpenMetadata’s MCP Server and MCP Toolbox provide automated ways to synchronize tags, descriptions, and other metadata across the tools in your data stack. This ensures that as your data ecosystem expands, and more agents are added, the semantic context remains consistent across every tool in your stack. By automating these updates, your Looker environment can stay up-to-date regardless of the data sources that are being used to populate dashboards.

With both MCP Servers installed in Gemini CLI, you can prompt the agent with:

“Use OpenMetadata to trace the lineage for my ecommerce.customers LookML Data Model, apply all tags and field descriptions from its upstream data sources corresponding LookML fields.”

2. Generating Custom Metadata Insights

We are also seeing developers use OpenMetadata’s MCP Server to pull stats like asset and user counts from OpenMetadata to build Looker charts that track adoption of data services. By leveraging MCP Toolbox, agents can quickly turn prompts into insights that can provide a deeper understanding of the health of your data environments.

To implement this use case, the stats from OpenMetadata need to be written to a database before they can be consumed through Looker. Use MCP Toolbox to connect to a database, e.g. Postgres, AlloyDB, etc.. The Docker Compose file used to install OpenMetadata earlier ships with a Postgres instances the can be used in Gemini CLI via the MCP Toolbox by adding the following to .gemini/settings.json:

{
    "mcpServers": {
        "postgres": {
            "command": "toolbox",
            "args": [
                "--prebuilt",
                "postgres",
                "--stdio"
            ],
            "env": {
                "POSTGRES_HOST": "localhost",
                "POSTGRES_PORT": "5432",
                "POSTGRES_DATABASE": "openmetadata_db",
                "POSTGRES_USER": "openmetadata_user",
                "POSTGRES_PASSWORD": "openmetadata_password"
            }
        }
    }
}

Then, prompt Gemini-CLI to:

“Calculate the total number of assets in OpenMetadata by asset type, create a table to hold these stats in Postgres, and write them to the newly created table.”

From here, we could have Gemini CLI connect Postgres and Looker, create a new LookML project, and initial LookML model, before building dashboards and Looks based on our new data.

Conclusion

Integrating OpenMetadata and MCP Toolbox can bring Semantic Intelligence to Looker and the rest of your data stack, providing powerful capabilities that give AI agents and other AI workflows a deep understanding of data assets, relationships and context. For more information on OpenMetadata, please check it out on GitHub and join the OpenMetadata Slack Community. To explore the MCP Toolbox, check out the GitHub repository, read the documentation, and join our Discord server to connect with the community.

For more on OpenMetadata and MCP Toolbox, please be sure to attend the next OpenMetadata Community Meeting! Google developers, Wenxin Du and Mike DeAngelo, will be showcasing MCP Toolbox at this virtual meetup this Wednesday, March 25th, 2026 at 9 AM PST!

Building a Semantic Intelligence Layer for the AI Data Stack was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Written by: Twisha Bansal, Software Engineer @ Google (Linkedin)

If you use Gemini CLI, you’re likely familiar with how it has flattened the learning curve and made app development with databases simple. Today, we’re making that experience smoother, faster, and more portable by transitioning from Tools to Agent Skills for the Cloud SQL for PostgreSQL extension.

Here’s what this means for you and how you can get started.

What are Agent Skills?

Think of Agent Skills as a “user guide” for your AI. Instead of teaching Gemini every possible command at once (which can make it slower and less accurate), Agents Skills allow Gemini to learn exactly what it needs, exactly when it needs it.

Why You’ll Love the Change

Traditional tool-based systems suffer from an “eager loading” problem. When you connect a toolset, the agent front-loads every tool schema into its context. This leads to Context Window Saturation — a state where the model’s limited context window is crowded with technical metadata, reducing its ability to focus on your actual task and increasing the likelihood of errors.

By moving to Agent Skills, we can take a “Progressive Disclosure” approach:

• Discovery: At startup, agents load only the name and description of each available skill, just enough to know when it might be relevant.
• Activation: When a task matches a skill’s description, the agent “activates”, which loads the full SKILL.md instructions into context.
• Execution: The agent follows the instructions, optionally loading referenced files or executing bundled code as needed.

What’s Changing in the Cloud SQL for PostgreSQL Extension?

We’ve refactored the extension to replace monolithic toolsets with a granular skills/ directory. Instead of one large bundle, functionalities are now split into specialized skills:

• cloud-sql-postgres-admin: Administrative tasks such as provisioning new Cloud SQL instances.
• cloud-sql-postgres-lifecycle: Managing the lifecycle of Cloud SQL instances.
• cloud-sql-postgres-data: Explore the database structure.
• cloud-sql-postgres-monitor: Troubleshooting performance issues.
• cloud-sql-postgres-health: Audit database health.
• cloud-sql-postgres-view-config: Discover and manage extensions or engine level settings.
• cloud-sql-postgres-replication: Monitor replication health.

Standardized Execution

Each tool is now mapped to a script within each skills package. This ensures that the execution logic is cross-platform, working seamlessly across Linux, MacOS, and Windows.

Tools vs. Agent Skills in Gemini CLI Extensions

The following comparison outlines the specific advantages of architecting our CLI extensions around Agent Skills rather than traditional tool definitions. By moving to a skill-based model, we transition from simple function calling to a sophisticated, reasoning-first extension ecosystem.

Loading Pattern

• Traditional Tools: Eager (Front-loaded): All tool definitions are loaded into the system prompt at the very beginning, whether they are actually needed for the task or not.
• Agent Skills: Progressive (On-demand): Capabilities are discovered dynamically. The system only loads detailed instructions once the agent identifies a specific, relevant task.

Context Usage

• Traditional Tools: High (Saturation risk): Large toolsets consume a significant amount of token space. This “context bloat” can lead to model confusion and decreased performance.
• Agent Skills: Minimal (Highly optimized): By swapping instructions in and out as needed, skills maintain a clean context window, which directly improves reasoning accuracy.

The Best Part: Zero Manual Installation

We’ve designed this rollout to be completely transparent to you. You don’t need to learn a new installation flow.

• Built-in: When you install an extension with gemini extensions install, skills are automatically installed in the ~/.gemini/extensions/<extension_name>/skills directory.
• Environment Parity: Your existing environment variables are automatically initialized and propagated to the skills during execution.
• Easy Updates: Users can use gemini extensions config <extension_name> to easily update any env variables for their current extension.

Note: As part of this rollout, we are deprecating the use of eager-loaded MCP servers within these extensions to prioritize the leaner skill-based discovery.

Exploring your skills

In the Gemini CLI, you can see what your AI “knows” at any time:

/skills list

Just Ask!

You don’t need special commands to trigger a skill. Just type like you normally would:

• List all the tables in my production database
• What are the top bloated tables in my Postgres instance?
• Execute this SQL and give me a summary

Gemini will automatically identify the right skill, run the underlying script, and give you the answer.

What’s Next?

While we are starting with Cloud SQL for PostgreSQL, we are evaluating the rollout for our entire database extension ecosystem.

Want to try it out?

1. Update your Gemini CLI (v0.29.0+):

npm install -g @google/gemini-cli@latest

2. Update your extension (v0.2.3+):

gemini extensions update cloud-sql-postgresql

If not already installed, install the extension using:

gemini extensions install https://github.com/gemini-cli-extensions/cloud-sql-postgresql

That’s it. Your agent is now leaner, faster, and ready to help you wherever you code.

Curious about the tech behind it? Dive deeper at agentskills.io.

Your Gemini CLI Extensions Just Got Smarter: Introducing Agent Skills was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Written by: Haoyu Wang, Software Engineer @ Google (Linkedin)

Up until recently, developers have primarily relied on the Model Context Protocol to securely connect their databases to AI agents and frameworks, such as the Gemini CLI. Meanwhile, the Agent Skill standard has recently been gaining serious traction as a new, unified way to package, distribute, and consume agent capabilities. As more frameworks begin to adopt this standard, we want to ensure your database tools can seamlessly make the jump. Today, we are excited to introduce the new skills-generate command to MCP Toolbox for Databases!

The Foundation: Invoking Tools from the CLI

Before we could package tools to fit the Agent Skill standard, we needed a way to execute Toolbox tools statelessly. To solve this, we are introducing the new toolbox invoke command.

This foundational feature allows you to run any configured tool directly from your terminal. By simply passing the tool name and its parameters as a JSON string, you can test and execute your queries on the fly without spinning up the server:

toolbox --tools-file tools.yaml invoke list_slow_queries '{"min_duration": "5 minutes"}'

This simple, CLI-driven execution model is exactly what makes our new Agent Skill integration possible.

Bridging the gap with `skills-generate`

Packaging custom tools to fit the new Agent Skill specification manually can be tedious. It requires authoring standard boilerplate, defining precise descriptions, and managing execution scripts.

The skills-generate command eliminates this friction by automatically converting your existing Toolbox toolsets into ready-to-use Agent Skills. It instantly generates a standard SKILL.md file containing the required frontmatter and parameter schemas, alongside a set of cross-platform Node.js wrapper scripts (.js) for each tool to be easily invoked by the agent.

How it works

To get started, simply make sure you have the toolbox executable (0.27.0+) in your PATH (installation guide) and Node.js installed on your system.

Let’s look at a realistic scenario. Imagine you are working on a DevOps AI assistant to help troubleshoot database performance issues. Let’s say you are already using MCP Toolbox building customized tools to enforce guardrails such as preventing access to customer data, and you have a customized tools.yaml file defining an entire suite of restricted, parameterized queries grouped under a db_diagnostics toolset:

sources:
  prod-pg-instance:
    ...

tools:
  list_slow_queries:
    kind: postgres-sql
    source: prod-pg-instance
    description: "List currently active database queries running longer than a specified duration."
    statement: |
      SELECT pid, now() - query_start AS duration, query
      FROM pg_stat_activity
      WHERE state = 'active' AND now() - query_start > cast($1 as interval)
    parameters:
      - name: min_duration
        type: string
        description: "Minimum duration to filter by (e.g., '5 minutes', '1 hour')"
        default: "5 minutes"
  ... # numerous other tools like check_locks, get_table_stats, etc.

toolsets:
  db_diagnostics:
    tools:
      - list_slow_queries
      ...

Now, you can package this entire toolset into a standard Agent Skill simply by running a single command:

toolbox --tools-file tools.yaml skills-generate \
  --name "pg-diagnostics" \
  --toolset "db_diagnostics" \
  --description "A skill for troubleshooting and diagnosing PostgreSQL performance" \
  --output-dir "skills/"

This command creates a standardized package directory, looping through your entire toolset to generate the necessary files:

skills/
└── pg-diagnostics/
    ├── SKILL.md
    ├── assets/
    └── scripts/
        ├── list_slow_queries.js
        ├── list_idle_connections.js
        └── ...

The resulting SKILL.md contains all the necessary metadata and script specifications required by the standard for your entire toolset. Meanwhile, the cross-platform Node.js scripts securely handle the execution of your parameterized SQL queries.

You can even generate skills straight from our prebuilt configurations. Need an AlloyDB admin skill? Just run:

toolbox --prebuilt alloydb-postgres-admin skills-generate \
  --name "alloydb-postgres-admin" \
  --description "skill for performing administrative operations on alloydb"

Ready for your Agent Frameworks

Because the output complies with the Agent Skill specification, you can now drop these tools into any agent framework that supports the standard. For instance, if you are using the Gemini CLI, you can easily install your newly generated skill with a single command:

gemini skills install /path/to/generated-skills/my-skill

Tip: You can skip a step by setting --output-dir to ~/.gemini/skills when generating the skill, installing it straight into the Gemini CLI environment!

Get Started

We’re excited to see how you leverage this new feature to distribute your database tools across the growing Agent Skill ecosystem. Check out the feature documentation, and join our community Discord to share your use cases, ask questions, and connect with the team!

Bring Your Database Tools to the Agent Skill Ecosystem was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.