platform-mcp-server
# Platform MCP Server
Serveur MCP (Model Context Protocol) **read-only** qui expose l'état de
[`multi-tenant-platform`](../multi-tenant-platform) et
[`golden-path-portal`](../golden-path-portal) à un agent IA (Claude
Desktop, ou tout autre client MCP).
➡️ Voir le [design doc](docs/design-doc.md) pour le contexte, et
[ADR-0001](docs/adr/0001-read-only-v1.md) pour la décision de rester
read-only en v1 (pas d'action possible sur le cluster depuis l'agent).
## Tools exposés
| Tool | Rôle |
|---|---|
| `list_tenants` | Liste les namespaces tenants, avec leur niveau PodSecurity |
| `get_tenant_pods` | Statut des pods d'un tenant (running, redémarrages) |
| `get_tenant_slo` | Disponibilité, error budget, latence p95 d'un tenant |
| `list_argocd_applications` | Statut sync/santé de toutes les Applications ArgoCD |
| `get_chaos_schedules` | Expériences de chaos actives d'un tenant |
| `list_catalog_services` | Services enregistrés sur le golden-path-portal |
## Prérequis
- `kubectl` configuré et pointant vers ton cluster k3s (le serveur hérite
de ton contexte local, pas de credentials séparés)
- Un port-forward actif vers Prometheus pour `get_tenant_slo` :
```bash
kubectl port-forward svc/monitoring-kube-prometheus-prometheus -n platform 9091:9090
```
- Node.js 18+ (pour `fetch` natif)
## Installation
```bash
npm install
```
## Utilisation avec Claude Desktop
Édite ta config Claude Desktop (`claude_desktop_config.json` — sur macOS :
`~/Library/Application Support/Claude/claude_desktop_config.json`, sur
Windows/WSL : vérifie le chemin équivalent dans les paramètres de
l'app) :
```json
{
"mcpServers": {
"platform": {
"command": "node",
"args": ["/chemin/absolu/vers/platform-mcp-server/server.js"],
"env": {
"PROM_URL": "http://localhost:9091",
"GOLDEN_PATH_CATALOG": "/chemin/absolu/vers/golden-path-portal/catalog.json"
}
}
}
}
```
Redémarre Claude Desktop. Tu peux ensuite demander directement :
> "Quel est l'error budget de team-a en ce moment ?"
> "Liste tous les services enregistrés sur la plateforme."
> "Est-ce que toutes les Applications ArgoCD sont saines ?"
Claude appelle les tools correspondants et répond à partir des données
réelles de ton cluster.
## Test manuel sans client MCP
```bash
node --check server.js # valide la syntaxe
node server.js # démarre le serveur (attend un client sur stdin)
```
## Pourquoi read-only (résumé)
Exposer des actions (suspendre un chaos, scaler un déploiement) à un
agent IA est une décision de sécurité à part entière — confirmation
requise, scope de permissions, audit trail. La v1 se concentre sur la
valeur immédiate (obtenir des réponses) sans ouvrir cette surface de
risque. Détail complet dans l'ADR-0001.
TDQS
Scored across 6 tools
Each tool targets a distinct resource (tenants, pods, SLO, ArgoCD applications, chaos schedules, catalog services) with clear descriptions. Even the tenant-specific tools (pods, SLO, chaos schedules) are differentiated by the resource they return, so there is minimal ambiguity.
The naming generally follows a list_/get_ prefix with resource names, but the pattern is not perfectly consistent: list_ is used for global resources while get_ is used for tenant-specific ones, and get_chaos_schedules omits 'tenant' from its name. Despite this minor deviation, the verb_noun structure is recognizable.
Six tools is a well-scoped number for a read-only platform observability server. The set covers the main platform resources without unnecessary bloat, and each tool serves a distinct purpose within the apparent domain.
The tool set covers listing and basic tenant-scoped queries but lacks any single-resource detail views (e.g., a specific ArgoCD app or catalog service) and any management/mutation operations. This limits the surface to read-only inspection, which may be intentional but leaves notable gaps for a 'platform' server.