fix(mcp): complete all 4 MCP templates to github-level quality

postgres:
- Fix false claim that server is read-only by design — it executes arbitrary SQL
- Rewrite rules.md with real SQL safety: hard stops for DROP/TRUNCATE/DDL,
  confirm-before-DML, no UPDATE/DELETE without WHERE, production environment
  detection, connection pooling guidance
- permissions.json: correct _comment to document the tool-level limit of
  the MCP permissions system (SQL-level restriction is behavioral via rules.md)

supabase:
- Add _verified_with: @supabase/mcp-server-supabase@0.7.0 to config.json
- Add _read_only_variant note documenting --read-only flag
- rules.md: add "Read-only mode for production" section — documents --read-only
  as hard enforcement layer for production tokens with exact args example

redis:
- permissions.json: add config_set, config_rewrite, shutdown to deny list
  (config_set can change maxmemory/bind/requirepass at runtime; shutdown
  terminates the process)
- rules.md: expand hard stops section with rationale for each denied operation

slack:
- permissions.json: add update_message, archive_channel, set_channel_purpose,
  set_channel_topic to deny; add add_reaction to allow
- rules.md: full rewrite — add editing rules (bot-only), privacy guidance for
  private channels, channel scope policy ("which channel(s)?"), hard stops
  with rationale for each denied operation

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: luiseiman

mcp/postgres/permissions.json

@@ -1,6 +1,6 @@
 {
   "_template": "claude-kit/mcp/postgres",
-  "_comment": "The official postgres MCP server (@modelcontextprotocol/server-postgres) is read-only by design — it only exposes query (SELECT). This permissions file documents that posture and adds no deny entries beyond what the server already enforces.",
+  "_comment": "The @modelcontextprotocol/server-postgres 'query' tool executes arbitrary SQL — it is NOT read-only by design. SQL-level restrictions (no DDL, no unguarded DML) cannot be enforced via the permissions system (which only blocks tool calls by name, not SQL content). Enforcement is via rules.md. The allow list restricts which tools Claude may call; write protection is behavioral, governed by rules.md.",
   "allow": [
     "mcp__postgres__query",
     "mcp__postgres__list_tables",

mcp/postgres/rules.md

@@ -5,26 +5,69 @@ globs: "**/*.sql,**/migrations/**,**/models/**,**/db/**"
 # PostgreSQL MCP Rules
 
 ## Server posture
-The official postgres MCP server is read-only — it only executes SELECT queries.
-Use it for schema exploration and data inspection, not for mutations.
 
-## Safe operations (call freely)
+The official `@modelcontextprotocol/server-postgres` exposes a `query` tool that executes
+**arbitrary SQL** — SELECT, INSERT, UPDATE, DELETE, and DDL. It does NOT enforce read-only.
+The permissions system cannot block specific SQL patterns — it only blocks tool calls by name.
+SQL safety is entirely governed by these rules. Follow them without exception.
+
+## Safe operations — call freely
+
 - `list_tables`: enumerate schema
-- `describe_table`: inspect columns, types, constraints
-- `query`: SELECT statements only — the server enforces this
+- `describe_table`: inspect columns, types, constraints, indexes
+- `query` with SELECT: data inspection — no confirmation needed
+- Always add `LIMIT` when querying unknown table sizes (default: `LIMIT 100`)
+- Use explicit column lists — avoid `SELECT *` on wide tables
+- When exploring foreign keys, use `describe_table` first
+
+## DML — confirm before executing
+
+Before any INSERT, UPDATE, or DELETE:
+1. Show the complete SQL statement
+2. State the expected row count (run a SELECT COUNT WHERE first if unknown)
+3. State whether the operation is reversible (no transaction → not reversible)
+4. Wait for explicit user confirmation
+
+**Never run UPDATE or DELETE without a WHERE clause.** If no WHERE clause is intended,
+say so explicitly and require double confirmation: "This will affect ALL rows in the table."
+
+## DDL — hard stops
+
+Never execute any of the following without the user typing the command explicitly
+(not just saying "yes, go ahead"):
 
-## Query hygiene
-- Always add LIMIT when querying unknown table sizes (default: LIMIT 100)
-- Use explicit column lists in SELECT — avoid `SELECT *` on wide tables
-- When exploring foreign keys or relationships, use `describe_table` first
+- `DROP TABLE` / `DROP TABLE IF EXISTS`
+- `DROP DATABASE` / `DROP SCHEMA`
+- `TRUNCATE` / `TRUNCATE TABLE`
+- `ALTER TABLE ... DROP COLUMN`
+- `ALTER TABLE ... DROP CONSTRAINT`
 
-## Mutations belong elsewhere
-For INSERT, UPDATE, DELETE, or DDL:
-- Use the Supabase MCP template if on Supabase (see mcp/supabase/)
-- Use local psql / migration tooling for schema changes
-- Never ask the user to "just run this in psql" without showing the full statement first
+For these operations: stop, show the full statement, explain the irreversibility, and
+instruct the user to run it manually via psql or their migration tool.
+
+## Migrations
+
+- Use SQL mutations through migration files, not through MCP `query` directly
+- Exception: exploratory SELECT queries and development seed data are fine via MCP
+- For schema changes in any non-local environment: stop and refer to migration tooling
 
 ## Environment awareness
-- Development DB: standard inspection workflow
-- Staging/production DB: always state which environment you are connecting to before any query
-- If DATABASE_URL points to production: treat even read operations as sensitive (may contain PII)
+
+Before any DML or DDL, identify the environment from DATABASE_URL:
+
+- **Local / development** (`localhost`, `127.0.0.1`, `*.local`): standard confirmation flow
+- **Staging** (`staging`, `stage`, `stg` in host or DB name): standard confirmation flow
+- **Production** (`prod`, `production`, `live`, or any RDS/Cloud SQL endpoint without clear staging marker):
+  - Treat even SELECT as sensitive (may contain PII)
+  - DML: stop and refuse — tell the user to run manually
+  - DDL: always refuse
+  - State the environment explicitly before every query: "Connecting to **PRODUCTION**"
+
+If DATABASE_URL is ambiguous (no clear env marker), ask before any write operation.
+
+## Connection pooling
+
+If DATABASE_URL uses PgBouncer or similar pooler:
+- Avoid SET statements and advisory locks — they break under transaction pooling mode
+- Avoid multi-statement transactions in a single `query` call under session pooling
+- Prefer explicit single-statement queries

mcp/redis/permissions.json

@@ -22,6 +22,9 @@
     "mcp__redis__flushdb",
     "mcp__redis__flushall",
     "mcp__redis__debug",
-    "mcp__redis__config_resetstat"
+    "mcp__redis__config_set",
+    "mcp__redis__config_rewrite",
+    "mcp__redis__config_resetstat",
+    "mcp__redis__shutdown"
   ]
 }

