Read-Only Protection in MCP Database Servers: Classifier Blind Spots and Defense-in-Depth

Background: Model Context Protocol (MCP) servers are adopted by 30+ AI assistants to connect LLMs to external data; database servers that advertise a read-only role are among the most security-sensitive, because a bypass turns an AI agent into a database writer. Problem: existing work catalogs vulnerabilities across the MCP ecosystem but does not measure how read-only is implemented, nor why two implementations facing the same blind spot end up with different outcomes. Method: we define a three-layer model of read-only protection (L1 statement classification, L2 role-based authorization, L3 execution-level read-only enforcement), audit six database-facing MCP servers, and measure each layer with real PostgreSQL 16.15 runtime differential experiments plus a purpose-built 11-pattern static detector. Results: we confirm one exploitable authorization defect (CWE-863/281, 77-star repository) where SELECT * INTO is classified as SELECT by sqlparse.get_type(), letting a writer role create tables; we show defense-in-depth (L3 conn.read_only=True) turns the same blind spot harmless in a second server, while a third server with recursive keyword scanning (incl. INTO) rejects it outright. Six detector iterations (v4-v7d) drive the false-positive rate from 40 to 0 findings on four audited repositories with zero recall loss. Impact: we provide the L1/L2/L3 model, a reproducible measurement protocol (incl. the transaction-semantics trap that rolls back uncommitted writes), and an open 11-pattern detector sustaining both precision and recall.