Documentation
¶
Overview ¶
Package mcp exposes the builder over the Model Context Protocol, so an agent running anywhere — Claude Code, Codex, any MCP client — can read the issue board and talk to this fleet and its memory.
Two servers rather than one, because they have very different blast radii:
/mcp/feedback — the issue plane. File issues, read them, comment, move them.
/mcp/agents — the fleet: personas, skills, each agent's brain, and the
custom apps an agent can add to this builder mid-run.
A token wired into a shared editor should be able to file bugs without also being able to read what every agent has learned — or to put executable code on a dashboard screen — so the scope is part of the credential rather than a convention.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Service ¶
type Service struct {
// contains filtered or unexported fields
}
func (*Service) Routes ¶
Routes mounts both MCP servers and the token management the dashboard uses.
The two servers are separate URLs rather than one server with per-tool permission checks. A client asks a server what it can do; if the answer depended on the token, the same URL would advertise different capabilities to different callers, and an operator reading the connect instructions could not tell what they were about to grant.
func (*Service) SetApps ¶ added in v0.2.0
func (s *Service) SetApps(a *customapps.Service)
SetApps hands the MCP surface the live custom-app registry.
Injected rather than constructed here because there is exactly one registry per process and it is the one serving /api/builder/apps: a second Service pointed at the same directory would scaffold into the right place and then rescan the wrong instance, so the app would be on disk and absent from the launcher until a restart. The apps provider boots after this service is built, which is why this is a setter and not a constructor argument.