Azure MCP-server

Kort fortalt

Dette er ikke en teori-artikkel. Dette er en demo med tenner: Azure MCP-serveren starter, svarer på HTTP og håndterer MCP-forespørsler uten å be om unnskyldning.

Poenget er enkelt, men ikke akkurat pyntelig: Jeg viser hvordan Azure-informasjon kan eksponeres gjennom et ryddig protokoll-lag, og hvorfor det faktisk er nyttig i et landing zone- eller plattformoppsett.

Dette lærer du

Etter å ha lest saken skal leseren vite:

• hva er Azure MCP-serveren
• hvordan startes den lokalt
• hvilke HTTP-endepunkter som finnes
• hvordan ser ut MCP-protokollen i praksis
• hvilke Azure-spesifikke verktøy og ressurser serveren eksponerer

Hva er dette egentlig?

Azure MCP-serveren er en TypeScript-basert implementasjon av Model Context Protocol for Azure landing zone-scenarier. Den fungerer som et standardisert grensesnitt mellom en klient og Azure-relaterte operasjoner, slik at AI-assistenter og automatiseringsverktøy kan spørre etter ressurser, validere Bicep, følge deploy-status og lese plattformdata på en strukturert måte.

Det interessante er ikke bare at serveren kjører. Det interessante er at den gjør Azure-informasjon tilgjengelig gjennom et tydelig og testbart protokoll-lag. Det er akkurat derfor den egner seg så godt som bloggcase.

Fyr opp lokalt

Vi begynner med det mest konkrete: å bygge og kjøre serveren lokalt.

powershell

cd azure-mcp-server

npm run build

npm run dev

`npm run build` kompilerer TypeScript-koden til `dist/`, mens `npm run dev` starter serveren direkte fra kildekoden. Det er helt greit for demoen, men det som teller er at du får tydelig output i terminalen og kan vise at serveren faktisk starter.

Vil du vise produksjonsvarianten, bruker du:

```powershell

npm start

Når serveren starter, ser terminalen slik ut:

Bilde1: terminalen med oppstartsbeskjeden og porten 

Bilde2: express laget er tilgjengelig

Bilde3: responsen fra /health

HTTP-laget

I src/server.ts er HTTP-laget bevisst enkelt. Det er et godt bloggpoeng, fordi det gjør det lett å forklare hva som skjer uten å drukne leseren i unødvendig kompleksitet.

Serveren har fire viktige ruter:

• GET / for enkel status
• GET /health for health check
• GET /api for enkel API-info
• POST /mcp for MCP-forespørsler

Poenget er at vanlige HTTP-endepunkter brukes til rask kontroll og feilsøking, mens POST /mcp er selve protokollinngangen der MCP-meldingene behandles. Det er her du går fra "serveren lever" til "serveren kan faktisk gjøre noe som er verdt å vise frem".

MCP, uten tåkeprat

Initialisere

Første steg er å etablere samtalen med serveren.

json

{

"jsonrpc": "2.0",

"id": 1,

"method": "initialize",

"params": {}

}

Dette er MCP-tilsvarigheten til en håndhilsen: klient og server blir enige om at de faktisk snakker samme protokoll.

Bilde4: MCP initialiserer etablerer samtalen med serveren

List verktøy

Når forbindelsen er etablert, spør du hvilke verktøy som finnes.

```json

{

"jsonrpc": "2.0",

"id": 2,

"method": "tools/list",

"params": {}

}

Bilde5: Verktøylisten viser hva serveren kan gjøre

Kall et verktøy

Bilde6: Et konkret verktøykall henter Azure-informasjon

List ressurser 

Etter verktøyene er det naturlig å vise ressursene.

```json

{

"jsonrpc": "2.0",

"id": 4,

"method": "resources/list",

"params": {}

}

Bilde7: Lister ressurser

Dette er en enkel overgang: verktøy gjør noe, ressurser lar deg lese strukturert plattforminformasjon uten at det blir et virvar.

Les en ressurs

Til slutt leser du en konkret landing zone-ressurs.

json

{

"jsonrpc": "2.0",

"id": 5,

"method": "resources/read",

"params": {

"uri": "azure://landingzone/config"

}

}

Dette er et særlig godt eksempel fordi `azure://landingzone/config` er intuitivt: det høres ut som plattformkonfigurasjonen leses direkte fra MCP-laget, ikke gjemt bak fem andre abstraheringer.

Bilde8: Ressurser gjør konfigurasjon og plattformdata lesbare

Ofte stilte spørsmål

1. Hva er Azure MCP-serveren i praksis?

Azure MCP-serveren er et MCP-kompatibelt lag som eksponerer Azure-relevante verktøy og ressurser via standard JSON-RPC-metoder, slik at klienter kan kjøre kall som tools/list, tools/call, resources/list og resources/read på en strukturert måte.

2. Hvilke kall bør jeg alltid teste først?

Start med initialize, deretter tools/list og resources/list. Da ser du raskt om protokollen fungerer, hvilke verktøy som er tilgjengelige, og hvilke ressurser du kan lese.

3. Hvorfor feiler tools/call mot list_management_groups av og til?

Vanligste årsak er manglende autentisering eller miljøoppsett for Azure-identitet. Serveren kan svare teknisk korrekt på MCP-nivå, men verktøykallet kan fortsatt returnere feil hvis underliggende Azure-tilgang ikke er på plass.

4. Hva er forskjellen på resources/list og resources/read i Azure MCP-serveren?

resources/list returnerer oversikt over tilgjengelige ressurs-URI-er, mens resources/read henter innholdet til én spesifikk URI, for eksempel azure://landingzone/config med metadata og payload.

5. Hvordan kobler jeg en klient (for eksempel Copilot/agent) til Azure MCP-serveren?

Klienten må konfigureres til å sende JSON-RPC-kall til MCP-endepunktet (POST /mcp). I praksis betyr det at klienten må støtte MCP-protokollen, kjenne server-URL, og kunne kjøre standardkall som initialize, tools/list og resources/read. En rask verifisering er å se at initialize returnerer protocolVersion og serverInfo.

Til slutt

Azure MCP-serveren er et godt eksempel på hvordan man kan gjøre plattforminformasjon tilgjengelig på en strukturert og pedagogisk måte. Ved å kombinere HTTP-endepunkter, MCP-protokoll og Azure-spesifikke verktøy får du en server som både kan demonstreres og brukes, i stedet for å bare ligge der og se teknisk ut.

Neste naturlige steg er å teste noen av verktøyene mot egne Azure-ressurser, eller å bygge videre på samme mønster for andre plattformtjenester. Hvis du ønsker mer informasjon, ta gjerne kontakt.

Les også