Reading is its own entry point: execute_read_only_query accepts SELECT, PRAGMA and EXPLAIN and rejects write operations outright, so an agent that should only read can be handed that tool and cannot get past it by phrasing the SQL differently. The genuinely destructive paths — execute_query and delete_database — are labelled as such in their own descriptions and ask the caller to confirm first, which is a convention in the text rather than a lock. The token you configure is organization-wide, so what the server can reach is decided when you set it, not per call.
A two-level Turso Cloud server: organization tools that create, list and delete databases and mint tokens for them, and database tools that read schema, run SQL and search vectors.
- Databases created, listed and deleted across your Turso organization, with group and regions set at creation
- Per-database tokens minted with a chosen permission by generate_database_token
- Schema on demand — list_tables for a database, describe_table for one table
- SQL split by risk: execute_read_only_query takes SELECT, PRAGMA and EXPLAIN and rejects write operations, while execute_query is the one that can INSERT, UPDATE, DELETE, DROP and ALTER
- Vector similarity search over a named vector_column, given a query_vector and a limit
A Turso account with an API token in TURSO_API_TOKEN, plus TURSO_ORGANIZATION and TURSO_DEFAULT_DATABASE so calls that omit a database still have one to run against.
One command plus a key — npx -y mcp-turso-cloud, then supply credentials