documentation
04 admin

Dev tools

Three surfaces for the times when the normal dashboard views aren't enough. Run E2E scenarios against a live Exolvra instance, invoke any tool by hand, and inspect the raw runtime state. Use these when you're debugging, not demoing.

What this page is for

Most of the time you run Exolvra from the regular pages — chat, issues, agents, analytics. But when something is behaving strangely and the normal views don’t show you enough, you need surfaces that dig one layer deeper. That’s what the Dev Tools hub is for.

Opening /admin/tools shows three cards: Test Runner, Tool Playground, and Debug. Each targets a different kind of diagnostic question.

The three tools

ToolBest forSkill required
Test Runner”Does Exolvra actually work end-to-end?”Low — click a button, watch scenarios pass
Tool Playground”What does this tool do when I hand it exactly these arguments?”Medium — you need to know tool schemas
Debug”What’s the actual runtime state of the process right now?”High — raw internals, no handrails

Test Runner

The Test Runner at /admin/test-runner runs E2E scenarios against the running Exolvra instance. It exercises the full stack — HTTP, websockets, database, tool execution — and reports pass/fail with timing. Scenarios cover the golden paths: creating an agent, assigning an issue, sending a chat message, installing a skill. Run it after a config change or before a big demo to make sure nothing broke.

This page also hosts the demo mode toggle. When demo mode is on, dashboard features that aren’t ready for public view are hidden, and the home page shows the onboarding carousel instead of the normal dashboard. Turn it off for day-to-day use; turn it on if you’re showing someone around.

Tool Playground

The Tool Playground at /admin/test-tools lets you invoke any registered tool directly with JSON arguments. Pick a tool from the dropdown, paste the arguments, click Run, see the result. It’s the equivalent of a REPL for tools.

Use it for:

  • Debugging tool schemas — when you’ve written a new tool and you want to confirm the parameter types work
  • Reproducing a failure — when a tool call in an agent turn is returning a weird result, re-run it with the same arguments here to isolate the tool from the agent
  • Seed data / cleanup — one-off invocations of file system, data store, or task board actions to prep a clean state

This is not the place to do actual work — use it for diagnostics only. Tool invocations from here are logged in the audit log the same as agent-invoked calls.

Debug

The Debug page at /admin/debug is the lowest-level surface. It dumps runtime state: loaded providers, configured channels, active sessions, registered tools, feature flags, the resolved configuration tree. Use it when you want to confirm what the process actually sees rather than what the UI claims.

Common questions it answers:

  • “Did my provider key actually get picked up?” — look in the Providers section
  • “Is this feature flag on in this environment?” — look in the Flags section
  • “Is the MCP server I installed actually registered?” — look in the Tools section

Debug is admin-only and read-only. Nothing on this page changes state — it’s purely for inspection.

Common pitfalls

Running the Test Runner against production. The scenarios create and delete test data. Run them against staging, or against a scratch deployment, not against a live multi-user instance.

Leaving demo mode on. Demo mode hides half the dashboard. If someone reports a “missing page,” check this first.

Using the Tool Playground to do real work. Playground calls are real calls — they cost real money, they hit real APIs, they mutate real data. Scope your testing carefully.

Reading runtime debug output as gospel. Debug shows the process’s in-memory state. Config changes that haven’t reloaded, or tools that are loaded but disabled, can look contradictory. Cross-reference with the actual files and the audit log if something looks off.

Where to go next