redshift-comment-mcp

Overview Schema Source Related Servers Discussions Admin

Setup Via Dialog

setup_via_dialog

Configure or update a Redshift connection profile when tools report 'not_configured' by using an OS-native dialog to collect the password securely without exposing it in chat.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Default
`host`	Yes
`port`	No
`user`	Yes
`dbname`	Yes
`profile`	No	default

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

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, the description carries full behavioral disclosure. It explains that the password never crosses the wire, uses OS-native dialogs, defines outcome statuses, and details write ordering (password first, then config/keychain). It also clarifies that on failure nothing is written, which is crucial for an agent's decision-making.

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

Conciseness5/5

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

The description is structured with clear sections: trigger, procedure, outcomes, write ordering, and alternative. It front-loads purpose and usage, then adds necessary detail. Every sentence serves a purpose—no fluff. Despite its length, it is efficient and well-organized.

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?

Given the tool's complexity (dialog, password handling, keychain, multiple failure modes, headless alternative), the description is thorough. It covers all outcomes, side effects, and prerequisites. The output schema exists, but the description still explains return statuses and failure implications, making it complete for an agent to use correctly.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate. It explains that host/port/user/dbname are collected conversationally and are non-secret, and mentions profile concept. It does not detail each parameter's format or constraints, but the schema already provides types and defaults. The description adds meaningful context beyond the raw schema, though it could be more specific about the profile parameter.

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 description clearly states the tool's purpose: to bootstrap or update a Redshift connection profile. It specifies the exact trigger condition (DB tools returning not_configured) and distinguishes itself from sibling query tools by focusing on setup. It's not a tautology and adds actionable context.

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?

It explicitly states when to use the tool: when DB tools return not_configured, or to add/re-key a profile. It also gives a clear alternative for headless environments (CLI pair set-fields + set-password). The guidance is direct and leaves no ambiguity about when to use this tool vs alternatives.

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

Deploy Server