Context
Follow-up tracker requested by @affandar in the PR #18 review. The initial MCP server connects directly to PostgreSQL via DATABASE_URL, which is acceptable for the first cut and matches how the TUI connects today. The non-blocking ask is to expose the PilotSwarm management/API surface through the portal as HTTP endpoints, then allow the MCP server (and other clients) to talk to those endpoints instead of requiring direct database access.
From the review:
Non-blocking follow-up: the direct DATABASE_URL model is acceptable for this initial MCP server, and it matches how the TUI connects today. But please file a tracking issue for exposing the PilotSwarm management/API surface through the portal as HTTP endpoints, then allowing the MCP server to talk to those endpoints instead of requiring direct database access.
Without that, this MCP server will not work in deployments where the only supported interface to the PilotSwarm cluster is the portal. In that topology, users should not need PostgreSQL connectivity or database credentials on the MCP client/server side; they should be able to point the MCP server at the portal/API URL with portal-compatible auth.
Scope to track
- Define the portal HTTP API surface that mirrors today's
PilotSwarmManagementClient capabilities (sessions list/get, send command + read command response, model registry read/write, agent resources, subscription/notification stream).
- Decide auth model for portal-facing clients (token, header conventions, scoping) and how MCP/TUI clients pick it up.
- Add a portal-mode transport to the MCP server so it can be configured with a portal URL + auth instead of
DATABASE_URL; keep direct-DB as an option for local/dev.
- Versioning and deprecation policy for the portal API surface (path or header versioning, stability guarantees, what counts as breaking).
- Migration path for the TUI to consume the same portal API where it makes sense, so direct DB access becomes opt-in rather than the default.
- CI coverage: contract tests against the portal API and a portal-backed MCP integration test alongside the existing direct-DB path.
References
Context
Follow-up tracker requested by @affandar in the PR #18 review. The initial MCP server connects directly to PostgreSQL via
DATABASE_URL, which is acceptable for the first cut and matches how the TUI connects today. The non-blocking ask is to expose the PilotSwarm management/API surface through the portal as HTTP endpoints, then allow the MCP server (and other clients) to talk to those endpoints instead of requiring direct database access.From the review:
Scope to track
PilotSwarmManagementClientcapabilities (sessions list/get, send command + read command response, model registry read/write, agent resources, subscription/notification stream).DATABASE_URL; keep direct-DB as an option for local/dev.References