redshift-comment-mcp

Overview Schema Source Related Servers Discussions Admin

Get Setup Status

get_setup_status

Check whether a Redshift connection profile is configured, enabling proactive setup before database tools fail, or verifying setup success.

Instructions

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

Input Schema

TableJSON Schema

Name	Required	Description	Default
`profile`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.12.0Sep 23, 2026
- addedInput schema / properties / profile / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- changedInput schema / properties / profile / default
```
Previous value: -"default"New value: +null
```
- removedInput schema / properties / profile / type
```
Removed value: -"string"
```
First observedv0.1.0May 30, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses safety ('does not touch Redshift, does not return any secrets'), time-independence ('Safe to call at any time'), resolution precedence for profiles, and mode-specific behaviors (inline/borrowed/profile). This is far beyond what annotations would typically cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long (~600 words), but every section (purpose, safety, usage, parameter semantics, return fields) adds unique value given the tool's multi-mode behavior. It is front-loaded with the core purpose and safety statement. While not terse, it avoids fluff and remains well-structured with clear field explanations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fully explains each return field, its conditions (e.g., 'present only when has_fields=True'), the meaning of 'borrowed_from_profile', and how 'next_step' is actionable. The output schema likely lists fields, but the description adds the conditional logic and mode semantics that an agent needs to interpret results correctly. Nothing important is missing for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema shows only a single nullable 'profile' parameter with no description (schema coverage 0%). The description compensates thoroughly by explaining what the parameter overrides, the exact resolution order (env var, pointer file, fallback, literal 'default'), when it has no effect, and how its output differs from the input — including a nuanced explanation of why the returned profile may differ from the passed argument.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: 'Read-only check of whether a profile is configured.' It also immediately disambiguates from siblings by noting it does not touch Redshift and is safe to call at any time, clearly separating it from setup_via_dialog and other DB-bound tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says '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.' This gives concrete when-to-use guidance and names the alternative tool, leaving no ambiguity about the context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server