I spent this weekend exploring MCP (Model Context Protocol), a protocol that allows LLMs (Large Language Models) to interact with other systems. This means you can connect your LLM, like Claude, to your file system, for example. You can then instruct your LLM to "change all my file names with whitespace to underscores," and it will execute the commands on your system, making the actual changes. This enables you to use natural language to interact with the systems you're working with, potentially transforming how we engage with our systems.

How do I interact with MCP?

To interact with an MCP, you need a client that can communicate with an MCP server. See here for a matrix of supported clients. In this post, I will use Claude Desktop. Since I’m running Linux and there’s no officially supported version of Claude, I’m using the unofficial desktop version of Claude Desktop. NB: Read and evaluate the code before you run it!

Adding an MCP server

After installing the desktop version, you can add your first MCP server. Our MCP server in this example will require npx. Check if you have it installed:

npx --version

If not, install it.

We will then add an MCP server to your Claude desktop config that interacts with your local file system:

vim .config/Claude/claude_desktop_config.json

Add the following:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/home/oystein/Desktop",
        "/home/oystein/Downloads"
      ]
    }
  }
}

This list will specify the directories in which the LLM can operate. Replace <myhomedir> with the name of your home directory.

Restart Claude Desktop. You will now see a hammer with a number, indicating that you have MCP tools available:

You can also select the “attach” button to the right of the hammer to see connected MCP servers:

You can see that I have two file servers installed.

Make changes to your local filesystem

You can now start interacting with Claude to make changes to your file system. Here, I ask it to create a script in my Desktop directory:

You will have to confirm when it wants to execute commands on your system:

Claude does its work:

And to confirm that it actually exists:

As you can see, the file now exists locally in my file system.

A very basic example, but full of potential. Let’s take it a bit further and see how we can interact with Azure DevOps.

Interacting with Azure DevOps

In this example, I will use the mcp-server-azure-devops for interacting with Azure DevOps. Note: I recommend using this only in your personal lab Azure DevOps organization.

Start by adding the Azure DevOps MCP server to your Claude Desktop config:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/home/oystein/Desktop",
        "/home/oystein/Downloads"
      ]
    },
    "azureDevOps": {
      "command": "npx",
      "args": ["-y", "@tiberriver256/mcp-server-azure-devops"],
      "env": {
        "AZURE_DEVOPS_ORG_URL": "https://dev.azure.com/<myorg>",
        "AZURE_DEVOPS_AUTH_METHOD": "pat",
        "AZURE_DEVOPS_PAT": "<redacted>",
        "AZURE_DEVOPS_DEFAULT_PROJECT": "Demo"
      }
    }
  }
}

Add your organization in <myorg> and your Azure DevOps PAT to <redacted>. I granted the PAT read access with write access to tasks.

Restart Claude and ask it to:

It will start listing all tasks assigned to me and their states:

I can even add comments and close tasks:

Conclusion

This was a quick introduction to the how and why of the MCP server. Even though it’s early, I believe this will significantly change our daily workflow, and it will be interesting to see what MCP server capabilities people will develop. However powerful it is, security departments will have a lot to monitor going forward, and the chance of user mistakes can increase since one can quickly select “yes” to all prompts asked by the LLM.

Many platform engineers focus on automating individual tasks that run from their local machines. While these scripts are helpful, the real value comes when automation is embedded into a structured process. The comic below illustrates a common scenario in many IT departments where an automated process is missing:

For many developers and platform engineers, this is an all-too-familiar day. These interruptions are costly—not just in time, but in focus. Constant context switching slows development, delays progress, and frustrates everyone involved. Developers waste time waiting for what they need, while platform engineers get stuck handling repetitive requests instead of improving the system.

The Problem: Scripting Tasks Doesn’t Solve the Root Issue

A typical reaction from platform engineers is to write a script that helps automate these tasks. While this reduces some manual effort, it doesn’t eliminate the costly back-and-forth between developers and platform teams. The interruptions continue, context switching remains, and the fundamental inefficiencies persist.

Now, imagine taking that script and embedding it into a fully automated process that considers the entire developer experience.

The Solution: Automate the Process, Not Just the Task

We can simplify it like this:

By providing a self-service interface, developers can request common services without interrupting anyone. If necessary, approval steps can be added, and validation checks can ensure input accuracy. By automating the entire process, we eliminate all unnecessary communication between teams.

In the early stages, simplicity is key. For instance, you might start with a GitHub Actions pipeline that developers can trigger on demand, serving as a straightforward self-service interface. As your team gains experience and your processes mature, you can explore more advanced interface options to further streamline operations.

Even if the initial process isn’t perfect, having a process in place is always better than having none at all—it creates a foundation that you can continuously improve.

The benefits extend beyond just saving time:

• ✅ Clear traceability – Every request and approval is logged.

• ✅ Improved security – Compliance can be built into the process itself.

