Generates Oracle DAO, SOAP and MCP server code from a config file. This is the source drop for
2.0.14; the running article is the container image.
docker pull ghcr.io/srmadscience/mcpdbwizard:2.0.14
docker pull docker.io/srmadscience/mcpdbwizard:2.0.14
The image is now published to Docker Hub as well as ghcr.io, from one build tagged for both, so
the two are the same manifest digest by construction rather than by two builds. Prefer ghcr.io where
you have no reason not to: Docker Hub rate-limits pulls per source IP, so a CI runner or an office
NAT can exhaust the allowance without any one person pulling much.
What is new in 2.0.14
Generated MCP servers no longer advertise tools/list_changed, a notification they have never
been able to send.
The boolean in .capabilities(...tools(x)) is listChanged — ToolCapabilities is a record whose
single component is listChanged() — so every generated server answered initialize with
"tools":{"listChanged":true} and had no code path able to send one: the tool list is a fixed
Arrays.asList built once at construction. A client that believes listChanged has no reason to
poll tools/list again, because it expects to be told.
False is the true answer rather than a retreat from a feature: curation happens at generation time,
and an operation you did not select has no tool-spec method emitted at all, so a server's tool set is
fixed for the life of its process by design. Changing it means regenerate-and-restart, which a client
re-initializes against.
Also included: 2.0.13
2.0.13 was released as an image but its source was never exported, so this drop carries both.
Two writers could fill the config volume. The audit trail's MCP_AUDIT_FILE_MAX_BYTES caps one
directory, and a trail directory takes exactly one writer — so every generated server got its own and
each independently took the 512 MB default. The advertised cap was 512 MB per config, roughly
10.5 GB across the default port range. MCP_AUDIT_TRAIL_MAX_BYTES is now a budget for the whole
trail, divided among its writers.
Retention could not hold it back, and the reason matters: at a few hundred calls a second a directory
reaches its cap in hours rather than days, and the oldest segment is then evicted regardless of age
and counted as dropped. Filling the volume was the visible half; losing audit records inside the
promised window was the other. Watch the drop counters on Admin → Audit, not just the disk gauge.
Separately, server.log had no cap at all — one MCP-CALL line per tool call, growing for the life
of the process. It now rolls at 8 MB keeping one previous generation.