I’ve been using MCP more often with coding agents because I want the agent to inspect real project context instead of guessing.

Code files are easy. Most agents can already read the repo. Databases are where the setup gets annoying.

If I want an agent to understand a schema, check a table, or verify a small query, I usually have to wire up a database-specific MCP server. That means one setup for PostgreSQL, another for MySQL, another for SQL Server, and so on. This works, but it starts to feel heavy when I move between client projects.

That is why TablePlus MCP support caught my attention. TablePlus already knows about my database connections. If it can expose those connections to an AI tool through MCP, the workflow becomes much simpler.

This is not about replacing a proper database workflow. I still want read-only users, staging databases, and manual review for anything risky. I just want to give an AI agent database context without maintaining a separate MCP setup for every engine.

For this walkthrough, I am using Codex, OpenAI’s coding agent CLI. I use it to read the project, run local commands, and connect to MCP servers from my development environment. TablePlus MCP gives Codex database context through the connections I already manage in TablePlus.

What TablePlus Added

TablePlus listed the MCP update in its macOS changelog for Version 7.1.8 (718), released on June 10, 2026. The release notes say TablePlus “introduced and reworked TablePlus MCP” and added Codex CLI support.

That timing is interesting because MCP has become the common bridge between AI tools and external systems.

What I Wanted

My ideal setup is boring:

• I manage database connections in TablePlus.
• I let an AI coding agent ask limited database questions through MCP.
• I avoid maintaining separate MCP servers for every database engine.
• I keep dangerous access out of the default workflow.

I want the database client I already trust to become the MCP entry point, instead of spreading connection details across several agent configs.

Step-by-step Local Setup

This is the local setup I used on macOS with TablePlus and Codex.

First, open TablePlus settings and go to the MCP tab. Enable the MCP server, choose a preferred port, and keep unsafe queries behind approval. In my case, TablePlus shows the MCP server running on port 51003.

I also keep Auto-generate Access Token for tableplus-mcp enabled. TablePlus generates a token when the app restarts and stores it where tableplus-mcp can read it. If I turn that off, I need to set the token manually with the TABLEPLUS_MCP_ACCESS_TOKEN environment variable.

TablePlus also shows the client setup snippet. For Codex, the important part is the command:

{
  "mcpServers": {
    "tableplus": {
      "command": "/Applications/TablePlus.app/Contents/MacOS/tableplus-mcp"
    }
  }
}

Then I add that command in Codex as a custom MCP server:

1. Open Codex settings.
2. Go to MCP servers.
3. Add a custom MCP server.
4. Set the name to tableplus.
5. Choose STDIO.
6. Set the command to:/Applications/TablePlus.app/Contents/MacOS/tableplus-mcp

After saving, TablePlus keeps the MCP server available. When you send a prompt that uses TablePlus MCP, Codex launches tableplus and the agent can use the database connections TablePlus exposes.

Sample Prompts to Verify MCP Connectivity

After setting it up, I like to test the connection in small steps. I do not start by asking the agent to do anything complicated. I first ask it to list what TablePlus can see.

1. List TablePlus Connections

The first prompt checks whether Codex can talk to the TablePlus MCP server:

using tableplus mcp, show all my connections.

In my case, Codex returned the saved TablePlus connections, including the driver, host, port, tag, default database, and SSH status. That proves the MCP server is reachable and that Codex can read the connection metadata exposed by TablePlus.

2. Open a Connection and List Tables

Once the connections are visible, the next test is opening a specific connection and asking for tables:

Open connection to "connection-name" and show all the tables.

This is a better test than only listing connections because it confirms that the MCP server can open the selected database connection and inspect the schema. In my local example, it opened the selected connection and listed the tables in the public schema.

3. Run a Small Read Query

The next check is a small read query:

Retrieve and display all data from the User table.

This confirmed that Codex could query a table through TablePlus MCP and return actual rows. For a real project, I would usually make this safer by asking for a capped result set:

Retrieve up to 10 rows from the User table.

Listing metadata proves the connection works. Reading a small table proves the query path works.

4. Run a Controlled Write Smoke Test

For local development, I also tried a small write test:

Add new dummy user.

Codex inserted a test row into public."User" and then verified that the row existed. After that, I asked it to show all the data again:

Perfect, now show me all the data.

This is not a prompt I would run casually against production. I used it as a local smoke test to confirm that TablePlus MCP can do more than list metadata and read rows. In this case, I made one controlled change and verified the database state immediately.

I also checked the same table directly in TablePlus afterward. This is the extra confirmation I like: the agent says it wrote the row, and the database client shows the row in the table.

How I Think About The Options

I do not think one option wins everywhere. For local development and project inspection, TablePlus MCP is the one I want to try first.

Why I Prefer TablePlus MCP

1. Easier Setup

