Add auto-detected Tools and MCP Services views to the dashboard (into #354)

[TonsOfFun]

Why

The dashboard had no answer to "what can my agents actually do?" Tools appeared only as chips inside a single trace, and MCP servers appeared nowhere at all — despite agents already calling them.

Anything built on a hand-maintained registry would have been wrong the first time someone shipped a tool without updating it. So nothing here is registered: the inventory is derived from records the engine already stores.

Third in the stack: #353 → #354 → this. It targets #354's branch, so this diff is only the two new views; retarget as the ones below it merge.

Where the inventory comes from

ToolDiscovery merges four sources, because each sees a different slice of the same traffic:

Source	What only it can see
The offered tool roster — prompt.input.tools on traces, provenance["tools"] on solid_agent generations	Tools the model was given and never called; descriptions and parameter names
Telemetry tool spans	Timing, status, error rates — and agents running in a host app reporting over the wire
agent_generations.tool_calls	Calls the model requested, including ones whose run died before a span existed
agent_messages with role: "tool"	The arguments a tool was really invoked with, which telemetry truncates

A dashboard-executed run writes to several at once, so counting per-source would multiply-count it. Each feeds a distinct counter (calls / requested / results), telemetry stays authoritative, and installs with telemetry off fall back to the strongest signal present rather than reporting a table of zeros.

Agents' configured tools and mcp_servers are unioned in last, so "configured, never called" is visible — the difference between a tool that is broken and one that was never wired up.

MCP attribution

The mcp__server__tool convention, tagged onto spans at instrumentation time by the framework's ToolOrigin (first commit here) and re-derived on read for older traces. McpCatalog hints cover servers whose tools are exposed unnamespaced, and a dashboard builtin of the same name wins that tie, since the engine is the one running it.

Detection never depends on the catalog. A server nobody documented shows up the moment its traffic lands, flagged undocumented — those are precisely the ones worth surfacing.

The catalog, and starting a server

McpCatalog gives the MCP Services view a default set (Playwright, Filesystem, Fetch, Git, Memory, Sequential Thinking, GitHub, Slack, Postgres, and the dashboard's own /mcp), so an install sees what it could connect and not only what it already uses.

The six that need no host credentials can be started in a sandbox from the view; the rest are listed with what they would need, because there is nowhere safe to source those secrets from. SandboxSession records which servers it was launched with, so a running server reads as running instead of offering to start a second copy.

Portability and seams

• Scopes are passed into ToolDiscovery rather than derived, so the ownership seam decides visibility — the controllers pass owned_traces / owner_agents.
• Spans are read in Ruby, not traversed in SQL: jsonb traversal would be PostgreSQL-only. The provenance lookup takes the jsonb_exists fast path only when the adapter has it. The suite runs on SQLite.
• builtin_tools resolves lazily; referencing an autoloaded constant during class definition would bind whatever loaded first.

Two ownership bugs this turned up

Both were found driving the engine mounted in a real multi-tenant host, and neither is reachable from the single-user dummy app:

• SandboxSession declares owned_by :user, :account, so its owner association is :user — but current_owner is the account in multi-tenant mode. Assigning through the seam put an Account in the user association and raised AssociationTypeMismatch on every launch. Now assigned the way SandboxesController already does it: a sandbox belongs to whoever opened it.
• respond_to?(:account=) is true whenever an account model is configured, since the association is declared from configuration — but a host app's pre-existing table may not have the column, which raised MissingAttributeError. Assignment now checks the attribute exists.

Testing

• Engine suite: 77 runs, 0 failures on SQLite (33 new), rebased on One expandable-object design for traces, spans and interactions (into #353) #354
• Framework suite: 1274 runs, 0 failures — the 253 errors are the pre-existing missing-OPENAI_API_KEY ones, the same count Extract the dashboard into the actionagent gem, with feature parity #353 reports
• Verified in Chromium through a real mount: both views render in light and dark, row expansion and Tools↔MCP cross-linking work, and a Playwright sandbox launches and reports as running

Review notes

• actionagent/app/assets/builds/action_agent.js is rebuilt — committed on purpose so host apps skip the JS build. It was the only rebase conflict against One expandable-object design for traces, spans and interactions (into #353) #354, and is regenerated rather than merged.
• The mcp_servers column is added to the install generator's table template and to the dummy app's schema. Hosts mounting over pre-existing tables need their own migration (the platform's is Rate limiting options per agent or per action #104).
• The provenance["tools"] source stays inert until solid_agent ships Persist the offered tool roster on each generation's provenance solid_agent#5; the other three cover the feature meanwhile.
• The TelemetryTrace readers gained the JSON-Schema parameter flattening and llm.tools alias that had been living in a platform-side concern — there is one implementation now rather than two.