1.0.0

A remote MCP server on Azure Functions, the Libre DevOps way

A Python function app on a Flex Consumption plan hosting a remote MCP server via the GA Azure Functions MCP extension: the platform speaks the protocol (Streamable HTTP at /runtime/webhooks/mcp, JSON-RPC framing, tool discovery), the functions are the tools.

Built basic but extensible

Wiring in a tool is dropping one file into src/tools/ with a module-level Blueprint; function_app.py discovers and registers it, and nothing else needs touching. The tool name is the function name, the docstring is the model-facing description, and the discovery test insists every tool carries a real one.

The launch tools

• check_cidr: any IPv4 CIDR against Azure's subnet rules, pure arithmetic, no identity needed. Azure reserves five addresses in every subnet (network, default gateway, two for Azure DNS, broadcast), so subnets run /2 through /29 and a /30 answers validAzureSubnet: false with the reason spelled out.
• get_next_cidr: the next free subnet of a requested size in a virtual network the server's identity can read. Reader on the vnet's scope is genuinely enough; nothing is created or reserved.

The estate treatment

Terraform composed from the published Libre DevOps registry modules with standalone and bring-your-own-network paths, a PowerShell justfile whose smoke speaks real MCP (initialize, tools/list, and a call of each tool), 32 unit tests, CI with tflint and a gated trivy scan, CodeQL, and dependabot. Proven live before release: a full MCP session against the deployed server answered 10.30.0.128/26 from the test vnet, then the stack was destroyed.