This is a quick update on 3 tech and 1 personal topic: All of them would not have been worth a blog post, but all 4 combined make it valuable - I hope :)

The TL;DR

The very brief update:

That’s it. Unless you want to understand a few more details, then the next sections are for you.

The Details: Docker Sandboxes

Looking back at the first blog post mentioned above, I shared the following configuration for a mixin kit that can be used to make a Docker Sandbox ready for the Azure DevOps MCP Server:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

schemaVersion: "1"
kind: mixin
name: az-devops
displayName: az-devops
description: Azure DevOps

network:
  allowedDomains:
    - "**.dev.azure.com"
    - "**.visualstudio.com"
  serviceDomains:
    4psnl.visualstudio.com: az-devops
    dev.azure.com: az-devops
    mcp.dev.azure.com: az-devops
  serviceAuth:
    az-devops:
      headerName: Authorization
      valueFormat: "Basic %s"

commands:
  install:
    - command: "mkdir /usr/local/share/npm-global/lib"
      user: "1000"
      description: Create missing folder

If you take a close look at line 12, you will see that I snuck in 4psnl.visualstudio.com as serviceDomain. The reason for that is that some interactions with Azure DevOps for quite old organizations use the old <your-org>.visualstudio.com URL structure. As you may have guessed from the name, 4psnl.visualstudio.com is one of the organizations used for the Dutch company group 4PS, my employer. But until recently, you couldn’t use wildcards when defining serviceDomains, so I had to add it explicitly, although that doesn’t make sense for anyone outside of 4PS. Fortunately, this was changed in one of the latest releases, so I can now write something like this:

1
2
3
4
5
6
7
8
9

network:
  ...
  serviceDomains:
    "*.visualstudio.com": az-devops
    ...
  serviceAuth:
    az-devops:
      headerName: Authorization
      valueFormat: "Basic %s"

With that in place, the Docker Sandbox will inject the right credentials into all traffic going to *.visualstudio.com without having to specify a dedicated org name.

I have also submitted this kit to the repo where Docker hosts them via this PR. I hope this will get accepted and then you can use it even more easily, but I’ll probably share another little update if and when that happens.

The Details: Authentication with the AL MCP Server

In the second blog post mentioned above, I explained that I had to use a little workaround to get authentication to work. The reason was that my backend used NavUserPassword authentication, but that made the AL MCP Server always ask for credentials. I could avoid this by using Windows authentication, but that was a) wrong and b) a bad workaround that probably would have fired back after a while.

Fortunately, Microsoft has decided to fix this based on a little GitHub issue where I reported the problem. The fix actually did quite a bit more, but most importantly for my scenario, it added a flag --noAuth to startup which makes the AL MCP never ask for credentials. So the MCP Server reference now needs to look like this and I want to specifically point out line 9:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  "mcpServers": {
    "al": {
      "command": "/home/agent/.dotnet/tools/al",
      "args": [
        "launchmcpserver",
        "--transport",
        "stdio",
        "--noAuth",
        "."
      ],
      "env": {
        "DOTNET_ROOT": "/home/agent/.dotnet"
      }
    }
  }
}

With that, I can now interact with my backend through the MCP tools and it will never ask for credentials. As the Docker Sandbox injects the credentials, it just magically works! Same as above, I also created a PR to make the AL MCP preparation kit available in the Docker repo.

The change also introduced new environment variables that can be used for the same purpose:

  • BC_SERVER_URL
  • BC_SERVER_INSTANCE
  • BC_SERVER_PORT
  • BC_SERVER_USERNAME
  • BC_SERVER_PASSWORD
  • BC_ACCESS_TOKEN

I think the names are pretty self-explanatory. The first three can be used to overwrite the settings in your launch.json, the last three can be used for authentication. As I already have a great option for my scenario with the --noAuth param, I didn’t use those, but I am pretty sure that they will come in handy at some point.

In any case, great to see that Microsoft is willing to make changes to better support AI-assisted development.

The Details: KAITO recognized by AI Runway

Referencing the third blog post mentioned above, I showed this command to create an AKS cluster:

1
2
3
4
5
6

az aks create \
  --location $env:AZURE_LOCATION \
  --resource-group $env:AZURE_RESOURCE_GROUP \
  --name $env:CLUSTER_NAME \
  --enable-oidc-issuer \
  --generate-ssh-keys

At a later step, I showed how to manually install KAITO on top of it:

1
2
3
4
5

helm repo add kaito https://kaito-project.github.io/kaito/charts/kaito
helm install kaito-workspace kaito/workspace \
  --namespace kaito-workspace \
  --create-namespace \
  --set featureGates.disableNodeAutoProvisioning=true

Already at that time, the parameter --enable-ai-toolchain-operator existed and did install KAITO, but AI Runway failed to detect that. I raised a first issue about it and got the feedback that it was resolved, but it actually still didn’t work for me, so I raised another issue. This time, the fix also worked for me. So now all you need to do is set that parameter when creating the cluster like this:

1
2
3
4
5
6
7

az aks create \
  --location $env:AZURE_LOCATION \
  --resource-group $env:AZURE_RESOURCE_GROUP \
  --name $env:CLUSTER_NAME \
  --enable-oidc-issuer \
  --generate-ssh-keys \
  --enable-ai-toolchain-operator

With that in place, there is no need anymore to install KAITO separately, but AI Runway automatically finds it.

The Details: I am still an MVP

The last and actually least relevant piece of this blog post is the news that I got renewed as MVP, again in both the Azure (Kubernetes and Open Source) and Business Applications (Business Central) categories. It is my 10th year in the program and as you can probably imagine, I am quite proud about that. A lot of time and effort goes into maintaining that status and I am very thankful to both 4PS and Hilti for allowing me to invest some of my working time into that topic. On the other hand, in our world full of big challenges from geopolitics through environmental to societal problems, I still struggle to be as happy about it as I was in the past. Anyway, I actually am happy about it and I wanted to share that, so here we are.