In Part 3, we gave GitHub Copilot a project identity. Custom instructions told it about our Zero Trust rules. Path-specific instructions scoped guidance to the right files. Prompt files turned repetitive tasks into one-click workflows. Custom agents gave it specialized personas with scoped tools.

But all of that is always on. Every Copilot conversation loads the custom instructions, whether you’re asking about networking or asking it to write a commit message. That’s fine when the instructions are small. It becomes a problem when your project grows when you accumulate rules for security reviews, cost analysis, state management, scaling, and image lifecycle. You can’t fit everything into `copilot-instructions.md` without turning it into a sprawling document that confuses the model as much as it helps it.

Skills solve this. They’re the on-demand counterpart to always-on instructions. A skill is a folder with a `SKILL.md` file that Copilot loads *only when your prompt is relevant to it. Ask about drift? The drift detector skill loads. Ask about costs? The cost estimator loads. Ask about a new Container App resource? Copilot uses the base instructions and leaves the cost estimator alone.

This is Part 4, and it’s entirely about skills.

What skills actually are

The mental model is straightforward. Custom instructions are rules you want Copilot to follow always your naming conventions, your provider version, your security posture. Skills are specialized knowledge packages you want available on demand the deep expertise for a specific task that would clutter the always-on context if it were always loaded.

Mechanically, a skill is a directory under `.github/skills/` with a single required file: `SKILL.md`. That file has two parts: a YAML frontmatter block and a Markdown body.

```
.github/
└── skills/
    └── my-skill-name/
        └── SKILL.md
```

The frontmatter defines the skill's identity:

```yaml
---
name: my-skill-name
description: >
  One sentence summary.

  When to use this skill:
  - "trigger phrase 1"
  - "trigger phrase 2"
---
```

The description field is doing a lot of work here. Copilot reads it to decide whether this skill is relevant to your current prompt. The “when to use” section isn’t documentation for humans it’s signal for the model. Write it as a list of phrases someone would actually type when they need this skill. The more specific and realistic, the better the match.

The Markdown body is the skill’s actual content: instructions, workflows, code examples, lookup tables, templates. Whatever Copilot needs to execute the task well.

Skills vs. the other tools in the toolbox

After three parts covering custom instructions, path-specific instructions, prompt files, and agents, it’s worth being precise about where skills fit.

The key distinction from agents: agents are personas you *select*. Skills are knowledge packages that Copilot *discovers*. When you assign an issue to the coding agent with the implementation agent selected, that’s an explicit choice. When you ask “how much does this architecture cost?” and the cost estimator skill loads, that’s automatic.

Building five skills for this project

Let’s build a complete skill library for the Azure Container Apps infrastructure we’ve been assembling across Parts 1, 2, and 3. Each skill addresses a real operational need.

Skill 1 Terraform Drift Detector :

Create `.github/skills/terraform-drift-detector/SKILL.md`:

---
name: terraform-drift-detector
description: >
  Detect, explain, and resolve Terraform state drift in this Azure Container Apps project.

  When to use this skill:
  - "Why does my terraform plan show unexpected changes?"
  - "Something changed in Azure but I didn't touch the Terraform"
  - "Detect drift", "check for drift", "why is plan not clean?"
  - "Azure Portal changes not reflected in state"
  - After manual changes via Azure CLI or Portal that weren't tracked in state
---

# Terraform Drift Detector

You are an expert in Terraform state management for Azure Container Apps infrastructure.
Your job is to detect, explain, and resolve drift between the Terraform state and actual Azure resources.

## What Is Drift

Drift happens when real Azure resources no longer match what Terraform's state file says they should be.
Common causes in this project:
- Manual changes via Azure Portal or CLI (e.g., scaling a Container App by hand)
- Azure auto-healing or auto-upgrading resources (e.g., Container App revision updates)
- Expiry or auto-rotation of identities
- Out-of-band certificate renewals on Application Gateway

## Detection Workflow

1. Read the current state using `#readFile` on `terraform.tfstate`
2. Run `terraform plan -detailed-exitcode`
   - Exit code 0 = no drift
   - Exit code 2 = drift found
3. Categorize each change by severity:
   - `external_enabled` flip on any Container App → 🔴 CRITICAL
   - `admin_enabled` change on ACR → 🔴 CRITICAL
   - Scaling values (min/max replicas) → 🟡 MEDIUM
   - Tag or label drifts → 🟢 LOW

## Reconciliation Rules

- NEVER auto-run `terraform apply` — show the plan first, ask for confirmation
- For CRITICAL: surface clearly, explain what probably happened, recommend remediation steps
- For LOW/MEDIUM: propose `terraform apply -target=<resource>` with the specific address

## Output Format

Present findings as a Drift Report with Critical Changes and Safe-to-Reconcile sections.

Why this skill matters. In a real team, someone will make a manual change in the Azure Portal usually in an incident, under pressure. Terraform will then want to revert it. The worst case is a terraform apply that flips external_enabled from true to false on the frontend, taking it offline. The drift detector loads the right context to catch that before it happens.

