Filtering the table names and reading the schema definitions lets the model map the database — foreign keys included — before it composes anything, which is the step that otherwise costs several failed queries. The query tool then runs whatever you give it, so the grants on the account in your connection string are the real boundary.
A server that connects to any SQLAlchemy-supported database through one connection string and exposes four tools: list the tables, filter them, read their schemas, and run a query.
- all_table_names — every table in the database, as a plain list
- filter_table_names — the tables matching a substring, for finding your way around a large schema
- schema_definitions — column names and types, primary keys, foreign-key relationships and nullable flags for the tables you name
- execute_query — any SQL you write, with optional bound parameters, returned row by row in a readable vertical layout
- Large result sets truncated sensibly, NULLs shown as NULL rather than blanks, and dates in ISO form
- Complete result sets beyond the context window when the companion local-files helper is configured, which is what makes a large export or a chart possible
Uv, a connection string in DB_URL, and the driver for your database installed alongside the server — psycopg2-binary for PostgreSQL, pymysql for MySQL and MariaDB, pymssql for SQL Server, with SQLite needing none. PostgreSQL, MySQL, MariaDB, SQLite, Oracle, SQL Server, CrateDB, Vertica and the other SQLAlchemy dialects all work. Setting CLAUDE_LOCAL_FILES_PATH is what turns on full result-set access. Mozilla Public License 2.0.
One command plus a key — uvx --from mcp-alchemy==2025.8.15.91819 --refresh-package mcp-alchemy mcp-alchemy, then supply credentials