Cymbal Air Toolbox Demo: a LangGraph agent that queries Google Cloud databases through MCP Toolbox

What Cymbal Air Toolbox Demo actually demonstrates

The repository is a reference implementation for a customer service agent at a fictional airline called Cymbal Air. The agent answers questions about flights and about San Francisco International Airport, which the README describes as Cymbal Air's hub. The examples given are concrete: luxury shops in a terminal, coffee near gate A6, a gift for a colleague, flights headed to NYC tomorrow.

The audience is narrower than the topic list suggests. This is for engineers who are designing an agent that needs to read from a database and who want to see the boundary between the model and the data drawn explicitly. The README frames the whole thing as a demonstration and states plainly that it is not an officially supported Google product. That is not boilerplate. It tells you the repository exists to show a pattern, and the pattern is the deliverable.

The topics on the repository list AlloyDB, BigQuery, PostgreSQL and Spanner, and the README says the database was intentionally designed to be interchangeable so you can run it on your preferred database. That interchangeability is the point of the exercise: the agent code should not care which engine sits behind the tool layer.

How the LangGraph agent, MCP Toolbox and the database fit together

The README describes three components. The Application is the user-facing agentic app that orchestrates the interaction. MCP Toolbox is middleware that exposes database operations as a set of tools, and the LLM agent connects to it to execute those tools. The Database holds the data.

The orchestration model is agent-based rather than a static chain of calls. The README states that the LLM decides which tools to use and in what order, given a set of tools each with a specific function such as find_flights or list_amenities. That design lets the agent decompose a question into smaller steps, and it is also why the tool boundary matters: every capability the agent has is a named tool with a predetermined query behind it.

The README gives three reasons for putting Toolbox in the middle. Security, because Toolbox handles authentication and authorization and the agent never touches the database directly. Scalability, because multiple agents can share one Toolbox and it can scale independently, with connection pooling or caching. And recall, because agents perform better when given smaller, discrete tasks, and mapping a specific action to a specific query improves the agent's ability to use it. The third reason is the one worth arguing about. It is a claim about agent behaviour, and the README asserts it without a measurement.

RAG is the second mechanism. The README explains retrieval as augmenting the prompt with retrieved data so the response is grounded, and notes that unlike fine-tuning, retrieved information does not alter the model or leave the context of the request. That last property is the reason to prefer retrieval when the data is sensitive.

Installing the demo and running a first query

The README lays out a three-step process: download the tools, do a one-time database and Toolbox configuration, then launch the Toolbox server and the app. Start by cloning the repository.

git clone https://github.com/GoogleCloudPlatform/cymbal-air-toolbox-demo.git
cd cymbal-air-toolbox-demo

Next, download the MCP Toolbox binary. The README points to the install steps on mcp-toolbox.dev and shows the commands for a Linux amd64 build. Note that the version shown in the README is an example, and the comment says to see the releases page for the latest version.

export VERSION=0.8.0
curl -O https://storage.googleapis.com/genai-toolbox/v$VERSION/linux/amd64/toolbox
chmod +x toolbox

The one-time setup creates your database instance, populates it with data, and produces the tools.yaml configuration file. The README does not inline those steps. It points to docs/database_setup.md and adds that if you have already configured your own database you can skip the section entirely. That pointer is the real install path, and it is the file to read before you run anything else.

After the database is initialized and tools.yaml exists, you launch the Toolbox server. The README offers two options. Option A runs Toolbox locally from your terminal and is described as the quickest way to get started, aimed at local development and testing. The second option deploys Toolbox to Cloud Run. Only the local option is shown in the excerpt here, so treat the Cloud Run path as something to confirm in the full README before you plan around it.

Finally, the application itself. The Dockerfile installs requirements.txt and starts the service with python run_app.py, so the container entry point is unambiguous.

FROM python:3.11-slim
ENV PYTHONUNBUFFERED True
WORKDIR /app
COPY ./requirements.txt requirements.txt
RUN pip install --no-cache-dir -r requirements.txt
COPY . ./
CMD ["python", "run_app.py"]

What you should see once both processes are up is a web application where you can type one of the README's sample questions and watch the agent choose a tool. If the agent answers without calling a tool, or the Toolbox server logs no tool invocation, the connection between the two is the first thing to check.

The tool layer is the part you will actually have to rewrite

The README's customization section is titled Customizing Your Tools, and that is the honest centre of gravity for this repository. The agent code is a demonstration of a pattern. The tools.yaml file is where your work begins, because every question the agent can answer is defined by a tool you write.

