Skip to content
Search ⌘K
Start a free trial

Best practices for AI agents

Use Tiger MCP and Tiger CLI safely with AI agents, including read-only mode, forks and read replicas, and effective prompting

Tiger MCP lets an AI agent act on your Tiger Cloud services: create and fork services, run queries, and change data. This page covers how to keep that safe and get better results. New to these tools? See Tiger CLI and Tiger MCP.

Restrict agents to read-only

Section titled “Restrict agents to read-only”

When you want an agent to explore and query without making any changes, turn on read-only mode. See Restrict Tiger MCP to read-only for the commands: it blocks mutating CLI commands and Tiger MCP tools, and puts database sessions into Tiger Cloud's immutable read-only mode so writes and schema changes are rejected by the server.

This also protects your bill: creating, forking, and resizing services all provision or change billable resources, and read-only mode disables the Tiger MCP tools for all three.

Default production to read-only

Keep production services in read-only mode and only escalate to write access deliberately, for the specific change you intend to make.

For an additional layer of security, create a dedicated read-only database role, save its password with tiger db save-password <service-id> --role <role> --password=<password>, then connect the agent as that role (tiger db connect <service-id> --role <role>, or the role parameter on Tiger MCP's database tools). Because the restriction is enforced by the database itself, it applies no matter how the agent connects. See Manage data security in your Tiger Cloud service to create the role.

Grant the role SELECT on the tables the agent needs. A role created with tiger db create role --read-only can log in but holds no table privileges, so an agent connecting as it gets permission denied on every query until you grant access.

Test against a fork or a read replica

Section titled “Test against a fork or a read replica”

For exploratory or agent-driven work, point the agent at a copy of your data instead of production:

  • Fork a service to get an isolated, writable copy you can experiment on and then discard: tiger service fork <service-id> --now, or ask your agent (service_fork). See Manage your services.
  • Read replica: connect the agent to a read replica so exploration never touches the primary or its write performance. There is no CLI or Tiger MCP tool for creating a read replica set; add one in Tiger Console (an agent should ask you to do this step, not attempt a command for it), then point the agent at that set's own connection details.

Have the database do the work

Section titled “Have the database do the work”

Agents sometimes pull large result sets to the client and process them locally, which is slow and can expose more data than needed. Get better results by:

  • Asking for a single computed answer (an aggregate, a ratio, a yes/no) rather than raw rows.
  • Setting explicit limits in your prompt, for example "return at most 50 rows."
  • Asking the agent to show the SQL it will run so you can verify it before it executes.

Guardrails for coding agents

Section titled “Guardrails for coding agents”

When you use an agent like Claude Code against your database, add project instructions (for example, in CLAUDE.md) that state which services are production and that production is read-only. This reduces mistakes when an agent switches context. For example:

## Database access via Tiger MCP


- Production service ID: `<prod-service-id>`. Treat as READ-ONLY: never call a mutating
  service tool against it (for example `service_resize`, `service_stop`,
  `service_update_password`), and never run write or DDL SQL against it, without
  explicit approval.
- For schema changes or risky queries, fork production first (`service_fork`) and test
  on the fork.
- Development service ID: `<dev-service-id>`. Safe to modify freely.
- Show the SQL you're about to run before calling `db_execute_query` with anything other
  than a `SELECT`.

Guardrails checklist

Section titled “Guardrails checklist”
  • Keep production services in read-only mode by default.
  • Connect the agent as a dedicated read-only database role, not tsdbadmin.
  • Point exploratory or agent-driven work at a fork or read replica, never production directly.
  • Ask for a single computed answer instead of raw rows, and set an explicit row limit.
  • Ask the agent to show the SQL it will run before it executes anything that writes.
  • State which services are production in your project instructions (for example, CLAUDE.md).

Next steps

Section titled “Next steps”