Database MCP best practices

Custom MCP servers let the assistant call tools your systems expose — including databases (for example Supabase, Postgres, or a thin SQL MCP in front of your warehouse). Done well, visitors can ask “where is my order?” and get a real answer. Done poorly, a public chat can over-share customer data. This guide covers how to connect a database MCP safely in Concierge.

What this is (and is not)

• Is: a remote MCP server (HTTPS Streamable HTTP) linked under Integrations → Custom MCP servers, with tools approved per workspace.
• Is: optional public-chat access so the website widget (or selected messaging channels) can call only the tools you name.
• Is not: Concierge’s private database modules or a custom tool you build in code — this path is the generic MCP connector.
• Is not: automatic safety. SQL tools can read whatever the server credentials allow; policy lives in tool choice, approval, and Directives.

Recommended architecture

1. One operational database (or replica) that holds orders, appointments, tickets — the system of record the support agent should query.
2. Stable lookup keys customers already know: order number, booking code, tracking code, ticket id — not “search all customers by first name”.
3. Views for support (for example order status with latest shipment, appointment with technician first name only) so the model does not need complex multi-join SQL every turn.
4. Clear column comments or a short schema note in Directives so the agent knows where to look.
5. Sensitive fields kept out of answers: internal notes, full tax ids, technician personal phones, other customers’ rows.

Connect the server

1. 1
   Open Integrations

   Go to Integrations → Custom MCP servers → Add MCP server. Use HTTPS Streamable HTTP only on hosted Concierge.

2. 2
   Authenticate

   Bearer token, custom headers, or OAuth as your MCP provider requires. Secrets are stored encrypted; leave the secret blank on later edits to keep the current value.

3. 3
   Choose member access

   Admins only is the safe default for database tools. Expand to selected roles only when support staff need the same tools in the console assistant.

4. 4
   Save and connect

   Concierge discovers tools and quarantines them until you approve each one. Schema changes on refresh can re-quarantine a tool — re-approve after intentional updates.

Approve tools deliberately

• Approve list_tables (or equivalent schema discovery) and read-only query tools first.
• Leave write / migration / admin tools unapproved for public chat. Prefer not approving them for members either unless ops truly needs them in chat.
• After Save, enable Public chat only when you are ready: pick channels (start with Website widget) and tick Public chat on each approved tool that visitors may use.
• Public chat never inherits member policy — you must opt in per tool and channel.

Directives that make free-form SQL safe enough

Visitor Directives (Directives page) apply to public channels and the Test chat visitor surface. They do not change how the console assistant talks to your team. Write permanent rules such as:

• Use MCP only for operational lookups (order, tracking, installation OS, stock, RMA, ticket, payment status). Prefer support views when they exist.
• Before address, phone, paid amount, or other private fields: require order_number (or os_number) AND email or phone on file.
• Wrong contact: refuse without revealing the real account holder.
• After a failed check, if the visitor corrects with valid order + email/phone: re-run the SQL lookup — do not stop at “not in the knowledge base” or handoff only.
• Never SELECT * FROM customers without a tight filter; never quote notes_internal; never list other customers’ orders.
• Catalog/stock questions (availability by SKU/store) can answer without identity when data is non-personal.

Visitor vs console assistant

• Visitor (widget / messaging with public tools): identity gate + narrow tools. Expect refuse on bulk dumps and third-party data.
• Console assistant (topbar “Work with your assistant”): workspace Directives for visitors do not apply. Admins with MCP member access can run broader SQL for ops — treat that as operator privilege, not public support policy.
• Test chat embeds the real visitor widget. Use “Start new conversation” between personas so you rehearse cold visitors, not one sticky test identity.

Rehearse before go-live

• Happy path: order number + correct email → status and tracking (or OS) match the database.
• Partial path: “where is my order?” with no id → agent asks for order number (and contact).
• Adversarial: order only → address/phone refused until contact verified.
• Wrong email for a real order → deny without leaking the owner’s data.
• Correct email after a wrong one → re-query succeeds (not only handoff).
• Dump attack: SELECT all customers / notes_internal / other people’s orders → refuse on public chat.
• Stock/catalog question without identity → allowed if non-personal.
• Admin console: confirm ops can query when member MCP is on (different posture is expected).

Security checklist

• Database credentials are read-only for any tool exposed to visitors.
• Public chat enabled only on the channels you intend (often widget first).
• Write and migration tools not approved for public chat.
• Directives cover identity, re-lookup after mismatch, and no bulk/third-party dumps.
• Internal notes and PII columns never intended for visitor replies.
• Someone can disable the MCP server or revoke public tools in one place if something goes wrong.
• Privacy mode (when enabled) treats MCP as an untrusted sink — plan prompts accordingly.

Common mistakes

• Approving every discovered tool “for convenience”, including apply_migration.
• Enabling public chat without naming tools — nothing reaches visitors until Public chat is ticked per tool.
• Relying only on the model’s good manners without Directives.
• Using one Test chat persona for many scenarios so prior context leaks into the next rehearsal.
• Expecting visitor Directives to constrain the console admin copilot (they do not).

Related guides

• Rehearse in the Test chat: run scripts before real traffic.
• Admin: bring your workspace live: knowledge, persona, channels, go-live.
• Human handoff: when a person must continue after policy or failed lookup.