Plan to link your LLM to your production database? What could possibly go wrong?

TL;DR: LLMs are a powerful way to interact with databases, but can cause security risks. We link a LLM to a database via a MCP server and then build a table reservation assistant.

LLMs are a powerful way to interact with databases, but cause all sorts of security risks. Users can trick the LLM to read out data that shouldn’t be read or even worse trick the LLM to perform SQL insertion attacks that delete huge swaths of data. Not only does the risk come from the user, but anything the LLM reads from the database could contain a prompt injection attack. Clearly in such a threat environment, we need to ensure the database access is closely regulated.

Model Context Protocol (MCP) servers fill the need for cases like this, acting as a bridge and a gatekeeper, allowing the AI to access external tools such as databases while standardizing communication through a unified protocol. With an MCP server in place users can interact with the database in natural language, not with SELECT … FROM … like statements but through clearly defined whitelisted tools that ensure compliant database access. In this way, AI assistants are able to interact with the database, discovering interaction patterns, reading data and writing new entries.

In this hands-on tutorial, we will go through the process of setting up an MCP server for a Postgres database and demonstrate how to use the MCP server. Next, we’ll link the LLM with a simple streamlit webapp and show how it can be used by end users to quickly search and update the datbase.

All material to recreate what I’m demonstrating can be found here: https://gitlab.com/cseward/psql-mcp