MCP Database Integrations

1. MCP Database Integrations

Welcome back! In this chapter we'll prepare our MCP servers for production applications, starting with integrating databases.

2. Why Add a Database to the Timezone Server?

So far, the resources we've defined have retrieved data from local files, which works for a small list of stable locations, but it doesn't scale well. By connecting MCP servers with databases, we can run real queries—filter by region, search by name, and sort—without loading everything into memory. When we have thousands of locations, database indexes keep lookups fast; a single file becomes slow and hard to maintain.

3. Why Add a Database to the Timezone Server?

Multiple clients or tool calls can hit the database at once without causing access or consistency issues. And we get the standard database benefits of backups, replication, and having a single source of truth. That's why backing the timezone server with a database makes it production-ready: it unlocks query power, scale, and concurrency that a file simply can't match.

4. Data Access: Tools vs. Resources

At this point, you may be wondering: when should data access become a tool call rather than a resource? This is an important question. Generally speaking, data access should be a resource when it only needs to be read-only, the data changes infrequently, and the information reflects a reference rather than a requirement. Things like content guidelines, documentation, and policies are often best exposed as resources. However, for data access that is dynamic and based on user inputs, writing operations, or highly changeable data, a tool call is often best. Think data analytics and operations here. So how does this connection actually take place?

5. Connection Lifecycle

Create the connection once the server starts, or on its first use, and reuse that same connection inside the tool and resource handlers instead of opening a new connection for each request. When the server shuts down, close the connection. That keeps the server efficient and avoids exhausting connection pools in production.

6. Database Resource: timezone_server.py

To ensure the database connection is created on startup, we add it to the top of the script, before any tools or resources are defined. The convert_timezone tool stays as before. The get_locations() resource now reads from the database instead of a file, so the model still gets the same list of supported locations as context. This information is a good fit for an MCP resource; however, we'll also try it as a tool to see both variations.

7. Database Lookup Tool: timezone_server.py

We add a lookup_locations tool that takes a timezone prefix and executes a parameterized query. You don't need to understand the database querying language here, the important thing to note is that the prefix chosen by the LLM will be inserted where the question mark is in the query to filter the dataset. When the server exits, we close the connection in a finally block so the connection is always released.

8. Safety and Production Habits

Database integrations can be game-changing for MCP servers, but only if we follow best practices and a cautious approach. Firstly, always use parameterized queries. Never build your code or querying language by concatenating or formatting user or LLM inputs. This leaves you open to a phenomenon called prompt injection. This is where users or LLMs can inject code into your system. Additionally, prefer read-only or tightly scoped database access. If the server doesn't need access to a particular table to perform specific operations, don't allow it. Apply smart limits—for example, a maximum number of rows or query timeouts—so responses stay bounded and predictable in production.

9. Let's practice!

Time to give this a go!

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.