Dostęp do bazy danych: SQL i NoSQL

Twoje AI pisze interfejs User z pamięci i jest błędny: zgaduje, że email jest non-null, pomija kolumnę miękkiego usuwania deleted_at i typuje created_at jako string, podczas gdy to timestamptz. Dziesięć minut później debugujesz zablokowane zamówienia, a AI radośnie proponuje zapytanie do tabeli payment, która tak naprawdę nazywa się payments. Obie wpadki mają tę samą przyczynę — AI zgaduje Twoje dane, zamiast je czytać.

Serwer MCP bazy danych zamyka tę lukę. Gdy AI potrafi już zinspekcjonować schemat i uruchamiać zapytania read-only, dwa codzienne przepływy pracy przestają boleć: zamienianie prawdziwej tabeli w poprawny kod aplikacji oraz ściganie błędu w danych za pomocą żywych zapytań zamiast ręcznie pisanego SQL-a. Ta strona dotyczy właśnie tych dwóch przepływów. Pełne menu serwerów MCP dla baz danych oraz instrukcje instalacji każdego z nich znajdziesz w Serwery MCP dla baz danych SQL i NoSQL.

Co z tego wyniesiesz

Powtarzalny przebieg generowania dokładnego modelu danych z żywej tabeli, w Cursorze, Claude Code i Codeksie
Pętlę debugowania na żywych danych, która znajduje winne wiersze w kilka minut
Prompty do skopiowania dla obu przepływów pracy
Postawę bezpieczeństwa „tylko do odczytu”, która sprawia, że te przepływy można bezpiecznie uruchamiać na stagingu

Szybka konfiguracja

Te przepływy zakładają, że podłączony jest jeden serwer MCP bazy danych. Minimalna konfiguracja Postgres przez Prisma jest poniżej; podmień ją na MongoDB, SQLite lub Supabase z referencji serwerów MCP dla baz danych. Cursor i Claude Code dzielą ten sam JSON mcpServers; Codex używa TOML [mcp_servers.<id>], gdzie stdio jest implikowane przez command.

{
  "mcpServers": {
    "prisma": {
      "command": "npx",
      "args": ["-y", "prisma", "mcp"]
    }
  }
}

claude mcp add prisma -- npx -y prisma mcp

[mcp_servers.prisma]
command = "npx"
args = ["-y", "prisma", "mcp"]

Przepływ 1: Wygeneruj model danych z żywej tabeli

Potrzebujesz modelu User, który dokładnie odpowiada tabeli users — a nie najlepszemu zgadywaniu AI.

Każ AI odczytać prawdziwy schemat. Inspekcja w pierwszej kolejności oznacza, że wygenerowany kod jest oparty na rzeczywistych kolumnach, typach i nullowalności.

Prompt do skopiowania — inspekcja tabeli:
“Use the database MCP to inspect the users table. List every column with its exact type, nullability, and default. Call out the primary key, any unique constraints, and any soft-delete or status columns. Do not generate code yet — just report the schema.”
Wygeneruj model z tego kontekstu. Teraz AI ma prawdę w kontekście, więc typy się zgadzają.

Prompt do skopiowania — generowanie otypowanego kodu ze schematu:
“Based on the schema you just read, generate a TypeScript interface for User plus a Zod schema that validates a row from that table. Match nullability exactly (nullable columns become optional/null), map timestamptz to Date, and add a short comment on any column that is a soft-delete or status flag. Do not invent columns that are not in the schema.”

Wynik pasuje do Twojej tabeli, bo został wygenerowany z Twojej tabeli — kolumny nullowalne są opcjonalne, znacznik czasu jest typu Date, a deleted_at jest udokumentowany, a nie pominięty.

Przepływ 2: Debuguj na żywych danych

Część zamówień się zablokowała i podejrzewasz dane, a nie kod. Zamiast ręcznie pisać join, opisz objaw i pozwól AI zbudować oraz uruchomić zapytanie.

Opisz zły stan zwykłym językiem. AI przekłada go na SQL, uruchamia przez serwer MCP (tylko do odczytu) i pokazuje Ci winne wiersze.

Prompt do skopiowania — tropienie złych wierszy:
“Using the database MCP, find every order created in the last 24 hours with status = 'pending' that has no matching row in the payments table. Return order id, customer id, created_at, and total, sorted oldest first. Show me the exact SQL you ran so I can sanity-check the join.”

Poproszenie go o wydrukowanie uruchomionego SQL-a to różnica między czarną skrzynką a narzędziem, któremu można ufać — sam weryfikujesz logikę joina, zanim uwierzysz w wynik.
Odbij się od dowodów. Mając w ręku konkretne ID zamówień, możesz zawęzić dalej bez przepisywania czegokolwiek ręcznie.

Prompt do skopiowania — zagłębienie się w ustalenie:
“For those stuck orders, check the payment_attempts table for any failed attempts in the same window. Group by failure reason and count. If a single error code dominates, summarize what it means and which orders it explains.”

Zdiagnozowałeś główną przyczynę na żywych danych, bez wychodzenia z edytora i ręcznego pisania wielotabelowego joina — a ponieważ użytkownik jest tylko do odczytu, nic z tego nie mogło niczego zmutować.

Gdy coś się zepsuje

AI odpytuje tabelę lub kolumnę, która nie istnieje. Wciąż zgaduje zamiast inspekcjonować. Wymuś krok 1: każ mu odczytać schemat, zanim napisze jakiekolwiek zapytanie, i potwierdź, że serwer MCP jest faktycznie podłączony (klient powinien wylistować jego narzędzia).

Uruchamia UPDATE lub DELETE, gdy chciałeś tylko SELECT. Użytkownik bazy danych ma zbyt wiele uprawnień. Utwórz dedykowaną rolę tylko do odczytu dla dostępu MCP — to najważniejsze zabezpieczenie dla obu przepływów.

Inspekcja schematu zwraca nieaktualne wyniki po migracji. Niektóre serwery MCP cache’ują metadane schematu. Zrestartuj serwer, by odświeżyć cache, a potem ponów prompt inspekcyjny.

Zapytanie przekracza timeout na dużej tabeli. Skany analityczne mogą przekroczyć timeout narzędzia serwera. Dodaj indeks, dodaj ciaśniejszą klauzulę WHERE lub poproś AI o LIMIT i paginację.

Co dalej

Serwery MCP dla baz danych Pełna konfiguracja dla Prisma, Supabase, MongoDB, SQLite i dbhub z konfiguracjami dla trzech narzędzi.

Budowanie niestandardowych serwerów MCP Opakuj wewnętrzne API lub zastrzeżony magazyn danych we własny serwer MCP.