feat(app): distinct connection states and per-invocation connection origin badges

[benjaminshafii]

Summary

Three UX defects from an enterprise ServiceNow debugging session:

1. Parts of the connections UI showed "not connected" for MCPs that were actually healthy — saved config, pending auth, healthy protocol session, and hard failure were conflated into a near-binary state.
2. With two similar connections enabled (cloud + direct ServiceNow), users could not tell which connection a chat tool call executed through, contaminating controlled comparisons.
3. The team's mock diagnostic MCP advertised incident-like tool names (lookup_incidents), easily confused with real ServiceNow tools during debugging.

What changed

1. Distinct connection states (desktop Settings → MCP / Connect)

New pure mapper connectionDisplayState() (apps/app/src/react-app/domains/connections/connection-display-state.ts) with unit-tested signal mapping:

Signal	State	Label
enabled === false or status disabled	disabled	Off
status needs_auth / needs_client_registration / needsAuth	auth_required	Needs sign-in
status connected (MCP initialize completed)	protocol_ready	Ready
status failed / failure signal	error	Error
config exists, no runtime status yet	configured	Set up, not started

mcp-view.tsx and connect-view.tsx render these as chips (colors matched to existing tones); i18n via static keys in en.ts. A degraded (recent tool failures) state was intentionally not added: no per-tool failure signal exists in McpStatusMap/engine sync today, and this PR does not invent new plumbing — noted for the diagnostics program (#2674) to supply.

2. Connection origin on every MCP tool invocation in chat

toolInvocationOrigin() (apps/app/src/lib/tool-invocation-origin.ts) parses dynamic tool names and renders a small badge beside the tool title in the generic tool renderer (components/ui/tool.tsx):

• direct MCP tools (<serverName>_<toolName>): badge shows the connection name (longest-prefix match against the session's known MCP servers, with a conservative fallback for unknown prefixes);
• openwork-cloud execute_capability calls: parses the name argument; mcp:<connectionId>:<toolName> renders as OpenWork Cloud → <connection> with the downstream tool as the title (connection name resolved best-effort from client-side data, otherwise the id — no new network calls);
• gated to dynamic-tool parts: built-in tools (bash, edit, ...) are completely unaffected.

3. Unambiguous synthetic tool names

Renamed incident-like mock tools to clearly synthetic names in packages/enterprise-mcp-mock-server (synthetic_servicenow_lookup, synthetic_servicenow_get_incident, synthetic_servicenow_summarize_incident, synthetic_servicenow_create_incident) and in ee/apps/diagnostics (synthetic_servicenow_lookup), with all referencing tests updated.

Deployment note: ee/apps/diagnostics serves diagnostic.openworklabs.com. Once deployed, scripts/runbooks that call the old lookup_incidents name (e.g. the manual verification steps on #2752) must use synthetic_servicenow_lookup. This rename is exactly the disambiguation the debugging session requested.

Testing

• apps/app: bun test --isolate tests/connection-display-state.test.ts tests/tool-invocation-origin.test.ts — 13 pass (every state mapping; direct MCP, OpenWork Cloud arg parsing, built-in passthrough, malformed args).
• pnpm --filter @openwork/app typecheck — clean.
• pnpm --filter @openwork/enterprise-mcp-mock-server test — 162 pass, 0 fail.
• pnpm --filter @openwork-ee/diagnostics test — 28 pass, 0 fail.
• pnpm --filter @openwork-ee/den-api exec bun test test/external-capabilities-search-divergence.test.ts — 17 pass, 0 fail (rename touch-point).
• Results reproduced independently by a second run after implementation.

No video/fraimz attached yet — stated explicitly per repo policy; the UI changes are covered by pure-function unit tests + typecheck, and a fraimz proof can follow up on request. Reviewer repro: (1) open Settings → MCP with a mix of enabled/disabled/needs-auth servers and observe distinct chips ("Ready", "Needs sign-in", "Off", "Set up, not started", "Error"); (2) run any MCP tool in chat and observe the connection badge beside the tool row; run an OpenWork Cloud capability and observe OpenWork Cloud → <connection>.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-app	Ready	Preview, Comment	Jul 14, 2026 9:08pm
openwork-den	Ready	Preview, Comment	Jul 14, 2026 9:08pm
openwork-den-worker-proxy	Ready	Preview, Comment	Jul 14, 2026 9:08pm
openwork-landing	Ready	Preview, Comment, Open in v0	Jul 14, 2026 9:08pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
openwork-diagnostics	Skipped		Jul 14, 2026 9:08pm