JSON-RPC reference
The Dev UI talks to the runtime through a JSON-RPC service (GoblinJsonRPCService). The same service is available over the Dev UI’s built-in JSON-RPC bridge, which is useful for scripting or CI validation. All methods read or mutate the in-memory MutableAssaultConfig; in dev mode every mutation is also written to .goblin-state.json, which replaces the quarkus.goblin.assault.* and quarkus.goblin.target.level properties at the next start (the active flag is never persisted).
| Method | Effect |
|---|---|
|
Returns |
|
Returns the full mutable config (profile, toggles, client-side toggles, latency range, exception config, HTTP status config, response body config, response header rules under |
|
Enable/disable chaos entirely. Emits a WARN log. Deactivating chaos also cancels any pending auto-off; activating it keeps a pending one. When the auto-off deadline has just elapsed, |
|
Schedule chaos to switch itself off after |
|
Cancel the pending auto-off; chaos stays in its current state. Returns |
|
Activate a predefined composite assault mode ( |
|
Flip the corresponding assault toggle on/off. |
|
Flip the corresponding client-side assault toggle on/off (outgoing REST Client and Vert.x WebClient calls). |
|
Set the response body transformation ( |
|
Add or replace the rule applied to the named response header. |
|
Drop the rule configured for the named response header. |
|
Set the min/max latency range. |
|
Set the exception class name and message. The class must extend |
|
Set the HTTP status code and response body. |
|
Set the percentage of affected requests (clamped to 0-100). |
|
Kill switch: deactivates the engine (which cancels any pending auto-off), disables every assault type and client-side assault, and resets the profile to |
|
Restore every toggle and parameter to its built-in default value, not to |
|
Apply a (partial) config object: |
|
Return |
|
Reset the assault counters to zero. Returns |
|
Return the assault history buffer. Each entry exposes the method, type, timestamp, the applied latency duration ( |
|
Empty the assault history buffer. Returns |
|
Return |
|
List the saved scenarios ( |
|
Save the current assault configuration (every toggle and parameter, the armed layers and the target level, never the active flag) as |
|
Replace the whole assault configuration by a saved scenario, published at once (one |
|
Delete a scenario file, leaving the current configuration untouched; names are case-insensitive. Returns |
Every mutating method except resetCounters, clearHistory, startAutoOff, cancelAutoOff, saveScenario and deleteScenario returns the full configuration as JsonObject (the same shape as getConfig) plus ok, so the Dev UI treats the response as a single source of truth; a rejected call returns ok: false and an error (alone, or with the unchanged full config for applyConfig). For backward compatibility the setters also echo the values they changed as top-level keys: setLatencyRange (minMilliseconds, maxMilliseconds), setExceptionConfig and setHttpStatusConfig (type or code, message), setResponseBodyConfig (mode, percentage), setTargetLevel (level), setResponseHeaderInfo (name, action, value); getConfig itself only carries level at the top level.
|
Dev MCP exposure
Every method above is also a Quarkus Dev MCP tool, so an AI agent connected to /q/dev-mcp can call it (see Driving Goblin from an AI agent).
What decides the exposure is a single rule: a method carrying a @JsonRpcDescription is served to both the Dev UI and MCP, and a method without one stays in the Dev UI only. A blank description is not enough — it hides the method from both. A description is also the only documentation an agent gets, so every method and every parameter describes the action, the accepted values and what comes back.
Being described is not the same as being enabled. A method annotated @DevMCPEnableByDefault is handed to the agent as soon as the Dev MCP server is on; a method without it stays out of the agent’s tool list (tools/list only returns enabled tools) until a developer turns it on explicitly in the Dev MCP tools page of the Dev UI (Settings, the gear icon, then the Dev MCP tab, then Tools), the only place where disabled tools are listed. The descriptions of the read-only tools say so, so an agent that only sees them knows the arming tools exist and must be enabled by a human. The split follows one rule: reading the state or stopping chaos is enabled by default, arming or mutating chaos is opt-in.
| Enabled by default | Why |
|---|---|
|
Read-only. An agent can find out what is armed and what has already happened, which is the minimum needed to work with Goblin at all. |
|
Stopping chaos. An agent must always be able to arm a safety net and to shut everything down, without having to ask a human first. |
|
Read-only. An agent discovers the saved experiments, and what each one arms, before anything is enabled. |
Next to the tools, Goblin serves two Dev MCP resources, quarkus-goblin_agentPlaybook and quarkus-goblin_resilienceInventory, both read-only and enabled by default under the same rule. They are build-time data, not JSON-RPC methods: see Agent playbook.
Everything else is opt-in: the master switch (toggleActive and setActive), every assault toggle, every parameter setter, setProfile, resetDefaults, applyConfig, the scenario tools that load, save or delete a scenario (loadScenario arms the assaults the scenario holds, saveScenario and deleteScenario write to disk), and the two methods that throw away evidence (resetCounters and clearHistory). setActive stays opt-in even when it is called with false, because the same tool arms chaos too; disableAll is the tool that turns everything off, and it needs no prior configuration.
applyConfig takes a free-form configuration object, and the MCP schema generated for a free-form object documents none of its keys. Its description therefore spells out every accepted key, its type and its accepted values, which makes it the longest description of the service.
|
With Quarkus 3.38, a tool that takes two parameters or more shows the description of its first parameter instead of its own, in the Dev MCP tools page and in the tool list an agent receives: Quarkus reads the method description with a lookup that also matches the parameter annotations. This affects setLatencyRange, setExceptionConfig, setHttpStatusConfig, setResponseBodyConfig and setResponseHeaderInfo, which are all opt-in. Their parameter descriptions stay correct, and the tools behave as documented in the table above; none of the tools enabled by default is affected, since they take at most one parameter.
|