listTables
List the tables in a database, with name search and optional columns, constraints, and indexes
List tables in a database, one page at a time. Results are paginated — see Cursor Pagination for the protocol. On MySQL/MariaDB and PostgreSQL the database parameter selects which database to inspect (defaults to the active database); SQLite operates on a single file and has no database parameter.
The tool accepts two optional parameters that shape the response:
search— a case-insensitive substring filter on table name:usersmatchesusers,users_audit, andold_users. The value is wrapped as%users%in aLIKE/ILIKEpattern, so%and_inside it still act as wildcards (_matches any single character).detailed— whentrue, the response includes per-table metadata (columns, constraints, indexes, triggers) so a single call enumerates the tables and inspects them. Defaults tofalse.
In brief mode (default) the response shape is:
{
"entries": ["customers", "orders", "products"],
"nextCursor": "<opaque or absent>"
}In detailed mode the response is keyed by table name:
{
"entries": {
"orders": {
"schema": "public",
"kind": "TABLE",
"owner": "app",
"comment": null,
"columns": [
{ "name": "id", "dataType": "bigint", "ordinalPosition": 1, "nullable": false, "default": null, "comment": null }
],
"constraints": [
{ "name": "pk", "type": "PRIMARY KEY", "columns": ["id"], "definition": "PRIMARY KEY (id)" }
],
"indexes": [],
"triggers": []
}
}
}Field availability follows what the backend exposes — owner is null on MySQL, MariaDB, and SQLite (only PostgreSQL reports it); PostgreSQL fills schema from the catalog while SQLite uses main.