mcp/redis/rules.md

@@ -28,8 +28,10 @@ Before any SET, DEL, EXPIRE, XADD, or consumer group operation:
 4. Wait for explicit confirmation
 
 ## Hard stops (always denied)
-- `flushdb` / `flushall` — data destruction. Never call.
-- `debug` / `config resetstat` — operational risk.
+- `flushdb` / `flushall` — destroys all keys in DB or entire instance. Never call.
+- `config set` / `config rewrite` — runtime server config changes (maxmemory, bind, requirepass). Can permanently alter server behavior or expose the instance. Never call.
+- `shutdown` — terminates the Redis process. Never call.
+- `debug` / `config resetstat` — operational risk, no legitimate use case via MCP.
 
 ## Redis Streams guidance (SOMA pattern)
 - Use XADD with MAXLEN ~ N to prevent unbounded stream growth in high-frequency producers

mcp/slack/permissions.json

@@ -1,16 +1,21 @@
 {
   "_template": "claude-kit/mcp/slack",
-  "_comment": "Read operations auto-allowed. Sending messages requires user prompt — messages sent via bot are visible to the whole channel/recipient.",
+  "_comment": "Read operations auto-allowed. Sending, editing, and reacting to messages requires user prompt — actions are visible to other users. Destructive and administrative operations always denied.",
   "allow": [
     "mcp__slack__list_channels",
     "mcp__slack__get_channel_history",
     "mcp__slack__get_thread_replies",
     "mcp__slack__search_messages",
     "mcp__slack__get_users",
-    "mcp__slack__get_user_profile"
+    "mcp__slack__get_user_profile",
+    "mcp__slack__add_reaction"
   ],
   "deny": [
     "mcp__slack__delete_message",
-    "mcp__slack__kick_user_from_channel"
+    "mcp__slack__update_message",
+    "mcp__slack__kick_user_from_channel",
+    "mcp__slack__archive_channel",
+    "mcp__slack__set_channel_purpose",
+    "mcp__slack__set_channel_topic"
   ]
 }

mcp/slack/rules.md

@@ -4,27 +4,60 @@ globs: "**/*"
 
 # Slack MCP Rules
 
-## Read operations (call freely)
-- `list_channels`, `get_channel_history`, `get_thread_replies`: message inspection
+## Read operations — call freely
+- `list_channels`: workspace channel index
+- `get_channel_history`: recent messages in a channel
+- `get_thread_replies`: thread inspection
 - `search_messages`: find relevant discussions
 - `get_users`, `get_user_profile`: team directory lookup
 