TablePlus already has a good UI for managing database connections, so I do not want to recreate that setup in several MCP config files.

I do not want to write a new JSON config every time I switch projects. I do not want to remember which MCP package supports which database engine. I also do not want to debug a separate server process before asking a basic question like “what columns does this table have?”

2. One Place for Multiple Database Engines

TablePlus supports many database engines: PostgreSQL, MySQL, MariaDB, SQLite, Microsoft SQL Server, Redshift, Oracle, CockroachDB, Snowflake, Cassandra, Redis, Vertica, MongoDB, and more.

Without TablePlus MCP, the shape often looks like this:

Agent -> PostgreSQL MCP server
Agent -> MySQL MCP server
Agent -> SQL Server MCP server
Agent -> SQLite MCP server

With TablePlus MCP, the shape can be closer to this:

Agent -> TablePlus MCP -> Existing TablePlus database connections

That gives me fewer config files, fewer packages, and fewer setup notes to carry between projects.

3. Less Duplicate Credential Management

Separate MCP servers usually need their own connection strings, environment variables, secrets, and local setup notes.

That is easy to tolerate for one project, but it gets messy across several projects. I also try to avoid leaving old staging or production credentials in forgotten config files.

With TablePlus, the connection is already managed in the desktop app. TablePlus also documents that database credentials are kept on the user’s device. In its LLM Plugin docs, TablePlus says data records are not sent to the language model, while table or view structure may be shared when using AI features.

I still treat database access carefully. But I prefer starting from the tool where my database connections already live instead of duplicating them into every MCP server config.

4. Better Fit for Real Consulting Work

In real client work, I rarely stay inside one perfect stack.

One project might use SQL Server. Another might use PostgreSQL. A local utility might use SQLite. A side project might use MySQL. If my AI database workflow depends on separate MCP servers for every engine, setup becomes part of the job again and again.

TablePlus is already built around this multi-database reality. That is why its MCP support feels practical to me.

5. Easier Project Switching

I like tools that reduce project ceremony.

The workflow I want is:

1. Open the right TablePlus connection.
2. Confirm the database and environment.
3. Let the AI agent inspect schema or run a bounded read query.
4. Review anything risky manually.

That is much easier to keep in my head than a pile of per-engine MCP setup instructions.

6. A Visual Safety Check

Raw MCP configs are invisible most of the time. You only notice the target database when something runs.

TablePlus gives me a visual database client in the loop. I can see connection names, groups, schemas, and query results in the same tool I already use for database work.

That does not replace permissions. But it does give me one more practical check before an AI agent works near real data.

A Concrete Example From My Workflow

Here is the kind of task where I want this. I would treat this as a prompt pattern, not a guarantee that every model will produce the same result:

Check the current schema for the User table and tell me which columns are
required when adding a new user. Only inspect schema metadata. Do not read
table rows or write to the database.

That example lines up with the local run shown earlier. I used a local Invoicing connection and the User table. Codex listed the TablePlus connections, opened the one I selected, listed tables in the public schema, retrieved rows from the User table, and then I checked the same result directly in TablePlus.

Without database access, the agent has to infer from code or ask me to paste schema details. That can work, but it is slower.

With a database MCP path, the agent can inspect the actual schema and compare it with the application code. The output is more grounded. The feedback is usually more useful.

I still keep the request narrow. For this kind of schema check, I ask for metadata only and make it clear that the agent should not read table rows or write to the database.

Where I Would Still Be Careful

MCP does not remove database risk. It gives AI tools a path to external systems, so permissions matter even more.

The guardrails I would keep:

• Use read-only users for AI-assisted inspection.
• Prefer local or staging databases for exploration.
• Cap query results with LIMIT 50, TOP (50), or the equivalent for the database engine.
• Review write operations manually instead of letting an agent change data freely.
• Keep production access separate from day-to-day AI workflows.
• Name connections clearly so the environment is obvious before any query runs.

The boring setup is the safer setup.

When I Would Choose TablePlus MCP

I would reach for TablePlus MCP when:

• I already manage database connections in TablePlus.
• I work with more than one database engine.
• I want one practical MCP entry point instead of several database-specific MCP servers.
• I need an AI coding agent to inspect schema, list tables, or run small read-only checks.
• I want less setup friction when switching between projects.

I would still consider a dedicated MCP server when I need deeper engine-specific behavior, a server-side deployment model, or a tightly controlled production integration.

For me, TablePlus MCP feels best for local developer workflows, exploratory queries, and agent-assisted understanding.

Final Thoughts

The reason I am interested in TablePlus MCP is not because it sounds flashy. It matches how I already work.

I already keep database connections in TablePlus. I already move between different database engines. I already use AI agents to inspect code and verify small details.

Putting MCP support inside the database client removes a layer of setup while keeping the workflow close to the tool I already use.