mysql-audit
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| review_migrationA | Review MySQL DDL or a migration script for locking, data-loss and replication risks. Args: sql: The SQL to run, one or more statements separated by semicolons. schema: Optional CREATE TABLE statements for the tables involved (e.g. from SHOW CREATE TABLE). Makes column-type and index checks exact. stats: Optional size per table from information_schema.tables: a row count ({"orders": 25000000}) or {"orders": {"rows": 25000000, "data_bytes": <data_length>, "index_bytes": <index_length>}}. Large = 1M rows or 5 GB. mysql_version: Optional target server version, e.g. "8.0.28", "8.4.3" or "aurora-3.04" (SELECT VERSION()). Older servers copy the table for more column changes. Without it, 8.0.29 or later is assumed. free_disk_gb: Optional free space on the server's data volume, in GB. With byte sizes in stats, a table rebuild that does not fit is blocked. rollback_sql: Optional down migration kept in a separate file (e.g. a golang-migrate .down.sql or Flyway U__ file). Down sections and --rollback lines inside sql are found without it. Returns a verdict (safe / review / block) and findings with line, impact and fix. |
| review_queryB | Review queries an application will run (SELECT / UPDATE / DELETE / INSERT) for missing indexes, unbatched writes and unsafe UPDATE/DELETE. Pass schema for index checks. Returns a verdict (safe / review / block) and findings with line, impact and fix. |
| review_codeA | Check application source code (Python, JS/TS, PHP, Go, Java) for SQL built by string interpolation or concatenation, i.e. SQL injection. Returns a verdict (safe / block) and findings with line and the parameterized fix. |
| preflight_checksA | SQL for the user (or DBA) to run on the primary right before deploying a migration: long transactions, long queries and metadata locks on the tables it touches, current table sizes, and how to check replica lag. Each query returns rows only when the deploy should wait. This tool does not connect to the database; hand the SQL to the user. Args: sql: The migration that is about to run. mysql_version: Optional server version, e.g. "5.7.44"; picks SHOW SLAVE / REPLICA STATUS. |
| explain_ruleC | Explain one rule (e.g. "L02"): why it matters and a safe example. |
| list_rulesA | List every rule this server checks, with its id, title and default severity. |
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 6 tools
The three review tools are separated by input type (DDL/migration, DML queries, application source code), and their descriptions make these boundaries explicit. preflight_checks, explain_rule and list_rules are clearly distinct. Minor residual risk that an agent passes query text to review_code or vice versa, but descriptions mitigate this well.
All names are snake_case and mostly follow a verb_noun pattern (review_migration, review_query, review_code, explain_rule, list_rules). preflight_checks is the one noun-only outlier, but it is still readable and consistent in style.
Six tools is well-scoped for an audit/lint server: three analysis entry points, one pre-deploy checklist generator, and two rule-discovery helpers. Each tool has a clear reason to exist with no filler.
The surface covers the full audit lifecycle: migration review, query review, injection scanning, pre-deploy checks, and rule discovery/explanation. The only gaps are that nothing connects to the database itself (a deliberate design choice stated in preflight_checks) and there is no way to inspect live schema or existing table state directly.