Agents

MCP for database: a database MCP server

MCP for database means an artificial intelligence (AI) application reaches a database through an MCP (Model Context Protocol) server. A database MCP server is that program: it offers database tools the application can call. MCP server Postgres means the same local server when the project it serves includes PostgreSQL (often called Postgres). SQL (Structured Query Language) is the text a saved query may contain. The command-line interface (CLI) is the datatug program that starts the server. SQLite is a file database a DataTug project can hold, and it is the database the published walkthrough runs. To give an AI agent read-only database access, use a database login that can only read, and use a server whose tools do not include writes.

MCP serverAvailable

MCP Apps explorerPreview

Read-only connectionsPlanned

The steps below are the plain local setup from the MCP server documentation. That page is the source for the commands. This page does not add flags the documentation does not list.

Install the CLI

Follow Install, then check that the binary includes MCP. The SQL CLI tool page is that same program used as a terminal database client.

datatug --version
datatug mcp --help

If datatug mcp --help is missing, rerun the installer from that page. Desktop clients need the absolute path to the binary when datatug is not on PATH, the list of directories the operating system searches for programs. On macOS and Linux the installer defaults to ~/.local/bin/datatug. In JSON (JavaScript Object Notation) configuration, replace ~ with the full home directory.

Start the local project daemon

The client starts datatug mcp, which talks to a separate datatug serve process. The daemon owns database connections, authentication, the serving principal, and access policies. datatug mcp does not start or stop the daemon. Standard input and output (stdio) is how the desktop client launches that process on your machine. Remote hosts and HTTPS (Hypertext Transfer Protocol Secure) origins are not supported by this bridge.

Use a real project that contains sources, environments, and saved SQL queries. You can register one:

datatug projects add --project my-project --directory /absolute/path/to/project

Or serve the directory directly. The role name in the documentation is a placeholder, not a built-in role. Choose a principal and role declared in the project's policies/ directory:

datatug serve --project /absolute/path/to/project --host 127.0.0.1 --port 8989 \
  --as analyst --role sql-reader

Native SQL execution is refused by default. The daemon's default read surface supports discovery. To execute saved SQL, the serving role needs an explicit opaqueQuery: true permission for the query operation, and the daemon must also be started with --allow-opaque-sql. See Native SQL access policies. That grant is privileged: row filters and column allow-lists are not applied to native SQL. Stop the daemon and restart it after you grant the permission:

datatug serve --project /absolute/path/to/project --host 127.0.0.1 --port 8989 \
  --as analyst --role sql-reader --allow-opaque-sql

Connect Claude Desktop or Codex

Both processes must run as the same operating-system user and use the same local daemon state. DataTug reads the daemon's existing loopback key. You do not copy a bearer token or database credentials into the MCP configuration. If you set DATATUG_DAEMON_DIR for serve, give the MCP process the same value.

Claude Desktop

Add this to claude_desktop_config.json and restart Claude Desktop. These two clients are the ones the documentation names. LLM (large language model) is the model inside the client that decides when to call a tool. The server is not the model.

{
  "mcpServers": {
    "datatug": {
      "command": "/absolute/path/to/datatug",
      "args": ["mcp", "--agent-url", "http://127.0.0.1:8989"]
    }
  }
}

Codex

codex mcp add datatug -- /absolute/path/to/datatug mcp --agent-url http://127.0.0.1:8989

--agent-url is optional at the default address http://127.0.0.1:8989. For another port, use the daemon's loopback origin with an explicit port and no /datatug path.

Discover, inspect, then run

The documentation's example prompt asks the agent to show the serving principal and SQL capability, list projects, discover environments and sources, show saved SQL queries, inspect the selected query, and ask for missing parameter values before running it. The server exposes these eight tools:

Tool	Result
`datatug_agent_info`	Effective serving principal and SQL capability
`datatug_list_projects`	Configured project identifiers
`datatug_describe_project`	Environment, source, and entity identifiers. Connection targets and credentials are omitted.
`datatug_list_queries`	Saved SQL query identifiers and parameter declarations
`datatug_get_query`	Saved SQL and typed parameter declarations. Defaults and connection targets are omitted.
`datatug_list_tables`	Scanned source catalog
`datatug_describe_table`	Table columns, keys, and allowed relationships
`datatug_run_query`	Saved SQL results using bound parameter values and daemon authorization

The saved-query journey in that documentation uses native SQL with SQLite. For the public demo project it names customers/customer-purchases-by-genre before datatug_run_query. Parameter values are supplied by declared identifier and bound by the database driver. They are not inserted into SQL text. limit defaults to 100 and cannot exceed 500. It bounds returned rows, not database work.

Those tool results are how you verify AI generated SQL. The server does not write the statement. Text to SQL accuracy is the reading: the saved SQL and the table description have to be on screen before the number is trusted.

MCP server Postgres, as the opening defines it, is not a separate product. PostgreSQL is a CLI source in the catalogue. This server does not ship a separate Postgres-only tool. An agent reaches a Postgres source only when that source is in the project the daemon is serving. The published walkthrough runs saved SQL on SQLite. TugQL, arbitrary SQL text, writes, generic HTTP (Hypertext Transfer Protocol) forwarding, and interactive query-builder tabs are outside this tool set.

Give an agent read-only database access

Read-only here means two shipped limits, plus one control that is still planned. The eight tools do not include a write. Native SQL stays off until you grant opaqueQuery and pass --allow-opaque-sql, and that grant does not apply row or column filters. The database login should itself be unable to write. DataTug cannot shrink permissions the database already gave that login. The ungoverned agent access article is the longer version of that risk.

The read-only connections pill above is planned. Do not treat it as a switch this setup already enforces. What is an MCP server defines the protocol. Query multiple databases at once is a separate CLI capability. It is not one of these eight tools.

MCP Apps is a developer preview

The saved-query explorer is a developer preview. The documentation says it was tested through a contributor reference host, not as a persistent viewer for your own projects, and that the Claude Desktop JSON and Codex command above configure plain stdio tools. They do not establish accepted desktop rendering. ChatGPT cannot directly launch this local stdio server. The full harness, checksums, and privacy modes are on the same documentation page.

Plain MCP returns saved SQL and query rows in tool results the model can see. The negotiated Apps path, when a host actually supports it, returns counts and a safe summary to the model. This page does not claim that your desktop client renders that view.

Ways to use DataTug · Compare · DataGrip alternative · All features