database-sentinel
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SENTINEL_DSN | Yes | PostgreSQL connection string for the read-only audit role (e.g., postgresql://sentinel_auditor.PROJECT_REF:PASSWORD@POOLER_HOST:5432/postgres) | |
| SENTINEL_REPO | No | Path to the repository to scan for exposed credentials (optional) | |
| SENTINEL_ANON_KEY | No | Supabase anon key used for anon-probe verification | |
| SENTINEL_REST_URL | No | Supabase REST URL (e.g., https://PROJECT_REF.supabase.co) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| run_audit_queryC | Run one allowlisted audit query (Q1..Q20 from audit-queries.md). |
| get_schemaD | Tables, views, columns, grants and functions in a schema. |
| probe_as_anonB | Check via PostgREST whether the anon key can read a table (row count only). |
| scan_repoA | Scan the configured repo for exposed service-role keys / JWT secrets (locations only). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| audit | Run a full Sentinel audit with your own LLM. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| anti-patterns | Supabase anti-pattern catalog: IDs, severity, detection, fixes. |
| fix-templates | Fix SQL templates. Show to the user; never run them. |
| auditor-role | SQL creating the read-only sentinel_auditor role. The user runs it, not the agent. |
TDQS
Scored across 4 tools
Each tool has a clearly distinct focus: running allowlisted audit queries, introspecting schema metadata, probing anon-key read access, and scanning a repo for secrets. Overlap is minimal, even though run_audit_query and get_schema both touch database information, because their actions and outputs are different.
All names use snake_case and begin with a verb, giving a readable, predictable pattern. Minor structural variation appears in run_audit_query and probe_as_anon, but conventions are not mixed.
Four tools are well-scoped for a focused database-security auditing server. Each tool covers a distinct security check, and none feels redundant or trivial.
The core security-auditing operations are represented: query-based checks, schema inspection, anon access probing, and repo secret scanning. However, there is no tool to list available audit queries, aggregate findings, or inspect other access-control details such as authenticated roles and policies.