• ✅ Defined business processes – Security teams and stakeholders can refine automation rather than fight ad-hoc scripts.

If security is unhappy with how something is automated? No problem—the process can be improved. If the user experience is lacking? Refine the workflow. This is where the real value of automation begins to take effect.

Automation as a Business Value Driver

One of the biggest challenges platform engineers face is communicating the value of their work to stakeholders. Automating IT processes makes this easier by providing clear, measurable benefits.

Without a structured, automated workflow, each request costs nearly 10,000 NOK in lost productivity. Multiply that by an estimated 500 requests per year, and the total yearly cost approaches 5 million NOK—just for a single process!

Let’s break down the numbers using the app registration process as an example:

Cost Breakdown for One App Registration Request

1️⃣ Developer Time

• Total Process Time: 5 hours

• Hourly Rate: 1500 NOK/hour

• Total Cost: 5 hours * 1500 NOK = 7,500 NOK

2️⃣ Interruption Costs (Context Switching & Actual Work)

• Tech Lead: 23 minutes ≈ 0.38 hours

• Platform Engineer One: 23 minutes ≈ 0.38 hours

• Platform Engineer Two: 23 minutes (interruptions) + 30 minutes (actual work) ≈ 0.88 hours

Total Interruption Time:
0.38 + 0.38 + 0.88 = 1.64 hours

• Total Cost: 1.64 hours * 1500 NOK = 2,460 NOK

3️⃣ Total Cost for One Request

• Total Cost: 7,500 NOK + 2,460 NOK = 9,960 NOK

Yearly Cost Impact

• Number of App Registrations per Year: 500

• Total Yearly Cost:
  500 * 9,960 NOK = 4,980,000 NOK

Take a moment to consider this:
Each app registration request costs nearly 10,000 NOK. Multiply that by 500 requests a year, and you're facing almost 5 million NOK in annual expenses. This stark figure shows how even minor inefficiencies—like repeated context switching and manual interventions—will result in massive, unnecessary expenses. Streamlining these processes through automation isn’t just about saving time; it’s about saving a substantial amount of money.

The Hidden Benefit: Platform Engineers Win Too

Beyond the cost savings, platform engineers benefit directly:
✅ Less context switching
✅ Fewer repetitive tasks
✅ More time to focus on higher-impact automation

By shifting from task automation to process automation, organizations can save money, improve security, and accelerate development—all while making life easier for everyone involved.

The Best Part? The Cost Can Be Reduced to Practically Zero

By investing in process automation, this 5 million NOK cost can be reduced to nearly zero. The solution isn’t just about automation—it’s about building scalable, efficient processes that eliminate waste at its core.

The Challenge with Portal-Based Elevation

The Azure Portal interface for PIM, while functional, presents several operational friction points:

• Time-consuming role selection, especially with multiple assignments

• Significant context switching for developers working primarily in PowerShell

• Interrupted development flow when managing multiple role elevations

A PowerShell-Based Solution

For developers who primarily work in PowerShell, here's a solution that simplifies the role elevation process:

param(
   [Parameter()]
   [string]$SubscriptionId,

   [Parameter()]
   [string[]]$RoleDefinitionName = @("Contributor", "User Access Administrator"),

   [Parameter()]
   [string]$Justification = "Local development",

   [Parameter()]
   [int]$DurationInHours = 8
)

$ErrorActionPreference = "Stop"

$currentContext = Get-AzContext

ForEach ($role in $RoleDefinitionName) {
   Write-Verbose "Elevating to role $role on subscription $SubscriptionId for $DurationInHours hours" -Verbose:$true
   $roleDefinitionId = (Get-AzRoleDefinition -Name $role).Id
   $inputObject = @{
       Name = [guid]::NewGuid().ToString()
       Scope = "/subscriptions/$subscriptionId/"
       ExpirationDuration = "PT${DurationInHours}H"
       ExpirationType = "AfterDuration"
       PrincipalId = (Get-AzAdUser -Mail $currentContext.Account.Id).Id
       RequestType = "SelfActivate"
       RoleDefinitionId = "/subscriptions/$SubscriptionId/providers/Microsoft.Authorization/roleDefinitions/$roleDefinitionId"
       ScheduleInfoStartDateTime = Get-Date -Format o
       Justification = $Justification
       Verbose = $false
   }

   New-AzRoleAssignmentScheduleRequest @inputObject
}

Implementation Guide

1. Save the script as Elevate-PimRole.ps1

2. Execute with your subscription ID:

./Elevate-PimRole.ps1 -SubscriptionId xxxxxxxx-xxxx-xxxx-xxxxxxxx

Important Considerations

• The default configuration elevates both Contributor and User Access Administrator roles

• The script assumes subscription-level scope; modify the scope parameter for resource group-level operations

• Default elevation duration is set to 8 hours

• Custom justification messages can be provided via the -Justification parameter

This approach maintains security while significantly improving developer productivity by eliminating unnecessary context switching and portal navigation.