This is a real constraint, not a formality. An agent built this way can only do what its tools allow. Ask Cymbal Air about a flight change and the answer depends entirely on whether someone wrote a tool for it. The README's claim that discrete tools improve recall cuts both ways: the agent is more reliable inside the tool set and completely blind outside it. If your domain has open-ended queries, a tool-per-query design will feel like a straitjacket, and you will spend your time writing YAML rather than prompts.

The second cost is version coupling. The repository pins toolbox-langchain==0.5.3 in requirements.txt while the README's binary download example uses VERSION=0.8.0. Those are different artifacts from the same project, and the README does not state which Toolbox server versions the pinned LangChain integration supports. Check that before you build on it.

Where this demo is the wrong starting point

The README's own note is the first limitation: this is for demonstration only and not an officially supported Google product. Nothing here comes with a support commitment, and the repository is a sample rather than a library you depend on.

The second limitation is that the demo assumes Google Cloud. The requirements pull in google-cloud-aiplatform and langchain-google-vertexai, and the deployment path is built around Cloud Run and Google Cloud databases. If your data lives in a self-managed Postgres on your own hardware, or you have standardized on a different model provider, you are not the target reader. The Toolbox middleware itself may still be useful, but the application half of this repository is not a template you can lift.

The third is scope. The demo is a single agent answering questions about one fictional airline at one airport. There is no evaluation harness described in the README, no accuracy number, and no statement about what happens when a tool returns nothing or the database is unreachable. Those are the failure modes that matter in production, and the repository does not address them. If you need a component with a stated reliability story, this is not it.

Last, the README does not document rollback, migration between database engines, or what happens to an existing tools.yaml when you upgrade the Toolbox binary. Plan for that gap yourself.

Compared with wiring the database directly into a LangChain agent

The obvious alternative is to skip the middleware and give the agent a database client directly, using LangChain's SQL toolkit or a custom tool that runs a query. That approach is faster to stand up. You write one tool, point it at a connection string, and the agent can query anything.

The difference in approach is where the query is defined. With a direct client, the agent composes SQL at runtime, so the set of possible queries is unbounded and the security boundary is whatever your database user can reach. With MCP Toolbox, the README states that each tool maps to a specific, pre-determined query, and the middleware handles authentication and authorization so the agent never touches the database. That is a narrower surface and a more predictable one, at the cost of writing a tool for every question you want answered.

If your agent needs to explore an unfamiliar schema, the direct approach wins. If it needs to answer a known set of questions against a database that holds anything sensitive, the tool boundary is the more defensible design, and this repository is a working example of it.

Licence, maintenance and the cost of keeping up

The repository is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files. That applies to the demo code here. It does not automatically cover the MCP Toolbox server binary you download separately, which lives in its own repository at github.com/googleapis/genai-toolbox, or the Python packages in requirements.txt, each of which carries its own licence. Check those independently if your use is commercial. Nothing here is legal advice.

On maintenance, the last push to the default branch was on 2026-08-14. The most recent release listed is v0.5.0 from 2025-09-26, following v0.4.0 in January 2025 and v0.3.0 in December 2024. The gap between the v0.5.0 release and the August push is worth noting: the repository has moved since the last tagged release, so pinning to a release tag and pinning to the default branch are different decisions.

The dependency list is the upgrade cost that will bite. It pins langchain, langchain-core, langgraph, langchain-google-vertexai, google-cloud-aiplatform, fastapi and toolbox-langchain to exact versions. Those packages release frequently, and the pins mean you inherit a working combination rather than a supported one. Upgrading any single entry means testing the agent loop end to end, because a change in how LangGraph routes between tool calls or how the Vertex AI integration formats messages will not surface until you run a question through it.

Editorial conclusion

Adopt this demo if you are building an agent that must query a database through a tool boundary and want a working reference for the LangGraph plus MCP Toolbox wiring, especially if you already run BigQuery, AlloyDB, PostgreSQL or Spanner. Skip it if you need a supported product, a hosted service, or an agent framework decision that is already settled. Before writing any code of your own, verify three things: that the MCP Toolbox binary version you download matches the tools.yaml schema in this repository, that your chosen database is the one the docs/database_setup.md guide actually covers, and that the toolbox-langchain version pinned in requirements.txt is the one your agent package expects. The demo's own README states it is for demonstration only and is not an officially supported Google product, and that sentence should decide how much of your architecture you copy from it.

Frequently asked questions

Official sources

1. GoogleCloudPlatform/cymbal-air-toolbox-demo on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases