DBShield
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| db_statusA | Check DBShield security gateway status, active safety tier, and database connection. |
| db_describe_schemaB | Safely introspect database tables, column types, nullable flags, primary keys, and foreign key relationships. |
| db_queryB | Safely execute a SQL query through DBShield guardrails. Destructive DDL and unconstrained mutations without WHERE clauses are automatically intercepted and blocked. |
| db_dry_runA | Simulate a database mutation inside an auto-rollback transaction sandbox. Calculates blast radius, affected row count, and returns a short-lived authorization token if safe. |
| db_commitA | Permanently execute and commit a mutation previously authorized by 'db_dry_run'. Requires a valid, single-use commitToken. |
| db_explain_queryC | Analyze query execution plan (EXPLAIN) to detect sequential full-table scans, missing indexes, and performance bottlenecks. |
| db_audit_logA | Retrieve the security and compliance query audit trail, including blocked operations, risk scores, and PII redactions. |
| db_validate_migrationB | Analyze DDL migrations against zero-downtime safety rules, detect table-level locking risks (e.g. non-concurrent index creation), dangerous NOT NULL columns, and destructive column/table drops. |
| db_check_schema_driftA | Inspect database schema health, identify unindexed foreign keys causing cascade locks, and detect schema drift. |
| db_check_semantic_intentB | Compare stated user prompt intent against SQL AST target columns to detect unauthorized modification of sensitive privilege, financial, or credential columns. |
| db_distributed_dry_runB | Simulate atomic mutations across multi-store environments (e.g. PostgreSQL + Redis + SQLite) and receive a single distributed commit token. |
| db_distributed_commitB | Execute two-phase distributed commit across multi-store environments using an authorized distributed dry-run token. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Most tools have clearly distinct purposes: status, schema introspection, query analysis, audit, migration validation, and distributed commit are well separated. The main ambiguity is between db_query and the db_dry_run/db_commit pair, since db_query says it safely executes SQL and may appear usable for mutations that should go through the dry-run/commit workflow.
All names use a consistent db_ snake_case prefix and are generally readable. Most follow an action-oriented pattern, but db_status and db_audit_log are noun-style rather than verb_noun, which is a minor deviation.
Twelve tools is well-scoped for a database security gateway covering status, schema, query safety, audit, migrations, and distributed transactions. Each tool appears to earn its place without excessive overlap.
The surface covers the expected lifecycle for guarded database operations: status, introspection, query execution, dry-run authorization, commit, explain plans, audit logs, migration safety, schema drift, semantic intent checks, and distributed two-phase commits. No obvious lifecycle gap stands out for the stated security-gateway purpose.