Un fapt incomod: Bicep respinge mai multe câmpuri specifice MCP pe care API-ul Azure API Center le acceptă. Dacă vrei să gestionezi un registru privat MCP ca și cod, nepotrivirea asta te blochează repede. După câteva servere, devine relevant.
Fluxul din portal e bun pentru demo. La 10+ servere și mai multe medii, ai nevoie de pull request-uri, detecția derivei, implementări repetabile și posibilitatea de a reconstrui dintr-un singur repo. Ghidul pe care îl rezum descrie o abordare concretă și funcțională pentru exact asta.
Ce contează tehnic
- API Center permite înregistrarea serverelor MCP ca active: endpoint-uri remote cu un URL runtime legat de un environment sau servere locale/bazate pe pachete descrise prin metadate de pachet. Portalul creează remotes și versiuni; dedesubt există un resource de tip APIs plus un copil deployments cu URL de runtime și environment.
- Problema: definițiile de tip ARM/Bicep nu includ toate câmpurile MCP utile în practică (remote, packages, elemente de auth/security). Serviciul le acceptă; Bicep le respinge la validare.
Abordarea care funcționează în practică
- Un JSON per server MCP. Name, title, summary, description (nu lăsa gol), kind=mcp, titlul versiunii, plus opționale vendor/icon/useCases/license/support. Pentru remote: URL runtime și indiciu de transport. Pentru pachete: registry/name/version/runtime hint și argumente. Aceste JSON-uri devin sursa unică de adevăr.
- Un modul Bicep reutilizabil (API 2024-06-01-preview) care:
- Creează workspace-ul și un environment.
- Materializează fiecare JSON ca un API de tip mcp.
- Când există remote, creează un copil deployments cu server.runtimeUri către URL-ul runtime și îl leagă de environment ca să apară în lista de servere.
- Încarcă JSON la compilare (fără fișiere de parametri) folosind încărcarea JSON din Bicep.
- Pentru a trece peste lipsa de tipuri, modulul înfășoară proprietățile în any/union ca să ocolească validarea la compilare, iar serviciul acceptă forma completă MCP.
- Un script PowerShell de deploy care rulează Bicep-ul și apoi face pruning: tot ce e în Azure dar nu e în JSON-uri e șters. Asta ține deriva la zero peste dev/test/prod.
Constrângeri și compromisuri
- Ocolirea tipurilor cu any() e un workaround tactic. Pierzi siguranța de schemă pentru a obține implementări reale. Așteaptă-te să revizuiești când evoluează tipurile RP.
- JSON-ul de registru vs. forma ARM nu sunt 1:1. Unele câmpuri se map-ează diferit față de schemele partenerilor. Testează riguros înainte de producție.
- Comportamentele portalului contează: un description gol face serverul invizibil în VS Code. Ține câmpurile de afișare obligatorii populate.
- Pruning șterge. Păstrează approvals și dry-run în CI ca să nu ștergi din greșeală active legitime când mută cineva fișiere sau redenumește.
- Serverele remote versus cele pe pachete vor evolua diferit. Streamable HTTP este direcția pentru majoritatea; SSE iese treptat din uz în ecosistem. Nu te ancora în transporturi ce pot fi deprecate.
Ce se schimbă pentru echipe
- Ai review pe fiecare adăugare/modificare de server, cu un workflow simplu „adaugi un fișier JSON”.
- Poți porni registre identice pe medii și reconstrui de la zero, util pentru DR și audit.
- Primești detecție reală a derivei și curățare automată, în locul unui registru doar în portal care adună resturi.
Ce aș urmări: schimbări în schema ARM a API Center care ar putea face hack-ul any/union inutil — sau l-ar putea strica. Protejează pasul de pruning cu allowlist explicit în primele rollout-uri. Și documentează în repo câmpurile minime obligatorii ca să eviți servere invizibile.
Mesajul practic: Dacă adopți MCP la nivel de organizație, tratează registrul ca infrastructură: JSON per server, modul Bicep care tolerează golurile de azi și un script de deploy care impune starea dorită cu un traseu de ștergere prudent.