# listViews

Source: https://dbmcp.haymon.ai/tools/list-views/

List the views in a database, with name search and optional SELECT definitions

List the views defined in a database. Materialized views are not returned — they are exposed via [`listMaterializedViews`](/tools/list-materialized-views). Results are paginated — see [Cursor Pagination](/features/pagination#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. PostgreSQL restricts the listing to the `public` schema.

In **brief mode** (default) the response is a sorted JSON array of view-name strings. View names are unique per schema, so no duplicates appear:

```json
{
  "entries": ["active_users", "monthly_revenue"],
  "nextCursor": "<opaque or absent>"
}
```

MySQL/MariaDB and PostgreSQL accept these optional parameters; SQLite returns the brief shape only:

- `search` — a case-insensitive substring filter on view name: `active` matches `active`, `active_users`, and `inactive`. The value is wrapped as `%active%` in a `LIKE`/`ILIKE` pattern, so `%` and `_` inside it still act as wildcards (`_` matches any single character). The `search` value must remain identical across paginated calls for cursor continuity.
- `detailed` — when `true`, the response includes per-view metadata (definer/owner, comment where supported, full SELECT body, plus backend-specific extras) so a single call enumerates views and inspects them. Defaults to `false`.

In **detailed mode** the response is keyed by **bare view name** — views cannot overload, so no signature suffix is needed. The view name is the map key only; it is **not** repeated inside the value. Brief and detailed pages share the same `viewname` row order, so a client can switch `detailed` mid-pagination without losing position.

The PostgreSQL payload carries owner and comment plus the SELECT body:

```json
{
  "entries": {
    "active_users": {
      "schema": "public",
      "owner": "app_user",
      "description": "Currently-active user accounts",
      "definition": " SELECT id,\n    name,\n    email\n   FROM users\n  WHERE active = true;"
    }
  }
}
```

The MySQL/MariaDB payload carries definer / security / check-option / updatability / session-context fields plus the SELECT body:

```json
{
  "entries": {
    "active_users": {
      "schema": "app",
      "definer": "root@%",
      "security": "DEFINER",
      "checkOption": "NONE",
      "updatable": true,
      "characterSetClient": "utf8mb4",
      "collationConnection": "utf8mb4_general_ci",
      "definition": "select `app`.`users`.`id` AS `id`,`app`.`users`.`name` AS `name`,`app`.`users`.`email` AS `email` from `app`.`users`"
    }
  }
}
```

The detailed-mode field set diverges per backend:

- **PostgreSQL** — `schema` (always `"public"`), `owner` (from `pg_views.viewowner`), `description` (from `pg_catalog.obj_description(c.oid, 'pg_class')`, or `null` when no `COMMENT ON VIEW`), and `definition` (the SELECT body verbatim from `pg_views.definition` — no `CREATE VIEW` wrapper, no truncation). Column metadata, the redundant `name` field, and view-level options (`security_barrier`, `security_invoker`, `WITH CHECK OPTION`) are deliberately omitted. Column shape is recoverable from the `definition` text or via [`listTables(detailed=true)`](/tools/list-tables) — Postgres exposes views in `pg_class`, so they appear in table-style introspection too. View options are recoverable from `pg_class.reloptions` via `readQuery`.
- **MySQL / MariaDB** — `schema` (`information_schema.VIEWS.TABLE_SCHEMA`), `definer` (`information_schema.VIEWS.DEFINER`, in `user@host` form), `security` (`information_schema.VIEWS.SECURITY_TYPE`, one of `INVOKER` / `DEFINER`), `checkOption` (`information_schema.VIEWS.CHECK_OPTION`, one of `NONE` / `CASCADED` / `LOCAL`), `updatable` (boolean derived from `information_schema.VIEWS.IS_UPDATABLE = 'YES'`), `characterSetClient` (`information_schema.VIEWS.CHARACTER_SET_CLIENT`, the session character set captured at view creation), `collationConnection` (`information_schema.VIEWS.COLLATION_CONNECTION`, the session connection collation captured at view creation), and `definition` (the SELECT body verbatim from `information_schema.VIEWS.VIEW_DEFINITION` — no `CREATE VIEW` wrapper; if the connected role lacks the `SHOW VIEW` privilege the engine redacts this column to the empty string but the row still appears in the response). `description` is intentionally absent — neither MySQL nor MariaDB exposes a user-comment column for views (`CREATE VIEW` syntax has no `COMMENT` clause). `algorithm` is intentionally absent — it is a MariaDB-only column on `information_schema.VIEWS`, so reading it would fail on MySQL 9. `owner` is renamed to `definer` to match the engine's terminology.

SQLite returns the brief shape only — `search` and `detailed` are not accepted there.