Cymbal Air Toolbox Demo: A LangGraph Agent Talking to Cloud Databases Through MCP Toolbox
Demo of a customer service agent (Cymbal Air) using LangGraph, Tools, and RAG to interact with Google Cloud Databases via MCP Toolbox.
At a glance
- What is it?
- A reference implementation for a customer service agent that answers airport questions by calling pre-defined database tools through MCP Toolbox. It is a teaching artifact, not a product, and the README says so outright.
- Who is it for?
- Adopt it as a reading and scaffolding exercise if you are building an agent that must query a database through a controlled tool layer, and you want a worked example of separate app, toolbox and database tiers. Do not adopt it as a dependency, a library or a deployable service, since the repository states it is for demonstration only and is not an officially supported Google product.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 32 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Cymbal Air is set up to solve
An LLM that answers questions about flight schedules and airport amenities has no way to know the answer unless you give it one. The demo exists to show a specific pattern for giving it one: the model does not query a database directly, it picks from a fixed set of named tools, and a separate middleware server turns each pick into a database call. The README frames this as a hallucination-reduction technique and pairs it with RAG, where retrieved data is placed into the prompt rather than baked into the model weights. The stated reason for preferring retrieval over fine-tuning is that retrieved information does not alter the model and does not leave the context of the request, which the README says makes it more suitable where information privacy and security matter.
The intended reader is a developer who already has data in a Google Cloud database and wants an agent in front of it. The fictional airline and SFO hub are scaffolding: they give the sample questions a reason to exist. Those questions are concrete (luxury shops in the terminal, coffee near gate A6, a gift for a colleague, flights to NYC tomorrow), and each one maps to a different kind of lookup. That is the point of the sample set. It is not a chat demo, it is a tool-routing demo.
Three tiers: app, Toolbox, database
The architecture diagram in the repository shows three components. The application is the user-facing agentic app that orchestrates the conversation. MCP Toolbox is a middleware server that exposes database operations as tools, and the LLM agent connects to it to execute them. The database holds the data. The README states that the database was intentionally designed to be interchangeable so the demo can run on a preferred database, and the repository topics list AlloyDB, BigQuery, Spanner and PostgreSQL, which is consistent with that claim but is not itself a supported-configuration matrix.
The orchestration model is agent-based rather than a static chain. The README's description is that the LLM decides which tools to use and in what order, given a set such as find_flights and list_amenities, and that this thought process lets it break complex questions into smaller steps. The third stated benefit of the middleware is the interesting one: agents perform better when given smaller, discrete tasks, and mapping one action to one pre-determined query improves the agent's ability to use it. That is a design constraint disguised as a benefit. You are not handing the model a query language, you are handing it a menu, and the quality of your agent is bounded by how well that menu is written.
Getting it running: clone, binary, tools.yaml, server
The README lays out three steps: download the tools, do a one-time database and Toolbox configuration, then launch the server and the app. The first command is a plain clone into a directory named cymbal-air-toolbox-demo. The second step downloads the MCP Toolbox binary, and the README shows the version pinned as an environment variable before the download:
export VERSION=0.8.0 curl -O https://storage.googleapis.com/genai-toolbox/v$VERSION/linux/amd64/toolbox chmod +x toolbox
Note the platform path in that URL. It is linux/amd64, so anyone on macOS or ARM has to find the matching artifact on the releases page rather than copy the line verbatim.
The one-time configuration creates the database instance, populates it with data, and produces a tools.yaml file, and the README points to docs/database_setup.md for the step-by-step version. It also says you can skip this section if you have already configured your own database, which is the branch most evaluators will take.
Launching the Toolbox server has two options. Option A runs it locally from the terminal, which the README calls the quickest way to get started and recommends for local development and testing. Option B deploys it to Cloud Run, which the README describes as a more robust setup. The agentic application is then run separately and connects to whichever server you started. The README's customization section is titled Customizing Your Tools, which is where tool definitions live.
Where this breaks down
The most important limitation is written at the top of the README in a callout: the project is for demonstration only and is not an officially supported Google product. That single sentence changes how you should treat everything below it. There is no support contract, no compatibility promise, and no guarantee that a future Toolbox release keeps the tools.yaml schema or the tool names stable.
The second limitation follows from the architecture. Because the agent only sees the tools you define, any question that does not map to an existing tool cannot be answered from the database, no matter how capable the model is. A user asking about a gate change that no tool covers will get a model that either declines or improvises, and the README's own framing of RAG as reducing hallucination is not the same as eliminating it. Adding coverage means editing tools.yaml and, in most cases, the query behind the tool.
The third is the version pin. The README pins VERSION=0.8.0 for the binary, while the repository's own releases are listed as v0.5.0, v0.4.0 and v0.3.0. Those are two different version lines, the demo repository and the Toolbox binary it depends on, and the README itself says to see the releases page for the latest version. Treat the 0.8.0 line as an example rather than a tested pairing.
The fourth is operational. Running Toolbox locally is described as the quickest path, but it also means the agent's only route to the database is a process on your laptop. Nothing in the supplied material describes what happens to in-flight agent requests when that process restarts.
What you would use instead, and how it differs
The obvious alternative is to let the agent talk to the database directly, either through a SQL-generating tool or through a framework's built-in database integration. The difference is where the query is decided. In a direct setup the model composes the query at request time, so coverage is broad and the blast radius is also broad: the model can read anything the connection can read, and the query it writes is only as safe as your permissions and your prompt. In this demo the query is fixed in advance and the model only chooses among them. That trades flexibility for predictability, and it is the trade the README is arguing for when it says the Toolbox handles authentication and authorization and prevents the agent from directly accessing the database.
A second alternative is to skip the middleware and write the tool functions inside the agent process itself, calling the database client directly. That is fewer moving parts and one less thing to deploy. What you give up is the separation the README describes: the Toolbox can be shared by multiple agents and scaled independently, and it is where connection pooling or caching would live. If you have exactly one agent and no plans for a second, the middleware tier is cost without benefit.
Maintenance, upgrades and the Apache-2.0 terms
The repository is licensed Apache-2.0, which permits commercial use and modification and requires that you retain the licence and attribution notices. It also includes a patent grant and a termination clause. That is a summary of the standard terms, not legal advice; read the LICENSE file in the clone before you ship anything derived from it. Note that the licence covers the demo code in this repository. The MCP Toolbox binary is a separate download from a separate project with its own terms, and the README links to that project's documentation rather than restating them.
Upgrade cost splits along the same seam. The application code is yours to fork and change freely. The Toolbox binary is a pinned download, and the README's own instruction to check the releases page means version drift is expected rather than exceptional. The practical exposure is the tool interface: if a Toolbox upgrade changes how tools are declared or invoked, your tools.yaml and the agent's tool-calling code both need attention. Nothing in the supplied material describes a compatibility policy or a deprecation window, so budget for reading release notes on each bump rather than assuming a drop-in upgrade.
Who should clone this, and who should close the tab
Clone it if you are designing an agent over a database and want a concrete example of the three-tier split, with the tool layer as its own deployable process and the tool definitions kept in a single configuration file. The value is in the shape, and the shape is easy to copy into your own repository. The sample questions are also a useful starting point for your own evaluation set, because each one exercises a different tool.
Do not clone it expecting a library to import, a service to deploy, or a supported component to build on. The README's own note rules that out, and the version mismatch between the demo repository's releases and the pinned Toolbox binary is a reminder that this is a snapshot of a pattern, not a maintained integration. If your agent needs to answer arbitrary analytical questions over a warehouse, the fixed-tool model here will frustrate you faster than it helps.
Editorial conclusion
Adopt it as a reading and scaffolding exercise if you are building an agent that must query a database through a controlled tool layer, and you want a worked example of separate app, toolbox and database tiers. Do not adopt it as a dependency, a library or a deployable service, since the repository states it is for demonstration only and is not an officially supported Google product. Before copying anything, verify three things in your own clone: that docs/database_setup.md matches the database you actually run, that the tool names in tools.yaml are the ones your agent expects to call, and that the pinned Toolbox binary version in the README matches the one you download.
Community notes