MCP server for the Apolo platform
Wellknown found it in public sources; nobody has proven control of it yet. Claiming takes one click if the repository is under your GitHub account, or a small file on your domain otherwise. Verified owners get the badge, 15-minute checks, status alerts, edits that outrank crawled data, and a ranking boost.
Agents can do it too: POST https://wellknown.network/api/v1/claims with {"agent":"apolo-mcp","method":"well_known_file"} — machine-readable steps at claim.json, guide at /docs/claim.
Everything here was measured by our prober or read from a registry. Nothing is self-reported.
Attributed to the source that supplied each field. Treated as claims, not facts.
# apolo-mcp `apolo-mcp` is a local stdio Model Context Protocol server for typed Apolo platform operations. It is a thin adapter over `apolo-sdk`: it never shells out to the CLI and uses the configured Apolo identity, permissions, and defaults. Local sessions normally come from `apolo login`; isolated jobs may use `APOLO_PASSED_CONFIG`. The server exposes bounded context discovery and typed platform operations. Every operational tool accepts explicit `cluster`, `org`, and `project` inputs where the SDK supports them; explicit inputs never modify the user's saved context. Secret values and one-time credentials are intentionally outside the model-visible interface. ## Installation Follow the [installation and client configuration guide](docs/getting-started/installation.md) for prerequisites, server and skill installation, Codex and Claude Code registration, per-session policy selection, and verification. Local stdio is the only supported transport; shared-credential remote service operation is unsupported. See the [Apolo MCP documentation](docs/README.md) for prerequisites, safety controls, the capability matrix, generated tools and skills catalogs, and task-oriented guides. ## Development ```console make setup make lint make test make build ``` Dependencies are locked with `uv.lock`. Tests use an `ApoloClientProvider` fake and do not require credentials. Integration tests, when added, must be opt-in and target an isolated non-production project. Wheel and source-distribution files are generated release artifacts and must not be committed. Tagged releases build them in CI and publish the exact outputs to PyPI via Trusted Publishing; local `dist/` contents are disposable. Maintainers should follow [RELEASE.md](RELEASE.md) for changelog, validation, signing, and publication. Release versions use `YY.MM.NN`: the two-digit year, the month without a leading zero, and a zero-based release sequence within that month. For example, `v26.7.0` is the first July 2026 …
Mapped onto the structured taxonomy from declared text and observed tool names. Confidence shown for derived entries.
Every source is kept verbatim. Field changes are logged as events.