schema-guard-mcp
README.md
# Schema Guard — MCP server
A **Model Context Protocol** server that gives an AI agent (Claude Desktop, Claude
Code, or any MCP client) tools to **audit Postgres / Supabase SQL for security
issues** — mid-conversation, with structured results. Point it at a schema and it
flags missing RLS, permissive policies, broad grants, `SECURITY DEFINER`
search_path gaps, and secrets in client-readable tables.
Built to show MCP / agent tool-use, and tuned to the exact mistakes that
[no-code exports ship](../34-nocode-rescue) with.
## Tools it exposes
| Tool | What it does |
|------|--------------|
| `audit_sql` | Full audit of a SQL schema → ranked findings (severity, rule, line, fix) + verdict. |
| `rls_coverage` | Quick per-table yes/no of whether RLS is enabled. |
| `list_rules` | The checks it runs, with rationale. |
## Checks
`RLS-001` table without RLS · `RLS-002` RLS on but no policy · `POL-001` `USING (true)`
policy · `GRANT-001` broad grant to anon/public · `SECDEF-001` `SECURITY DEFINER`
without pinned `search_path` · `COL-001` sensitive column in a client-readable table.
## Run the live demo
```bash
npm install
npm run demo # spawns the server, does the MCP handshake, audits a sample schema
npm test # 10 assertions on the audit engine
```
The demo is a real MCP client (`@modelcontextprotocol/sdk`) speaking to the server
over stdio — the same handshake Claude performs. It finds **7 issues** (2 critical)
in `fixtures/vulnerable-schema.sql` and prints the fix for each.
## Wire it into Claude
**Claude Desktop** — `claude_desktop_config.json`:
```json
{
"mcpServers": {
"schema-guard": {
"command": "node",
"args": ["C:/path/to/35-schema-guard-mcp/src/server.js"]
}
}
}
```
**Claude Code** — `.mcp.json` in your project:
```json
{
"mcpServers": {
"schema-guard": { "command": "node", "args": ["./src/server.js"] }
}
}
```
Then just ask Claude: *“audit this schema for RLS gaps”* and paste your SQL — it
calls `audit_sql` and reports back.
## Stack
Node (ESM) · `@modelcontextprotocol/sdk` (stdio transport) · zod · zero external
services, deterministic output.
TDQS
A4.2/5.0
Scored across 3 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: comprehensive audit, quick RLS check, and rule listing. No overlap or ambiguity between tool responsibilities.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with lowercase and underscores (audit_sql, rls_coverage, list_rules). Naming style is uniform and predictable.
Tool Count5/5
Three tools is well-scoped for a focused SQL security auditing server. Each tool serves a necessary and non-redundant function without bloat or thinness.
Completeness5/5
The domain of static SQL security auditing is fully covered: full audit, quick subset check, and rule enumeration. No obvious missing operations for the server's stated purpose.
Maintenance
ActivityStale
ResponsivenessNo issues