
The MCP Server on an Azure Function App
The foundation - standing up a Model Context Protocol server on a serverless Azure Function App.
Run this first. The project is mcp-node, in this repo. Paste one line into an agent CLI (Claude Code, Codex, Copilot, or Gemini):
Install mcp-node: read and follow https://github.com/zacha0dev/zallen-dev/blob/main/mcp-node/install/agent.md
It checks your tools, signs you into Azure, deploys, and prints how to connect. A few minutes later you have a server running in your own Azure. Then come back here for what it is and why it works this way.
What we are building
The first real piece of the system is the part everything else plugs into: a server an AI can talk to. In this series that server is an MCP server, and it runs on an Azure Function App. By the end of this piece you have one running in your own cloud, for about ten dollars a month, that you can connect Claude or ChatGPT to and use to manage its own Azure.
What MCP actually is
A language model, on its own, only does one thing: text in, text out. It cannot read a file, deploy a server, or check a bill. The Model Context Protocol (MCP) is the standard that lets it do those things. You run a small server that exposes a set of actions, called tools, and the AI calls them over MCP. The model decides what to call; the server runs it and hands back the result. (If MCP is new to you, the plain-English explainer covers the shape of it.)
So an MCP server is just a program that says "here are the tools I have" and runs them when asked. That is the whole idea. Everything else in this series is more tools on top of this one server.
Why a Function App
You could run the server on an always-on virtual machine, but that costs money around the clock. An Azure Function App is serverless: it runs only when a request comes in, and scales to zero when nothing is using it. An idle node costs almost nothing. For a personal system you leave connected but rarely hammer, that is exactly the right shape.
The walkthrough
Here is what that one line actually does, start to finish:
- Checks your machine has the tools it needs (the Azure command-line, Node, the Functions tools) and installs whatever is missing.
- Signs you into Azure and confirms which subscription to use.
- Creates one resource group: a single labeled box that holds everything for this node.
- Deploys the pieces into it: the Function App that runs the server, an Azure Key Vault for secrets, a managed identity so the node can act on Azure without storing a password, and a monthly cost cap.
- Generates the sign-in secrets and stores them in the vault.
- Publishes the server code to the Function App.
- Prints a connect block: the values you paste into Claude or ChatGPT.
When it finishes you have a live server at its own web address, answering on three paths: one to start a session, one to sign in, and one for the AI to call tools.
Connecting
Each AI client wants the connect values in a slightly different shape. Claude takes a couple of them and runs the sign-in itself; ChatGPT wants the full set spelled out. The per-client steps are in the docs. Once connected, ask it to report its status, and you will see it talking to your own resource group.
What you have now
One server, in one capped resource group, that an AI can connect to and use to manage its own cloud and code. It is small on purpose. In the next piece we wire up its connectors - how clients reach in and how the server reaches out - and from there the system grows one piece at a time.