Skip to Content
dbmcp

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: users matches users, users_audit, and old_users. The value is wrapped as %users% in a LIKE/ILIKE pattern, so % and _ inside it still act as wildcards (_ matches any single character).
  • detailed — when true, the response includes per-table metadata (columns, constraints, indexes, triggers) so a single call enumerates the tables and inspects them. Defaults to false.

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.