LogCarverGuard
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOGCARVERGUARD_READ_ONLY | No | true allows queries only | false |
| LOGCARVERGUARD_AUDIT_DB_PATH | No | Audit log SQLite file | LogCarverGuard/audit.db under your local application data folder |
| LOGCARVERGUARD_EXEC_WHITELIST | No | Stored procedures that may be EXEC'd | |
| LOGCARVERGUARD_CONNECTION_STRING | No | The login the statements run as | |
| LOGCARVERGUARD_TRUNCATE_ALLOWLIST | No | Tables where TRUNCATE is allowed | |
| LOGCARVERGUARD_CONNECTION_STRING_FILE | No | Path to a file containing the connection string | |
| LOGCARVERGUARD_ALTER_DROP_COLUMN_ALLOWLIST | No | Tables where DROP COLUMN is allowed |
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
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| execute_sqlA | Execute a SQL statement against the guarded database, under your own identity. Ordinary INSERT/UPDATE/DELETE/ALTER TABLE run and are audited. DROP TABLE, unapproved TRUNCATE, unapproved EXEC, and your own BEGIN/COMMIT/ROLLBACK TRAN statements are blocked before they ever reach the database - if blocked, the reason is returned so you can adjust and retry. A batch containing INSERT/UPDATE/DELETE runs in one transaction that is rolled back if any statement fails; DDL, TRUNCATE and EXEC run as they are and are not rolled back as part of a batch. When the server runs in read-only mode only queries are allowed and every other statement is blocked with a reason. |
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 1 tool
With only one tool, there is no possibility of selecting the wrong tool or confusing overlapping purposes. The single entry point has an unambiguous, well-bounded role: execute SQL under guardrails.
The lone name, execute_sql, follows the standard verb_noun snake_case convention cleanly. There are no other names to conflict with, so consistency is trivially satisfied.
A single tool is thin for a server with this much behavior (read-only mode, batch transactions, blocking rules, auditing). It is defensible as a unified SQL gateway, but the rubric treats 1 tool as borderline.
execute_sql is a complete interface for running and guarding SQL, covering DML, DDL, EXEC and transaction rules. Minor gaps exist: no dedicated tool to inspect the audit log, check current mode, or preview whether a statement would be blocked.