-## Sending messages — always show draft first
+## Sending messages — show draft first
+
 Before calling `post_message` or `reply_to_thread`:
 1. Show the full message text as a draft
-2. Confirm the target channel or thread
-3. Wait for explicit approval — sent messages are visible to others and cannot be unsent easily
+2. Confirm the target channel or thread (name + ID)
+3. Wait for explicit approval — sent messages are immediately visible to others
+
+Before `add_reaction`: state the emoji and target message. Reactions are visible and
+accumulate — don't add reactions automatically without user intent.
 
 ## Format and tone
 - Never add emojis unless the user includes them in the draft
-- Never use @here or @channel in automated messages without explicit instruction
-- Keep automated/bot messages clearly distinguishable from human messages
+- Never use `@here`, `@channel`, or `@everyone` in automated messages without explicit instruction
+- Bot messages must be distinguishable from human messages — never impersonate a user
+- Markdown formatting (bold, code blocks) is acceptable; decorative formatting is not
+
+## Editing messages
+
+`update_message` is denied by default. If re-enabled:
+- Only edit bot-authored messages — never edit messages posted by a human user
+- Show the before/after diff before calling
+- Require explicit user approval
 
 ## Privacy
+
 - Do not log or store message content from `get_channel_history` beyond the current task
-- Do not share content from private channels in responses unless directly relevant to the task
-- User profiles may contain personal info — use only for context, never expose unnecessarily
+- Private channels (`is_private: true`): only read if the user explicitly navigated to them —
+  do not proactively scan private channels during workspace exploration
+- User profiles may contain personal info (phone, email, timezone) — use only for
+  task context, never surface unnecessarily
+- Never forward channel content to external services during an MCP session
 
 ## Hard stops
-- `delete_message`: only on bot-authored messages. Never delete messages from other users.
-- `kick_user_from_channel`: always denied — administrative actions belong in the Slack UI.
+
+- `delete_message`: denied by default. If re-enabled, only on bot-authored messages,
+  require explicit confirmation, and never delete in bulk.
+- `update_message`: denied by default (editing messages from others is irreversible from
+  the recipient's perspective).
+- `kick_user_from_channel`: always denied — administrative actions belong in the Slack UI
+  or via the Slack admin API with proper audit trail.
+- `archive_channel`: always denied — permanently removes a channel from active use.
+  Requires workspace admin review.
+- `set_channel_purpose` / `set_channel_topic`: always denied — channel metadata changes
+  affect all members and should be intentional, not side effects of an automated session.
+
+## Channel scope
+
+When asked to "check Slack" or "look at Slack", default to the channels the user
+explicitly names. Do not iterate over all channels or read channel history broadly.
+Ask: "Which channel(s) should I check?"

mcp/supabase/config.json

@@ -1,8 +1,9 @@
 {
   "_template": "claude-kit/mcp/supabase",
-  "_verified_with": "@supabase/mcp-server-supabase@0.x",
+  "_verified_with": "@supabase/mcp-server-supabase@0.7.0",
   "_install": "Merge the 'supabase' key into mcpServers in ~/.claude/settings.json. Set SUPABASE_ACCESS_TOKEN env var (create at supabase.com/dashboard/account/tokens).",
   "_note": "This template uses the Supabase management API server, which operates on projects and their schema. For direct SQL on a specific project, combine with mcp/postgres/ using the project's DATABASE_URL.",
+  "_read_only_variant": "For production read-only access, add '--read-only' to args. This restricts the server to non-destructive operations only.",
   "supabase": {
     "type": "stdio",
     "command": "npx",

mcp/supabase/rules.md

@@ -35,3 +35,19 @@ Any operation that modifies schema or data requires showing the full operation a
 - When creating or modifying tables, always ask: "Should this table have Row Level Security enabled?"
 - Never disable RLS on an existing table without explicit user instruction
 - Review Edge Function code for secrets before deploying — never log tokens or keys
+
+## Read-only mode for production
+
+The server supports a `--read-only` flag that restricts it to non-destructive operations.
+Recommended pattern:
+
+- **Development/staging config**: use the standard template (no `--read-only`)
+- **Production config**: add `"--read-only"` to the `args` array in mcpServers
+
+```json
+"args": ["-y", "@supabase/mcp-server-supabase@0.7.0", "--access-token", "${SUPABASE_ACCESS_TOKEN}", "--read-only"]
+```
+
+With `--read-only`, `apply_migration`, `execute_sql` (writes), `create_branch`, and
+`merge_branch` are unavailable at the server level — not just behavioral restrictions.
+Use this as a hard enforcement layer for production access tokens.