Launchpad & MCP Hub
How do independently built tools become a system that is understandable to operate?
- Application registry
- Launcher
- Health & logs
- MCP hub
- Tool backends
Two connected problems
A growing collection of internal apps needs discovery, authentication, health checks, and a repeatable deployment path. Agents also need a consistent way to discover tools exposed by different MCP servers.
What I built
The personal launcher uses a project registry and deployment manifests to manage app lifecycles, logs, health checks, and persistent data. A separate MCP hub aggregates tools, prompts, and resources behind one endpoint and provides a browser inspector.
The engineering decisions
The registry describes what should exist; runtime state describes what is actually running. The hub handles eager and lazy backends, bounded restart behavior, and explicit tool-name collisions. A registered URL alone is not a successful deployment.
Related work at Slice
I’m applying the same focus on discoverability and maintainability to Slice Consulting’s internal platform: shared applications, AI integrations, repository conventions, and continuous integration.