List the schemas in the database with how many tables and views each holds. Start here when you do not know the shape of the database yet.

List the tables and views in one schema, largest first, with an estimated row count and total on-disk size. Use this to find out what is expensive before you query it. Row counts are planner estimates, not exact counts.

Full description of one table: every column with its type, nullability and default, plus primary keys, foreign keys, unique and check constraints, indexes and any comments. This is the core tool once you know which table you want.

Search for columns by name across every schema, optionally filtered by type. Use this instead of listing tables when the database is large: searching for "customer_id" finds every table that carries it in one call.

Follow foreign keys from one table, in both directions, up to a given depth. Outbound keys tell you what a row points at; inbound keys tell you what points at it. Use this to work out how to join instead of guessing from column names.

Return the first few rows of a table so you can see the shape of the data. Columns whose names look like secrets are masked. Results are capped by row count and by size, and the response says when it truncated.

Run one SELECT or WITH statement. Anything else is refused, including stacked statements, DDL, DML and SELECT INTO. The query runs in a read-only transaction with a statement timeout, results are capped and secret-looking columns masked. There is no write mode.

Show the query plan for a SELECT without running it. Pass analyze: true to execute it and get measured timings instead of estimates. Use this to tune a query before running it against a large table.

Write a Markdown data dictionary for one schema to a file: every table, every column with type and nullability, and every key and constraint. Once written, you can read the schema from disk with no database connection. This is the only tool here that writes anything, and it writes only to the path you give it.