List schema names. include_comments defaults to True (cheap — schema count is small).

List tables in a schema. Pass include_comments=True to include table comments inline; include_parent_comments (default True) also returns the parent schema's comment.

List columns (name, type, nullable) in a table. Pass include_comments=True to include column comments inline; include_parent_comments (default True) also returns the parent table's comment.

Search schemas by keywords (space-separated, OR logic) over schema name and comment.

Search tables by keywords (space-separated, OR logic) over table name and comment.

Pass schema_name to scope to one schema (faster, narrower). Omit it to search across all user schemas in the cluster (broader, slightly slower).

Search columns by keywords (space-separated, OR logic) over column name and comment.

schema_name is required. Pass table_name to scope to one table (cheap; use this for routine drill-down). Omit table_name to search every table in the schema (schema-wide; the natural primitive for cross-table FK / JOIN-key reconnaissance, returns table_name on each row).

Get the authoritative comment for a schema — defines its true business purpose; trust it over the schema name.

Get the authoritative comment for a table — defines what data it actually contains; trust it over the table name.

Get the authoritative comment for a column — defines its business meaning and calculation logic; trust it over the column name.

Get authoritative comments for ALL columns in a table at once. Each comment overrides the column name.

Execute a read-only SQL query (SELECT/WITH only). Result rows are paginated via limit/offset.

Bootstrap (or update) a Redshift connection profile from inside an MCP session.

Use when DB tools (list_schemas etc.) return {"error": "not_configured"}, or to add a new profile / re-key an existing one. Ask the user for host / port / user / dbname conversationally — these are not secret — then call this tool. The password is collected via an OS-native dialog (macOS osascript / Linux zenity) launched server-side; it never crosses the MCP wire, never appears in chat or tool args.

Outcomes (return shape):

• {"status": "configured", ...} — profile written, password in keychain. Lazy resolve picks it up on next DB tool call; no restart needed.

• {"status": "dialog_cancelled" | "permission_denied" | "dialog_unavailable" | "platform_unsupported" | "empty_password", ...} — the password step failed, so NOTHING was written: config.toml and the keychain are exactly as they were before the call. The message field tells the agent / user what to do next (often: run redshift-comment-mcp set-fields + set-password --profile X --stdin from a terminal).

Write ordering: the password is collected FIRST; config.toml and the keychain are only touched once one is in hand. That keeps a failed setup from leaving a profile whose fields point at the new cluster while the keychain still holds the old password.

For headless environments without a GUI, prefer the CLI pair set-fields + set-password --stdin instead.

Read-only check of whether a profile is configured. Safe to call at any time including the very start of a session — does not touch Redshift, does not return any secrets.

Use at session start to decide proactively whether to call setup_via_dialog (before triggering any DB tool's not_configured error path), or to verify a setup_via_dialog call succeeded from a fresh angle.

profile overrides which profile to check in profile mode, exactly like the CLI --profile flag — both go through config.resolve_active_profile with the same priority. Omit it (the default) to see the profile the server would actually resolve to right now: REDSHIFT_COMMENT_PROFILE env var, then the active-profile pointer file, then the upgrade-rescue lone-profile fallback, before the literal "default". It has no effect in inline / borrowed mode, where connection resolution never consults a profile name at all.

Returns:

• profile — in profile mode, the profile actually resolved (which may differ from what you passed, or from the literal "default", per the resolution above); None in inline / borrowed mode. No profile is that mode's connection target, so the field never names one — echoing back the call argument (or the literal "default") would tell you the connection is on a profile that may not even exist. In "borrowed" mode specifically, the lending profile's name is reported separately in borrowed_from_profile; the connection itself still never targets that profile, only borrows its password

• source — the mechanism actually in force: "inline" (launch-arg host/user/dbname, password from the REDSHIFT_PASSWORD env var or none), "borrowed" (launch-arg host/port/user/dbname, no inline password, but a stored profile whose host, port, user AND dbname all match lent its keychain password — the connection target is still the INLINE values, never the matched profile's), or "profile" (config.toml + keychain, no launch args)

• configured — bool, equivalent to has_fields && has_password

• has_fields — whether the connection target (host / port / user / dbname) is known; in inline / borrowed mode, always True (the fields came from launch args); in profile mode, False only when the resolved profile has no config.toml entry

• has_password — whether a password is available (OS keychain in profile / borrowed mode; the REDSHIFT_PASSWORD env var in plain inline mode). NEVER returns the password itself

• host / port / user / dbname — the target the connection will actually use, present only when has_fields=True (these are non-secret)

• borrowed_from_profile — present only when source="borrowed": the name of the profile whose keychain password was borrowed

• next_step — present only when configured=False; actionable hint pointing at the right mechanism for the mode