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, Claude Code, and Xum 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…
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.