--- title: Best practices for AI agents | Tiger Data Docs description: 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](/learn/tiger-cli-mcp/index.md). ## 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](/get-started/quickstart/mcp-cli#restrict-tiger-mcp-to-read-only/index.md) 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 --role --password=`, then connect the agent as that role (`tiger db connect --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](/deploy/tiger-cloud/tiger-cloud-aws/security/read-only-role#create-a-read-only-user/index.md) to create the role. ## 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. See [Manage your services](/build/tiger-cli-mcp/common-tasks#manage-your-services/index.md). - **Read replica**: connect the agent to a read replica so exploration never touches the primary or its write performance. Add a read replica [in Tiger Console](/deploy/tiger-cloud/tiger-cloud-aws/high-availability/read-scaling#create-a-read-replica-set/index.md), then point the agent at that set's own connection details. ## 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 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, that production is read-only, and which project to use. This reduces mistakes when an agent switches context. ## Next steps - [Common tasks with Tiger CLI and Tiger MCP](/build/tiger-cli-mcp/common-tasks/index.md): Manage services and work with your data from the CLI or your agent. - [Cookbook](/build/tiger-cli-mcp/cookbook/index.md): Longer, multi-step prompts for schema design, data analysis, and performance tuning. - [Integrate Tiger Cloud with your AI agent](/get-started/quickstart/mcp-cli/index.md): Set up Tiger MCP and connect it to your AI agent. - [File an issue in the Tiger CLI repo](https://github.com/timescale/tiger-cli): Report bugs or request features to help shape the open-source Tiger CLI and Tiger MCP.