Skill 2 ACA Scaling Advisor

Create `.github/skills/aca-scaling-advisor/SKILL.md`:

---
name: aca-scaling-advisor
description: >
  Design, review, and optimize scaling rules for Azure Container Apps in this project.

  When to use this skill:
  - "Add scaling rules to my Container App"
  - "How should I scale the backend API?"
  - "My app is slow under load", "optimize scaling", "autoscale"
  - "Add KEDA scaler", "HTTP scaling", "queue-based scaling"
  - "min_replicas is too high", "I'm paying too much for idle containers"
---

# ACA Scaling Advisor

You are an expert in Azure Container Apps autoscaling using KEDA.
Architecture context: frontend is external-facing via Application Gateway,
backend is internal-only. Both run on Consumption workload profile.

## Key Rules

**Frontend** — safe for `min_replicas = 0`. Application Gateway handles the queue.
Use HTTP scaler with `concurrentRequests = 100`.

**Backend** — keep `min_replicas = 1` unless the frontend uses async calls.
Scale-to-zero on a synchronously-called backend means the frontend sees cold start latency.
Use CPU scaler at 70% utilization.

## HTTP Scaling (Frontend)

\`\`\`hcl
template {
  min_replicas = 0
  max_replicas = 10

  custom_scale_rule {
    name             = "http-scaler"
    custom_rule_type = "http"
    metadata = {
      concurrentRequests = "100"
    }
  }
}
\`\`\`

## CPU Scaling (Backend)

\`\`\`hcl
template {
  min_replicas = 1
  max_replicas = 5

  custom_scale_rule {
    name             = "cpu-scaler"
    custom_rule_type = "cpu"
    metadata = {
      type  = "Utilization"
      value = "70"
    }
  }
}
\`\`\`

Always validate: no conflicting scale rules, `max_replicas` fits your cost ceiling,
and `min_replicas ≥ 1` on synchronously-called services.

The scaling advisor encodes the architectural constraints of this specific project. A generic Copilot response might suggest min_replicas = 0 on the backend because it reduces costs. That’s correct in isolation. It’s wrong here because the frontend calls the backend synchronously a cold start becomes frontend latency. The skill carries that context.

Skill 3 Azure Cost Estimator

Create .github/skills/azure-cost-estimator/SKILL.md:

---
name: azure-cost-estimator
description: >
  Estimate and break down monthly Azure costs for this Container Apps infrastructure.

  When to use this skill:
  - "How much does this architecture cost?"
  - "Estimate my Azure bill", "cost breakdown", "cost estimate"
  - "Is the Application Gateway expensive?"
  - "I want to reduce costs", "cheapest way to run this"
  - "What's the difference in cost between Consumption and Dedicated?"
  - Before adding new resources — estimate the cost impact first
---

# Azure Cost Estimator

Pricing reference for West Europe (adjust by ~10-20% for other regions):

| Resource | Config | Est. Monthly Cost |
|---|---|---|
| Application Gateway | Standard_v2 | ~$185 |
| Container Registry | Standard SKU | ~$20 |
| Container Apps (per app) | 0.25 vCPU, 0.5GiB, 8h/day | ~$15 |
| Public IP | Standard | ~$4 |
| Private DNS Zone | 1 zone | ~$1 |
| Log Analytics | <5GB/day ingestion | ~$0 |

**Important:** Application Gateway accounts for ~75% of the bill at this scale.
It costs ~$185/month regardless of traffic volume.

When asked for an estimate:
1. Read `.tf` files to identify all provisioned resources
2. Ask for region if not West Europe
3. Present the cost table with actual resource configs from Terraform
4. Highlight the biggest cost driver
5. Suggest one or two project-specific optimizations
6. Always point to the Azure Pricing Calculator for accurate quotes

Every project eventually hits the “what’s this costing us?” question. Without the skill, Copilot would give a generic answer that doesn’t account for the Application Gateway’s flat cost, the specific SKUs we chose, or the Consumption billing model. The skill bakes those numbers in.

Skill 4 Security Posture Reviewer

Create .github/skills/security-posture-reviewer/SKILL.md:

---
name: security-posture-reviewer
description: >
  Review the Zero Trust security posture of this Azure Container Apps Terraform project.

  When to use this skill:
  - "Review my security", "security audit", "security check"
  - "Is this Zero Trust?", "what are my security gaps?"
  - "Check my NSG rules", "are my secrets safe?"
  - Before a production deployment or architecture review
  - After adding new resources — verify they follow the project's security rules
---

# Security Posture Reviewer

Review the project's Zero Trust compliance against this checklist.
Output ✅ or ❌ for each item after reading the Terraform files.

### Networking
- [ ] `internal_load_balancer_enabled = true` on Container App Environment
- [ ] ACA subnet CIDR is minimum `/23`
- [ ] NSG includes `GatewayManager` and `AzureLoadBalancer` inbound rules on AppGW subnet
- [ ] No `0.0.0.0/0` allow-all inbound rules (except those required by Azure platform)
- [ ] Private DNS zone linked to VNet with `registration_enabled = false`

### Container Apps
- [ ] Backend uses `external_enabled = false` (not just an NSG rule)
- [ ] No plaintext secrets in environment variables

### Container Registry
- [ ] `admin_enabled = false`
- [ ] SKU is Standard or Premium

### Identity and Credentials
- [ ] System-assigned Managed Identity enabled on both Container Apps
- [ ] `AcrPull` role assigned for each Container App's principal_id
- [ ] GitHub Actions uses workload identity federation (not service principal secrets)
- [ ] `terraform.tfstate` is NOT committed to the repository

## Common Gaps to Flag

**State file in repo**  contains resource IDs and output values. Add to `.gitignore` and use Azure Storage backend.

**Missing WAF policy**  Standard_v2 supports WAF but it's not enabled by default. Without it, no OWASP rule set protects the frontend from injection attacks.

**Log Analytics retention at default 30 days**  insufficient for incident response. Set `retention_in_days = 90`.

This skill is the automated version of the senior engineer’s pre-deployment checklist. It doesn’t just know generic security best practices it knows this project’s security model and can check it against the actual Terraform files.

Skill 5 ACR Image Manager

Create .github/skills/acr-image-manager/SKILL.md:

---
name: acr-image-manager
description: >
  Manage container images in Azure Container Registry — tagging strategy, image promotion,
  cleanup, and updating Container App image references in Terraform.

  When to use this skill:
  - "Tag my image for production", "promote image from staging to prod"
  - "Clean up old images in ACR", "delete untagged manifests"
  - "Update the Container App to use image version X"
  - "How should I tag my Docker images?", "image versioning strategy"
  - "Purge images older than 30 days", "reduce ACR storage costs"
---

# ACR Image Manager

ACR was created with `admin_enabled = false`. All operations use RBAC, not admin credentials.
Always authenticate with `az acr login --name <acr_name>` using the user's Azure CLI identity.

## Tagging Strategy

Use semantic versioning with a build reference. Never rely on `latest` alone for production.

\`\`\`
<acr_login_server>/<service>:<semver>-<short_sha>
\`\`\`

Examples:
- `acrab3k2m.azurecr.io/frontend:1.2.0-a3f9c1e`  ← immutable, for rollback
- `acrab3k2m.azurecr.io/frontend:latest`           ← mutable, for convenience

## Image Promotion (Staging → Production)

Use `az acr import` to copy between registries without pulling locally:

\`\`\`bash
az acr import \
  --name <prod_acr_name> \
  --source <staging_acr_login_server>/backend:1.2.0-a3f9c1e \
  --image backend:prod-1.2.0 \
  --registry <staging_acr_resource_id>
\`\`\`

## Updating Container App Image in Terraform

After promoting, update the `image` field in `aca.tf`:

\`\`\`hcl
image = "${azurerm_container_registry.acr.login_server}/backend:1.2.0-a3f9c1e"
\`\`\`

Then run `terraform plan` — only the image tag should change. Azure Container Apps creates a new revision automatically.

## Cleanup

Always dry-run before executing:

\`\`\`bash
az acr run \
  --registry <acr_name> \
  --cmd "acr purge --filter 'backend:.*' --untagged --ago 30d --dry-run" \
  /dev/null
\`\`\`

Remove `--dry-run` once the output looks right.

The image management skill is particularly useful after the GitHub Actions CI/CD pipeline from Part 3 starts pushing images. Without it, Copilot doesn’t know whether to suggest az acr commands, direct Docker commands, or Terraform changes. The skill normalizes that: use RBAC auth, use the ACR import command for promotion, update the specific image field in aca.tf.

How Copilot discovers and loads skills

You don’t invoke skills manually. When you type a prompt in Copilot Chat (or an issue body that gets routed to the coding agent), Copilot reads the description field of every skill in .github/skills/ and decides which ones are relevant. If the match is strong, the SKILL.md content is injected into the context for that conversation.

This means the description field is actually the most important part of the file. Write it as if you’re writing the queries that should trigger it. The more concrete and realistic, the better.

A few things that improve match quality:

Be specific about trigger phrases. “Detect drift”, “check for drift”, and “why is plan not clean?” are all things a real engineer would type. Generic phrases like “help with infrastructure” are too broad — they’d match every skill and load them all.

Include anti-examples if needed. If two skills might get confused (say, cost estimator and scaling advisor both relate to “spending less money”), mention what each one doesn’t cover in the description.

Keep the body focused. A skill loaded into context costs tokens. If the body is bloated with tangential information, the model’s attention dilutes. Each skill should do one thing well.

Your repo structure after Part 4

.github/
├── copilot-instructions.md            # Always-on: naming, provider, Zero Trust rules
├── agents/
│   ├── terraform-aca-implement.agent.md  # Specialist: writes and validates Terraform
│   └── terraform-aca-planning.agent.md   # Specialist: designs changes, creates plans
├── instructions/
│   ├── networking.instructions.md     # File-scoped: vnet.tf, nsg.tf, dns.tf
│   └── containers.instructions.md    # File-scoped: aca.tf, acr.tf
├── prompts/
│   ├── new-container-app.prompt.md   # One-click: scaffold a new Container App
│   └── terraform-review.prompt.md   # One-click: security review checklist
├── skills/
│   ├── terraform-drift-detector/
│   │   └── SKILL.md                 # On-demand: detect and resolve state drift
│   ├── aca-scaling-advisor/
│   │   └── SKILL.md                 # On-demand: design KEDA scaling rules
│   ├── azure-cost-estimator/
│   │   └── SKILL.md                 # On-demand: monthly cost breakdown
│   ├── security-posture-reviewer/
│   │   └── SKILL.md                 # On-demand: Zero Trust compliance check
│   └── acr-image-manager/
│       └── SKILL.md                 # On-demand: image tagging, promotion, cleanup
└── workflows/
    └── terraform.yml                # CI/CD: plan on PR, apply on merge

Each layer serves a different purpose. Always-on instructions keep every AI interaction aligned with your project’s conventions. Path-specific instructions add depth when editing specific file types. Prompt files make repetitive tasks one-click. Agents give you specialized personas. Skills provide deep expertise exactly when and only when you need it.

Where to find more skills

GitHub maintains the github/awesome-copilot repository with 247+ community-contributed skills. For Azure infrastructure work specifically, look at azure-architecture-autopilot (design and deploy Azure resources from natural language) and create-specification (generate structured spec files optimized for AI consumption). These are production-grade starting points — fork them, trim what you don’t need, add your project’s specific context.

One thing worth knowing: skills in awesome-copilot are organized by domain rather than by project. They’re designed to be generally useful, not specifically aware of your infrastructure. The value you get from writing your own is exactly that specificity — the drift detector that knows the difference between a MEDIUM and CRITICAL change for this architecture, the scaling advisor that knows this backend is called synchronously, the cost estimator that already has these SKUs and region prices loaded.

The full picture

Three parts built an infrastructure platform. Part 4 built the AI layer on top of it.

Start with what’s always relevant: custom instructions for project-wide rules that apply to every conversation. Add path-specific instructions for file types that have specialized concerns. Create prompt files for the tasks your team runs repeatedly. Build agents for the workflows that need specialized personas and specific tool access. Then write skills for the deep expertise that’s only needed sometimes state drift, scaling design, cost analysis, security review, image lifecycle.

None of these are about making Copilot smarter in the abstract. They’re about making it useful for your specific project, in the way that a colleague who’s worked on the codebase for six months is useful not because they know more general programming knowledge than a new hire, but because they know what matters here.

This is Part 4 of a series on building production-ready microservices on Azure Container Apps with Terraform and GitHub Copilot. Part1 covers the secure networking baseline. Part 2 covers ACR, internal backend, and frontend-backend wiring. Part 3 covers AI-assisted automation, Managed Identities, and CI/CD.

Up until now, I’ve mainly been using existing MCP servers. But at some point the real question arrives:
How do you build your own MCP server? Where do you host it? And how do you actually use it in real projects?

That’s exactly what led me here. I wanted to create my first MCP server from scratch. While exploring different approaches, I came across several sample repositories in Azure-samples. Since I’m a long-time C# developer, my first instinct was to build a server using Azure Functions + C# totally in my comfort zone.

But this time, I made a promise to myself: step outside the comfort zone.
And after watching many presentations by the amazing Pamela Fox, I said why not Python for this first example?

So in this blog post, we’re going to build a simple expense-tracker MCP server using Python, deploy it as an Azure Function, and test it using MCP Inspector and VS Code’s MCP extension.

You’ll find a clear, step-by-step guide including:

Cloning the repo : https://github.com/achrafbenalaya/expensetrackermcpserver
Writing the server logic
Creating & deploying the Azure Function
Testing it locally and in VS Code with MCP Inspector

If you enjoy this walkthrough, feel free to share it and if you’d like to support my content, you can buy me a coffee here: buymeacoffee.com/ben2code

Prerequisites to follow along

To build and test this project, make sure you have:

• VS Code
• MCP Inspector
• Python
• Browser
• Docker (optional I’ll show how to run without it)
• Azure account with permissions to create Azure Functions
• And of course… an internet connection

Alright let’s jump right in.

When you walk into a car showroom, you don’t start by asking about the engine specs, compression ratio, or fuel injection system. First, you want to see the car. You look at the design, step inside, feel the seats, maybe even take it for a quick test drive. Only after that do you start digging into the technical details.

We’re going to take the exact same approach here.

Before diving into code, architecture, Azure Functions, or deployment pipelines, let me show you the final result what the MCP server can actually do once it’s up and running.

Tool #1: get_expenses

This first tool simply retrieves your saved expenses a clean, structured way to read your stored data through MCP. Think of it like opening your car’s dashboard to see your mileage and trip history before we start checking the engine.

Let’s take a look at how it works in action

Simply here i was asking for my expenses for the month of October for the year 2025

Tool #2: get_budget

The second tool gives us visibility into our monthly budget.

For the demo, I’ve set the default budget to $1000 per month. Later, we’ll make this more flexible by storing the budget in an environment variable which means you’ll be able to adjust it per month, per environment, or even per user without touching the code.Think of this tool like checking the car’s fuel range before a road trip you need to know how far you can go before running out

This command simply returns your current budget value, so you always have a clear reference point before adding or reviewing expenses.

Tool #3: get_spending_summary

This tool gives you a summary of your spending over a specific time range.

Tool #4: add_expense

Now that we can read our budget and existing data, it’s time for the fun part adding new expenses.

This tool allows you to record a new expense with all the important details: category, amount, description, and date.

Let’s check if the record is added :

But wait where is all this data actually stored?
Behind the scenes, everything is saved in an Azure Storage account, inside a Blob as a CSV file. Simple, lightweight, and easy to query.

Project Overview How We Built This MCP Server

Now that you’ve seen the final result, let’s open the hood and see how everything works under the engine. In this section, we’ll walk through:

• Where the project skeleton came from
• What was modified and why
• How the MCP server was implemented in Python
• How we deployed it to Azure Functions
• The configuration (environment variables, Storage, Blob, etc.)
• How we tested locally and in the cloud
• Tools used along the way (MCP Inspector, VS Code, Claude Desktop, etc.)

Let’s break it down step-by-step

1⃣ Pulling the Base Template (Source Repo)

I started by cloning the official Model Context Protocol example repository from Azure-Samples, which provides a clean starting point for building MCP servers.

It gave me a Python-based skeleton so I could focus on extending the logic instead of building everything from scratch.

repo url =====> Azure-Samples/remote-mcp-functions-python

Full functionel repo ===> https://github.com/achrafbenalaya/expensetrackermcpserver

git clone https://github.com/Azure-Samples/remote-mcp-functions-python.git

2⃣ Understanding the Starter Code & Modifying It

From the base template, I:

• Reviewed the MCP handler logic
• Created new MCP tools (get_budget, get_expenses, add_expense, get_spending_summary)
• Integrated Azure Blob Storage as the backend
• Added CSV read/write operations
• Structured responses to match MCP protocol expectations
  
  

Basically , I built a lightweight expense-tracking service in Python backed by Azure Blob Storage no pandas required. It handles both CSV and XLSX formats, includes reliable date and amount parsing, supports dynamic monthly budgets via environment variables, and provides simple rule-based expense categorization. Each capability is implemented as small, testable functions and exposed as MCP tools (get_expenses, add_expense, get_budget_status, get_spending_summary, categorize_expense).

I’ll first explain, in plain steps, how the existing “get all expenses” tool was added (what the method does and why). Then I’ll show a minimal example of adding a new simple “hello world” tool — both the class method and a small HTTP wrapper you can drop into an Azure Functions HTTP trigger or run locally.

How the “get all expenses” tool was added short, concrete steps

What we added: a public method get_expenses(month: str, category: Optional[str] = None) -> List[Dict] on ExpenseTracker.

Why: expose a small, testable API that lists expenses for a given month (and optional category) in a JSON-serializable format so it can be used by MCP tools, HTTP endpoints, or scripts.

Implementation summary :

• Input normalization:
  • _parse_yyyymm(month) accepts “YYYY-MM” or “YYYYMM” and normalizes to “YYYY-MM”. This makes the interface robust to common formats.
• Read source of truth:
  • Calls self._download_rows() which fetches the blob (XLSX or CSV) from the configured container and returns rows as dicts. If the blob is missing, _download_rows() returns an empty list.
• Iterate and filter:
  • For each row, read the Date field. The code accepts:
    • Excel date objects (openpyxl returns datetime/date),
    • datetime objects,
    • or ISO date strings “YYYY-MM-DD”.
  • Convert/normalize to a date, build row_month = "YYYY-MM" and compare with the requested month.
  • If category is supplied, compare case-insensitively and skip non-matching rows.
• Normalize fields:
  • Ensure Amount is cast to float() (on failure fallback to 0.0).
  • Ensure Category and Description are strings.
• Return shape:
  • A list of dicts like:
    • { “Date”: “YYYY-MM-DD”, “Amount”: float, “Category”: str, “Description”: str }
  • This JSON-friendly shape is easy to serialize as an HTTP response or an MCP tool return.

Error/edge behavior:

• If month format invalid → _parse_yyyymm raises ValueError.
• If no blob exists → returns [] (safe).
• Bad amount strings → amount becomes 0.0 for listing (but add_expense raises ValueError for invalid amounts).

How it becomes a “tool” (exposure options)

• Direct use in scripts: instantiate ExpenseTracker() and call get_expenses("2025-12").
• Wrap as HTTP endpoints (Azure Functions) where the function handler instantiates ExpenseTracker() and returns the list as JSON.
• Register it as an MCP tool wrapper (the repository already contains tooling that triggers these methods) the method contract is intentionally simple (primitive types + JSON-serializable results).
  
  example below the get_expenses function

def get_expenses(self, month: str, category: Optional[str] = None) -> List[Dict[str, Any]]:
    month = _parse_yyyymm(month)
    rows = self._download_rows()
    result = []
    for r in rows:
        d = r.get("Date")
        if not d:
            continue
        if isinstance(d, datetime):
            ddate = d.date()
        elif isinstance(d, date):
            ddate = d
        else:
            try:
                ddate = datetime.strptime(str(d), "%Y-%m-%d").date()
            except Exception:
                continue
        row_month = f"{ddate.year:04d}-{ddate.month:02d}"
        if row_month != month:
            continue
        cat = r.get("Category") or ""
        if category and str(cat).strip().lower() != category.strip().lower():
            continue
        amount = r.get("Amount", 0.0)
        try:
            amount = float(amount)
        except Exception:
            amount = 0.0
        result.append({
            "Date": ddate.isoformat(),
            "Amount": amount,
            "Category": str(cat),
            "Description": str(r.get("Description", "")),
        })
    return result

Where the tool is declared ?

in this part we define the new tool and we call the function

@app.generic_trigger(
    arg_name="context",
    type="mcpToolTrigger",
    toolName="get_expenses",
    description="Retrieve expenses filtered by month and optional category.",
    toolProperties=tool_properties_get_expenses_json,
)
def get_expenses(context) -> str:
    ...

Input the tool expects

The function receives a single context parameter which is a JSON string (the trigger payload). The function parses it like this:

content = json.loads(context)
month = content.get(“arguments”, {}).get(“month”)
category = content.get(“arguments”, {}).get(“category”)

So the caller should send a JSON payload shaped like:

{
  "arguments": {
    "month": "2025-12",
    "category": "IT"            // optional
  }
}

wrapper function :

1. Parse context JSON and extract month and optional category.
2. Validate required month argument. If missing, return a JSON error object.
3. Call the underlying tool method:
   • Uses _get_tracker() to get a singleton ExpenseTracker instance.
   • Calls _get_tracker().get_expenses(month=month, category=category).
4. Wrap the result in a uniform response object and return it as JSON string:

return json.dumps({
    "ok": True,
    "month": month,
    "category": category or "all",
    "count": len(result) if isinstance(result, list) else 0,
    "result": result
})

Sequence :

Client (MCP caller / script)
-> sends JSON context to MCP trigger
-> function_app.get_expenses(context) wrapper
-> parses JSON, validates month
-> calls _get_tracker().get_expenses(month, category)
-> ExpenseTracker.get_expenses(...)
-> _download_rows() reads blob (XLSX/CSV) <– Azure Blob Storage
<- rows
<- filtered/normalized result
<- wrapper returns JSON string { ok, month, count, result }

In the repo you will find readme file that will explain full code , so no worries.

3⃣ Adding Environment Variables

To keep settings flexible and secure, I added environment variables for:

4⃣ Local Development & Testing

To test everything locally, I used:

VS Code : to code and run the azure function => Download here
Python : because we are using python for this demo
Azure Functions Core Tools : Azure Functions Core Tools lets you develop and test your functions on your local computer
MCP Inspector (to simulate LLM connection) : MCP Inspector will be used later for testing .
it can be launched via the cmd : npx @modelcontextprotocol/inspector

Once you run it you can browse : http://127.0.0.1:6274/#resources to see the mcp inspector home page and you can connect to your function app by inserting this link to
http://localhost:7071/runtime/webhooks/mcp/sse to the URL and set

You can choose any tool and test it from the List Tools :

An storage emulator : An storage emulator is needed when developing azure function app in VScode : Azurite emulator for local Azure Storage development
You can run the Azurite in VS Code  : C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\Extensions\Microsoft\Azure Storage Emulator> .\azurite.exe
or Using Docker : docker run -p 10000:10000 -p 10001:10001 -p 10002:10002 mcr.microsoft.com/azure-storage/azurite

5⃣ Deploying to Azure Functions

Once everything worked locally:

• Created an Azure Function App
• Pushed the code via VS Code deployment
• Added same environment variables in Azure portal
• Uploaded/created the blob file for storage

The simplest way to deploy an azure function via vs code is to click on it and select : Deploy to function app (As I’m writing this article, I’m also planning to prepare a Terraform version of this Azure Function to streamline and automate the deployment process.)

Once the app is deployed , you can see the tools by clicking on functions from the portal :

Now before we go and test on MCP inspector or vs code we need to copy the system keys to use (not the best practice for now ,but its for the demo) .
where to find it ? simply go to App Keys and copy the mcp_extension key and save it .

If you’re familiar with the Model Context Protocol and how servers work with it, you know that we need an mcp.json file to define the MCP servers we plan to use.

{
    "inputs": [
        {
            "type": "promptString",
            "id": "functions-mcp-extension-system-key",
            "description": "Azure Functions MCP Extension System Key",
            "password": true
        },
        {
            "type": "promptString",
            "id": "functionapp-name",
            "description": "Azure Functions App Name"
        }
    ],
    "servers": {
        "remote-mcp-function": {
            "type": "sse",
            "url": "https://${input:functionapp-name}.azurewebsites.net/runtime/webhooks/mcp/sse",
            "headers": {
                "x-functions-key": "${input:functions-mcp-extension-system-key}"
            }
        },
        "local-mcp-function": {
            "type": "sse",
            "url": "http://0.0.0.0:7071/runtime/webhooks/mcp/sse"
        }
    }
}

You can add a new server always by using the CTRL+shift +P

Storage account :

I have uploaded a simple csvp file to a storage account on azure and i genrated SAS token for the blob and for the container of the blob

Generate two sas and save them because we will use them later

6⃣ Testing our MCP server

First lets run the MCP server in VS Code :

cd src
pip install -r requirements.txt
func start

you make sure you already have the mcp inspector runing and also the Azurite emulator for local Azure Storage development and now open the mcp inspector page and paste that url on the url tab :

Testing the online server :

Now that we’ve tested the local server and added our MCP server to the mcp.json file, there’s one final step before we test it. We need to add the environment variables — using the values we copied earlier — to the local.settings.json file

{
    "IsEncrypted": false,
    "Values": {
      "FUNCTIONS_WORKER_RUNTIME": "python",
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "EXPENSES_CONTAINER_SAS_URL": "EXPENSES_CONTAINER_SAS_URL",
      "EXPENSES_BLOB_NAME": "expenses.sample.csv",
      "EXPENSES_BLOB_SAS_URL": "EXPENSES_BLOB_SAS_URL"
    }
  }

To test the setup, copy the Azure Function URL and append /runtime/webhooks/mcp/sse to it.
Then, go to Authentication, select the app key, and use it to authenticate the request.
Make sure to set the header name to x-functions-key.

Testing our MCP server with GitHub Copilot

Testing an MCP server with GitHub Copilot means configuring the server in your development environment so Copilot Chat can leverage it for richer context and enhanced capabilities.
we have already added the configuration in the mcp.json we should see the server running by now and we have Agent mode selected .

Lets try another tool , lets add some expenses :

Testing our MCP server with Claude Desktop :

first we need to edit the claude_desktop_config.json under the  C:\Users\<username>\AppData\Roaming\Claude

We need to add to the file the config below

{
  "mcpServers": {
    "my‑mcp": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "http://localhost:7071/runtime/webhooks/mcp/sse"
      ]
    }
  }
}

we can see our local server up and running ,its time to test

Conclusion

In this guide, we walked through how to create an MCP server using Azure Functions and Python, and tested it with tools like MCP Inspector, VS Code, and Claude Desktop. By following these steps, you now have a fully functional server environment ready for further experimentation and development.

In our next blog post, we’ll explore how to achieve the same setup using C#, giving you an alternative approach and expanding your toolkit for building MCP servers in Azure. Stay tuned!

What is MCP (Model Context Protocol)?

The Model Context Protocol (MCP) is an open protocol developed by Anthropic that enables large language models (LLMs) to integrate with external data sources and tools in a standardized way. It creates a framework that allows AI tools to communicate with each other seamlessly.

In simpler terms, instead of building custom adapters every time we want an AI tool to perform a specific function—like reading a Figma design or managing a database—MCP lets us plug that tool in directly, provided our main AI interface understands the protocol.

MCP defines how AI models can:

• Call external tools
• Fetch data
• Interact with various services
• Access context in a manner that’s generalizable across different integrations
  
  

Why Use MCP?

Consider the traditional approach when you want your AI model to connect to your resources. You would need to:

1. Ask your developers to create custom connectors or extensions
2. Create web APIs
3. Handle authentication
4. Develop additional functionality as needs arise

MCP eliminates this complexity by providing a standardized way for AI models to interact with external tools and data sources.

Real-World Example: Updating My Microsoft Acronyms Project

To demonstrate MCP’s capabilities, I tested it on a small project I created two years ago: Microsoft Acronyms. Since I’ve been busy with work, family, and other projects, I hadn’t updated it with the latest acronyms.

Traditional Process (Without MCP)

Without MCP, updating the site would require me to:

1. Go to GitHub and examine the project structure
2. Search the internet for new Microsoft acronyms
3. Compare them against what’s already on my website
4. Consult an AI model like GPT about the newest acronyms
5. Pull the project
6. Create a branch
7. Update the file
8. Push changes
9. Create a pull request

With MCP

Using MCP and a GitHub MCP server, I simply asked in one prompt: “Can you create a new pull request on my repo: MicrosoftAcronyms001 and also update the data.tsx file with more and newer Microsoft Acronyms?”

That’s it! A new PR was created with updated content, no manual intervention required.

Setting Up the GitHub MCP Server

If you want to try this yourself, here’s how to set up the GitHub MCP server:

1. First, download the GitHub MCP Server from: https://github.com/github/github-mcp-server
2. In Visual Studio Code, go to Settings and activate the MCP server option.
3. Edit the settings.json file to add your server(s). You’ll need to replace ${input:github_token} with a Personal Access Token (PAT) generated from your GitHub account:

{
  "mcp": {
    "inputs": [
      {
        "type": "promptString",
        "id": "github_token",
        "description": "GitHub Personal Access Token",
        "password": true
      }
    ],
    "servers": {
      "github": {
        "command": "docker",
        "args": [
          "run",
          "-i",
          "--rm",
          "-e",
          "GITHUB_PERSONAL_ACCESS_TOKEN",
          "ghcr.io/github/github-mcp-server"
        ],
        "env": {
          "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}"
        }
      }
    }
  }
}

1. Click “Run” and Docker will launch the server locally. (If you prefer not to use Docker, check the official repository for alternative configuration options.)
2. Once the server is running, go to Agent mode in Visual Studio Code and check the tool buttons for available servers – you should see your MCP server listed.
3. Now you can ask Copilot (with Agent mode and the MCP server for GitHub) to perform tasks like creating pull requests or updating files.

Important Note: Make sure your PAT has the correct permissions. When I first tried this, I had only given read permissions, which prevented the MCP from creating the pull request.

MCP SERVER running

Now since the server is running , we click on the button select tools , and we scroll down we can see any MCP server that we have added .

now after I asked the Model that i have used here : Claude 3.7 , as you can see it”s asked me to use the mcp server I provided , and started to use it’s sub models to aces my repo , get the file content that i need it to be updated it and create new branch.

Results : As you can see , I have a PR created and that have updated the file with some Acronyms , the pipeline worked fine and the file contain new content

And now I asked to merge the Pull request too :

After the merge , i went to my website to test the new acronyms if its exist and the result as you can see , it works .

Conclusion

MCP represents a significant advancement in how we integrate AI models with external tools and data. By providing a standardized protocol for these interactions, it eliminates the need for custom development work and makes AI integration much more accessible.

Isn’t it amazing that all of this can be accomplished without developing any connectors or manual intervention? I believe MCP is just the beginning of a new era in AI integration, and I look forward to exploring its capabilities further in future posts.

List of available Servers & Clients : https://github.com/modelcontextprotocol/servers?tab=readme-ov-file

Think of it as a Super-Smart Creative Assistant

• It’s like having a helper that can:
  
  • Write stories and emails
  • Create images from descriptions
  • Answer questions
  • Complete your sentences
  • Help with coding
    

Real-Life Example

Just like how a chef can create new recipes from ingredients, Gen AI creates new content from what it has learned!

How Does Gen AI Work?

Three Simple Steps:

1. Learning Phase
   • Reads tons of information (like reading millions of books)
   • Learns patterns (like learning a language)
     
2. Understanding Phase
   • Recognizes what you’re asking
   • Processes your request
     
3. Creation Phase
   • Creates new content based on what it learned
   • Tries to be helpful and relevant

Common Gen AI Tools You Might Know

• ChatGPT: Your friendly chat buddy
• DALL-E: The digital artist
• GitHub Copilot: Your coding assistant
• Midjourney: The image creator
• Claude: The helpful analyst

But Wait, There’s a Catch!

Limitations of Basic Gen AI:

• Sometimes makes things up
• Can be outdated
• Might mix up facts
• Doesn’t know about your specific needs

This is where RAG comes in to save the day!

(Retrieval-Augmented Generation)

Think of RAG as Gen AI with a Personal Library!

Simple Example:

• Regular Gen AI is like asking a friend who read lots of books
• RAG is like asking a friend who can also check your personal notes

How Does RAG Work?

Three Easy Steps:

1. Retrieval
   • Searches through your specific documents
   • Finds relevant information
2. Augmentation
   • Adds this information to what it already knows
3. Generation
   • Creates responses using both sources

RAG in Real Life

Example Scenarios:

Customer Service Bot

• WITHOUT RAG: Gives general answers
• WITH RAG: Knows your company’s specific policies

Technical Support

• WITHOUT RAG: Provides generic solutions
• WITH RAG: Uses your product’s actual documentation

Benefits of RAG

1. More Accurate
   • Uses your specific information
   • Reduces made-up answers
     
2. Always Updated
   • Can access new information
   • Stays current with your needs
     
3. Customized Help
   • Knows your context
   • Gives relevant answers

Real-World Applications

Where RAG Shines:

1. Business
   • Customer support
   • Internal documentation
   • Employee training
     
2. Education
   • Personalized tutoring
   • Course material assistance
   • Research help
     
3. Healthcare
   • Medical record assistance
   • Treatment information
   • Patient care guidelines

Simple RAG Example in Action

Scenario: Company Help Desk

Question: “What’s our vacation policy?”

Regular Gen AI Response:

“Generally, companies offer 2-3 weeks vacation…”

RAG-Enhanced Response:

“According to our company handbook, full-time employees get 25 days plus 5 wellness days…”

Tips for Using Gen AI with RAG

1. Be Specific
   • Clear questions get better answers
     
2. Verify Important Info
   • Double-check critical details
     
3. Start Simple
   • Begin with basic questions
   • Gradually ask more complex ones

The Future is Bright!

With RAG combined with Gen AI today , the future is bright , we will have better ,faster and occurred answers .

What’s Coming Next:

• Better accuracy
• Faster responses
• More personalization
• Easier integration

Remember: Gen AI + RAG = Smarter Assistance!