Releases: AIops-tools/MySQL-AIops
Release list
v0.6.0
Fixed
undo applyreplays against the target the original write ran on. It dispatched the inverse against whatever target the caller named — in practice the config's first entry — while the write's own target sat unused in the undo record. On a multi-target config the inverse therefore ran against the wrong host; it only looks harmless because the resource usually is not there, but two hosts holding the same name and the inverse succeeds on the wrong one, silently. An explicitly named target still wins. Line-wide: all 24 copies had the identical defect. Caught live in container-host-aiops, where a stop recorded against a Podman target replayed against a Portainer one.
v0.5.0
Changed (BREAKING)
- Requires MCP SDK 2.0 (
mcp[cli]>=2.0,<3.0).mcp.server.fastmcpno longer exists in 2.0; the server is now built withMCPServerand reports its package version in the stdio handshake.
Fixed
undo applyworks from the CLI. Every write tool is imported lazily inside its own CLI command, so a CLI-driven undo ran in a process where the inverse tool was never registered and failed with "inverse tool is not registered" — for every write tool. Only the MCP entry point, which imports the whole server, worked. Found while live-verifying against a real cluster.- An undetermined outcome is audited
unknown, notok. The harness only classified a result as undetermined when the payload also carried anerrorkey, so a write that looked successful but had not been confirmed was recorded as a success. as_intrejects a bool rather than coercing it.boolsubclassesint, so a boolean would otherwise have been reported as a count. The conversion itself was already exact (no float round-trip), unlike the sibling copies fixed in the same sweep.
v0.4.0
Release notes — mysql-aiops 0.4.0
Previous release: 0.3.0.
BREAKING — the authorization layer is removed
This tool no longer decides whether a write is permitted. Read-only mode
(<PREFIX>_READ_ONLY), the graduated-approval / approver gate, and the
rules.yaml deny engine are all gone. Whether an operation runs is the
agent's judgement, or the permission of the account you connect it with — point
it at a read-only credential and the write fails at the server, the place that
actually owns the permission.
What the tool guarantees instead is that nothing is silent: every operation,
over MCP and the CLI alike, lands a row in the audit log — there is no
unaudited entry point. Destructive writes still capture their before-state and
record an undo token where a clean inverse exists.
- If you set
<PREFIX>_READ_ONLY=1, it now has no effect and the MCP server
logs a warning at startup. Restrict writes via the connecting account instead. <PREFIX>_AUDIT_APPROVED_BY/<PREFIX>_AUDIT_RATIONALEstill work, but are now
optional audit annotations — recorded on the row when set, never required.- The declared
risk_levelis carried into the audit row as a descriptive tier
(a label, not a gate).
The governance harness is now: audit (MCP+CLI, unbypassable) · runaway/budget
safety guard · undo recording · output sanitize. policy.py is a small
risk-tier classifier; governance/readonly.py is deleted.
v0.3.0
Release notes — mysql-aiops 0.3.0
Previous release: 0.2.2.
In this tool
kill_session/kill_queryrefuse this tool's own connection, andset_global_variablerefuses the globals that lock it out (init_connect,max_connections,read_only,skip_networkingand the rest).SET GLOBALtakes effect immediately, so a bad value stranded the undo behind a connection that could no longer be opened. The read path already filtered the tool's ownCONNECTION_ID(); the writes did not.- A connection lost mid-statement now raises a dedicated error and is audited as
unknown, noterror— the statement may have committed before the link died.
Every tool in the line: previews and undetermined outcomes
This release fixes three harness defects that were silently degrading the audit
trail and the undo store.
A write that loses its response is no longer recorded as a failure. The
harness assumed a sanitized error meant nothing had happened. That assumption is
false in exactly the case that matters most: when a write severs its own
connection, the request has already landed, the response cannot come back, and
the operation was recorded as status=error with no undo token created at
all. Transport-level failures are now audited as status=unknown, the result
says plainly that the operation may have taken effect and should be verified
before retrying, and a write that stashed its before-state has its inverse
recorded anyway — flagged effectVerified: false, which undo_list and
undo_apply both surface. Existing undo.db files are migrated in place; their
rows read as verified, which is accurate, since the old code only ever recorded
on the confirmed path.
A dry-run no longer writes an undo token. Previews were recording inverses
built from a before-state they never had: the undo callback's permissive default
filled the gap with a guess, producing a real, applicable token for an operation
that never happened.
A dry-run no longer demands a named approver. Requiring an approval in order
to ask whether something needs approval inverts what a preview is for. The tier
is still computed and still audited, so the preview can tell you an approver
will be needed; it just no longer refuses to answer. The write itself is gated
exactly as before.
The invariant, now stated: a dry_run may read; it must never write. Guards
run on the preview path, which means a preview can and does report that an
operation would be refused.
Also line-wide
- Truncated text now ends in an ellipsis instead of being cut silently. This
line already treats a silent cut as a defect for lists; it was doing exactly
that to strings. - Error messages are capped at 800 characters, not 300. These messages end
with what to do instead, so the cap was removing the most useful sentence of
every long refusal.
v0.2.2
Release notes — mysql-aiops 0.2.2
Previous release: 0.2.1.
Live-verified: MariaDB
No behaviour changes. The MariaDB flavor branch was the largest verification debt in
this repo and had never been run against a live server. It has now been exercised
against MariaDB 11.8.8:
- Flavor correctly detected as
mariadb; the MariaDB-specific paths
(SHOW SLAVE STATUS,information_schema.innodb_lock_waits) execute and return
well-shaped data. analyze lock-waitson real contention: with two transactions deliberately
fighting over one row, it correctly identified the root blocker (the session
holding locks while waiting on nobody), the blocked session, an 18-second measured
wait, and named the exact tools to resolve it.- With
performance_schema = OFF,doctorreports it as a limitation and says how
to enable it — no driver traceback, exactly as the checklist requires. - All 16 commands return well-formed JSON, including the
Decimalaggregate path
fixed in 0.2.1.
See docs/VERIFICATION.md. Replication against a real replica
remains unverified.
v0.2.1
Release notes — mysql-aiops 0.2.1
Previous release: 0.2.0.
Fixed: server databases crashed against a real server
SUM() aggregates come back from MySQL as decimal.Decimal, which json cannot
encode — so server databases raised
TypeError: Object of type Decimal is not JSON serializable on every live server.
The mock suite could not see this: its fixtures returned plain ints.
Numeric aggregates now go through a shared as_int() helper, and the regression test
models the driver's real types. Absent stays None rather than becoming 0 — an
unknown count and a zero count are different facts.
Live-verified
This release was exercised end-to-end against a real MySQL 8.4.10 server: reads
cross-checked against the mysql client, analyze slow-query on genuine full scans,
the full governance loop (real create_index → audit row → undo_apply actually
dropping it), and both layers of read-only mode. See
docs/VERIFICATION.md for what is confirmed and what is still
open — MariaDB remains mock-only and is now the largest gap in this repo.
v0.2.0
Release notes — mysql-aiops 0.2.0
Previous release: 0.1.0.
Headline: read-only mode
export MYSQL_READ_ONLY=1With this set the 9 write tools are never registered — an MCP
client lists 26 tools instead of 35. The writes are not hidden
behind a flag and not merely refused on call: they are absent from the session,
so a model cannot invoke one and cannot be argued into one. For a reviewer this
is checkable rather than promised — connect, list the tools, and the writes are
not there.
Enforcement is two layers deep: the @governed_tool harness refuses every
non-read operation (covering the CLI and in-process callers too), and the MCP
server removes write tools from list_tools(). Changing entry point does not
get around it.
BREAKING — return shapes changed
This release changes payloads that callers may be parsing. Both changes exist
to stop a result from misrepresenting itself:
- Absent fields are now
null, not"". A missing value and an empty value
were previously indistinguishable, which invited consumers to invent the
difference. Keys are still always present — only the value may be null. - Anything with a
limitnow returns an envelope —
{"<items>": [...], "returned": N, "limit": L, "truncated": bool}. Truncation is
measured (one extra row is fetched), never inferred from the page happening to
be full. Where a genuine pre-cap total is knowable it is reported astotal;
where it isn't,totalis deliberately omitted rather than echoingreturned.
Also in this release
docs/VERIFICATION.md— what the mock suite actually guarantees, a live
verification checklist, and the criteria for claiming this tool verified.skills/mysql-aiops/references/agent-guardrails.md— for driving this tool with a
smaller / local model: which guardrails are now enforced for you, and a
ready-made system prompt for the rest.- Expanded operator playbooks in the skill documentation.
- The advertised tool count now matches what an MCP client actually lists
(it includesundo_list/undo_apply), and a release gate keeps it honest. - The
(preview)label has been dropped. It never meant unreleased; verification
status now lives indocs/VERIFICATION.mdwhere it can be specific.