So think of the site less as an authoritative reference and more as careful notes, taken in public. This post is about why I started it and where it stands.

The gap I kept running into

When I started reading, the material felt oddly polarized. docs.kernel.org is authoritative but tells you what and how — it’s reference documentation, not a narrative. LWN is the gold standard for the why, but it’s news-shaped — tied to a particular patch series — and not organized as something you can sit down and browse by subsystem.

What I kept wishing for was a current, organized place that explained the reasoning: the trade-offs, the alternatives that got rejected, the mailing-list arguments that produced the design we ended up with. I couldn’t find it, so I started assembling it as I learned. It’s meant to complement docs.kernel.org, not compete with it.

Where it stands today

Today it spans roughly 375 pages across 28 subsystems, built as a static MkDocs site. Memory management is the deepest part (the page allocator, reclaim, folios, huge pages, get_user_pages, the kernel’s address-space layout), with broader coverage of the scheduler, networking, the architecture layer, io_uring, locking, filesystems, and more.

Two principles I try to hold to — precisely because I’m not the expert in the room:

• Every claim should trace to a primary source — a specific commit on git.kernel.org, an LWN article, a lore.kernel.org thread. The authority lives in those sources, not in me. If I can’t cite it, it doesn’t belong on the site, and where I’ve summarized something the original is one click away.
• The cross-references stay honest — there’s CI that fails the build on any broken internal link or anchor, so as the site grows the links between pages don’t quietly rot.

What I try to do on a page

The goal isn’t to list the right structs and functions — docs.kernel.org and the source already do that better than I could. What I aim for is an honest attempt at why. Take get_user_pages: the part I found worth understanding wasn’t the function signature, it was why the kernel ended up with two nearly-identical APIs, why an ordinary reference count couldn’t express “this page is being used for DMA,” and how that ambiguity led to a long tail of subtle bugs. I don’t always get this right, and some pages are thinner or shakier than others.

Where it’s going

It’s open source, and there’s a lot of surface left to cover — scheduler extensions, Rust in the kernel, the mainlining of PREEMPT_RT, and plenty of subsystems that are still thin. I’ll keep adding to it as I learn.

If any of this is your kind of thing, it’s all at kernel-internals.org.

Here’s what’s new.

Contents:

• Write Operations
• Workflow Lifecycle Management
• Connector Management
• Knowledge Tools
• Performance Improvements
• Updated Tool Summary

Write Operations

The biggest change in v0.3 is the shift from read-only to read-write. Three new tools let you manage workflow definitions:

• create_workflow — Creates a new workflow. For Consumption SKU, this creates a new Logic App resource. For Standard SKU, it adds a workflow to an existing Logic App.
• update_workflow — Modifies an existing workflow’s definition. Handles the API differences between SKUs automatically.
• delete_workflow — Removes a workflow entirely. Use with caution.

Now you can ask your AI assistant things like:

• “Create a workflow that triggers on HTTP request and sends an email”
• “Add a condition to check if the order total exceeds $1000”
• “Update the workflow to retry failed API calls”

The AI can build the workflow definition and deploy it directly.

Workflow Lifecycle Management

v0.3 adds two new tools for controlling workflow state, complementing the existing run_trigger and cancel_run:

• enable_workflow — Enables a workflow that was previously disabled.
• disable_workflow — Disables a workflow without deleting it. Useful for maintenance or temporarily stopping processing.
• run_trigger — Manually fires a workflow trigger for testing. No need to wait for a schedule or craft an HTTP request.
• cancel_run — Cancels a workflow run that’s in Running or Waiting status. Handy when a workflow is stuck or you need to stop a long-running process.

Example prompts:

• “Disable the order-processing workflow while I update the database”
• “Run the daily-report workflow now so I can test it”
• “Cancel all running instances of the batch-import workflow”

Connector Management

Logic Apps connect to external services through API connections. v0.3 adds tools to work with connectors programmatically:

• create_connection — Creates a new API connection for managed connectors like SQL Server, Service Bus, or SharePoint. Supports both OAuth and parameter-based authentication.
• get_connector_swagger — Fetches the OpenAPI spec for any managed connector, so the AI understands what operations and parameters are available.
• invoke_connector_operation — Calls dynamic connector operations like GetTables, GetQueues, or GetSchemas through an existing connection.

This enables conversational flows like:

• “Connect to my SQL database and show me the available tables”
• “What operations does the Service Bus connector support?”
• “List all queues in my Service Bus namespace”

The AI can discover schemas and structures, then use that information to build workflows that reference the right tables and fields.

Knowledge Tools

One challenge with AI assistants is they don’t always know the specifics of Logic Apps — expression syntax, connector quirks, SKU differences. v0.3 bundles documentation directly into the server through four knowledge tools:

The guides are markdown files in the knowledge folder. When you install the MCP server, these files are bundled with it — no separate download needed. When you ask “Why is my expression failing?”, the AI pulls the relevant troubleshooting docs and gives you targeted advice instead of generic suggestions.

Performance Improvements

v0.3 includes several reliability improvements:

• Retry with exponential backoff — Transient failures (429s, 5xx errors) are automatically retried with jitter to avoid thundering herd issues.
• SKU detection caching — The server caches whether a Logic App is Consumption or Standard, avoiding repeated API calls.
• Parallelized operations — get_connector_swagger fetches connector metadata in parallel, reducing response time.
• Content link limits — Fetching action inputs/outputs has a 30-second timeout and 10MB size limit to prevent hanging on large payloads.

Updated Tool Summary

The server now has 37 tools:

The shift to write operations opens up new possibilities. Your AI assistant can now help you not just understand and debug workflows, but build and manage them. Combined with the knowledge tools, it has the context to make better suggestions.

If you’re already using the server, update with npm update -g @laveeshb/logicapps-mcp. If not, check out the repo to get started.

Contents:

• Getting Started
• Sending Messages
• Authentication
• Tuning the Listener
• Under the Hood
• Local Development
• Source Code

Getting Started

See a complete example in the sample project.

Install the package:

pip install azure-functions-sqs

Write a function that triggers on SQS messages:

import json
import logging

from azure_functions_sqs import SqsTrigger, SqsMessage

trigger = SqsTrigger(queue_url="%SQS_QUEUE_URL%")

@trigger
def process_message(message: SqsMessage) -> None:
    logging.info(f"Received: {message.message_id}")
    logging.info(f"Body: {message.body}")

    # Process the message...
    data = json.loads(message.body)
    logging.info(f"Order ID: {data.get('order_id')}")

    # If this function completes without exception, the message is deleted
    # If an exception is raised, message becomes visible again for retry

Configure your queue URL in local.settings.json:

{
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "python",
    "SQS_QUEUE_URL": "https://sqs.us-east-1.amazonaws.com/123456789/my-queue"
  }
}

The SqsMessage class gives you access to all SQS message properties:

@trigger
def process(message: SqsMessage) -> None:
    # Core properties
    print(message.message_id)
    print(message.body)
    print(message.receipt_handle)

    # System attributes
    print(message.attributes.get("SentTimestamp"))
    print(message.attributes.get("ApproximateReceiveCount"))

    # FIFO queue properties
    print(message.attributes.get("MessageGroupId"))
    print(message.attributes.get("SequenceNumber"))

    # Custom message attributes
    for name, attr in message.message_attributes.items():
        print(f"{name}: {attr.string_value}")

Sending Messages

Output Binding

The simplest way to send messages — decorate a function and return the message body (see full example):

import azure.functions as func
from azure_functions_sqs import SqsOutput
import json

app = func.FunctionApp()
output = SqsOutput(queue_url="%OUTPUT_QUEUE_URL%")

@app.function_name("SendToSqs")
@app.route(route="send", methods=["POST"])
@output
def send_to_sqs(req: func.HttpRequest) -> str:
    body = req.get_json()
    return json.dumps({
        "timestamp": body.get("timestamp"),
        "data": body.get("data"),
        "source": "azure-function",
    })

Batch Sending with SqsCollector

For sending multiple messages efficiently, use SqsCollector — it batches messages in groups of 10 (the SQS limit), similar to IAsyncCollector in .NET (see full example):

from azure_functions_sqs import SqsCollector

@app.function_name("BatchSendToSqs")
@app.route(route="batch", methods=["POST"])
def batch_send(req: func.HttpRequest) -> func.HttpResponse:
    collector = SqsCollector(queue_url="%OUTPUT_QUEUE_URL%")

    for item in req.get_json().get("items", []):
        collector.add({
            "item_id": item.get("id"),
            "action": item.get("action", "process"),
        })

    sent_count = collector.flush()

    return func.HttpResponse(
        json.dumps({"messages_sent": sent_count}),
        mimetype="application/json",
    )

FIFO Queues

For FIFO queues (URL ends with .fifo), specify a message group ID (see full example):

from azure_functions_sqs import SqsOutput, SqsOutputOptions

fifo_output = SqsOutput(
    queue_url="%FIFO_QUEUE_URL%",
    options=SqsOutputOptions(message_group_id="order-processing"),
)

@app.route(route="fifo", methods=["POST"])
@fifo_output
def send_to_fifo(req: func.HttpRequest) -> str:
    return json.dumps(req.get_json())

Authentication

The extension uses the boto3 credential chain. If you don’t provide explicit credentials, the SDK looks for them in this order:

1. Environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
2. Shared credentials file (~/.aws/credentials)
3. IAM role for EC2/ECS/EKS

Local Development

Set environment variables in local.settings.json:

{
  "Values": {
    "AWS_ACCESS_KEY_ID": "your-access-key",
    "AWS_SECRET_ACCESS_KEY": "your-secret-key",
    "AWS_REGION": "us-east-1"
  }
}

Or configure a profile with the AWS CLI:

aws configure

Workload Identity Federation (Recommended for Production)

The best approach for Azure-hosted functions is OIDC federation between Azure AD and AWS. No stored credentials — your function uses its Azure Managed Identity to assume an AWS IAM role.

1. Create an OIDC Identity Provider in AWS IAM that trusts Azure AD
2. Create an IAM role with a trust policy for your Azure Function’s managed identity
3. Use AssumeRoleWithWebIdentity to get temporary AWS credentials

This eliminates credential management entirely. See AWS docs for setup details.

Azure Key Vault (Alternative)

If federation isn’t an option, store your AWS credentials in Azure Key Vault and reference them in app settings:

AWS_ACCESS_KEY_ID=@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/aws-key-id/)
AWS_SECRET_ACCESS_KEY=@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/aws-secret-key/)

Tuning the Listener

Configure polling behavior with SqsTriggerOptions:

from datetime import timedelta
from azure_functions_sqs import SqsTrigger, SqsTriggerOptions

trigger = SqsTrigger(
    queue_url="%SQS_QUEUE_URL%",
    options=SqsTriggerOptions(
        max_number_of_messages=10,
        visibility_timeout=timedelta(seconds=30),
        polling_interval=timedelta(seconds=5),
    ),
)

Under the Hood

The trigger uses a sequential polling loop:

┌─────────────────────────────────────────────────────────────────┐
│                         Polling Loop                            │
└─────────────────────────────────────────────────────────────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │  ReceiveMessage     │
                    │  (long poll, 20s)   │
                    └─────────────────────┘
                               │
              ┌────────────────┴────────────────┐
              │                                 │
              ▼                                 ▼
     ┌─────────────────┐              ┌─────────────────┐
     │  Messages?  Yes │              │  Messages?  No  │
     └─────────────────┘              └─────────────────┘
              │                                 │
              ▼                                 ▼
     ┌─────────────────┐              ┌─────────────────┐
     │ Execute Function│              │ Wait interval   │
     └─────────────────┘              │ (5s default)    │
              │                       └─────────────────┘
              │                                 │
      ┌───────┴───────┐                        │
      │               │                        │
      ▼               ▼                        │
┌──────────┐   ┌──────────┐                    │
│ Success  │   │ Failure  │                    │
└──────────┘   └──────────┘                    │
      │               │                        │
      ▼               ▼                        │
┌──────────┐   ┌──────────────┐                │
│ Delete   │   │ Leave in     │                │
│ message  │   │ queue (retry)│                │
└──────────┘   └──────────────┘                │
      │               │                        │
      └───────┬───────┘                        │
              │                                │
              └────────────────┬───────────────┘
                               │
                               ▼
                         (repeat loop)

async def _poll_loop(self):
    while self._running:
        messages_received = await self._poll_and_process()

        if messages_received == 0:
            await asyncio.sleep(self._options.polling_interval.total_seconds())

Long polling (20-second wait time) reduces API calls — instead of hitting SQS every second, the SDK waits for messages to arrive or the timeout to expire.

Local Development

The extension works with LocalStack for local development without AWS credentials:

trigger = SqsTrigger(
    queue_url="http://localhost:4566/000000000000/test-queue",
    region="us-east-1",
    aws_key_id="test",
    aws_access_key="test",
)

See the LocalStack guide for Docker setup. The same scripts work for Python.

Source Code

The extension is open source on GitHub. Key files:

• Python extension source
• Sample functions
• Tests

Here’s how it works.

Contents:

• Why This Approach
• The Architecture
• Writing a Function
• The QR Generator Sample
• Deploying to Azure
• Try It

Why This Approach

Azure Functions has built-in support for languages like C#, JavaScript, Python, and Java. For Go, the recommended approach is Custom Handlers — the host starts your HTTP server and forwards requests.

Why this works well:

• No SDK required — Use standard net/http, the same code runs anywhere
• Simple architecture — Just an HTTP server, nothing special
• Easy debugging — Test locally with go run or any HTTP client
• Production ready — Custom Handlers are a documented, stable feature
• Portable — Your code isn’t tied to Azure, it’s just a Go web server

The Architecture

The Azure Functions Host starts your Go binary and forwards HTTP requests:

Internet → Azure Functions Host → Your Go Binary (net/http server)

Your binary reads the port from an environment variable and serves requests (main.go):

func main() {
    port := os.Getenv("FUNCTIONS_CUSTOMHANDLER_PORT")
    if port == "" {
        port = "8080"
    }

    http.HandleFunc("/api/hello", helloHandler)
    http.HandleFunc("/api/health", healthHandler)

    log.Printf("Starting server on port %s", port)
    log.Fatal(http.ListenAndServe(":"+port, nil))
}

The host.json tells Azure Functions to use your binary as a Custom Handler:

{
  "version": "2.0",
  "customHandler": {
    "description": {
      "defaultExecutablePath": "handler"
    },
    "enableForwardingHttpRequest": true
  }
}

With enableForwardingHttpRequest: true, the host passes through HTTP requests directly — your Go code sees standard http.Request and http.ResponseWriter.

Writing a Function

A simple hello function:

func helloHandler(w http.ResponseWriter, r *http.Request) {
    name := r.URL.Query().Get("name")
    if name == "" {
        name = "World"
    }

    response := map[string]string{
        "message": fmt.Sprintf("Hello, %s!", name),
    }

    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(response)
}

Each function needs a function.json that defines its trigger:

{
  "bindings": [
    {
      "authLevel": "anonymous",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": ["get", "post"],
      "route": "hello"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "$return"
    }
  ]
}

That’s it. Standard Go HTTP handlers, standard JSON responses.

The QR Generator Sample

The repo includes a complete QR code generator with a web UI (main.go):

func handleGenerate(w http.ResponseWriter, r *http.Request) {
    if r.Method == http.MethodGet {
        // Serve the web UI
        w.Header().Set("Content-Type", "text/html")
        fmt.Fprint(w, landingPageHTML)
        return
    }

    // POST: Generate QR code
    var req GenerateRequest
    json.NewDecoder(r.Body).Decode(&req)

    png, _ := qrcode.Encode(req.Content, qrcode.Medium, req.Size)

    json.NewEncoder(w).Encode(GenerateResponse{
        Image:   base64.StdEncoding.EncodeToString(png),
        Content: req.Content,
        Size:    req.Size,
    })
}

The web UI lets users enter text and see the generated QR code:

• GET /generate — Interactive web page
• POST /generate — API returns base64-encoded PNG
• GET /health — Health check endpoint

Deploying to Azure

Each sample includes deployment scripts (deploy.sh, deploy.ps1). For the QR generator:

cd samples/qr-generator

# Deploy to Azure (creates everything: resource group, storage, function app)
./deploy.sh -g my-resource-group -l westus2

# Or on Windows
.\deploy.ps1 -ResourceGroupName my-resource-group -Location westus2

The script:

1. Cross-compiles to Linux (GOOS=linux GOARCH=amd64)
2. Creates Azure resources (resource group, storage account, function app)
3. Deploys with func azure functionapp publish

For local development:

# Build
go build -o handler .

# Run with Azure Functions Core Tools
func start

Try It

Clone the repo and try the samples:

git clone https://github.com/laveeshb/azure-functions-go-worker.git
cd azure-functions-go-worker

# Hello World - basic HTTP function
cd samples/hello-world/src
go build -o handler .
func start

# QR Generator - web UI + API
cd samples/qr-generator
go build -o handler .
func start

The code is on GitHub.

Contents:

• Why This Exists
• How It Works
• Two Flavors
• Getting Started
• Authentication
• Tuning the Listener
• Under the Hood
• Local Development
• Source Code

Why This Exists

Real-world systems span services and clouds — data doesn’t always live where your compute does. You might have:

• Legacy systems that push to SQS
• Third-party integrations that only support AWS
• Partner data landing in SQS queues
• Teams using different cloud providers

Whatever the reason, if your compute is on Azure Functions and your messages are in SQS, you need a way to connect them.

How It Works

The extension polls SQS using long polling (20-second wait), receives messages, and triggers your function. If your function succeeds, the message is deleted. If it fails, the message becomes visible again after the visibility timeout — built-in retry for free.

Two Flavors

Azure Functions has two hosting models, and this extension supports both:

New projects should use the isolated worker model. It runs in a separate process, supports any .NET version, and is the future of Azure Functions.

Getting Started

Isolated Worker (Recommended)

See a complete example in the sample project.

Add the NuGet package:

dotnet add package Extensions.Azure.Functions.Worker.SQS

Register the extension in Program.cs:

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults(worker =>
    {
        worker.UseSqs();
    })
    .Build();

host.Run();

Write a function:

public class SqsFunction
{
    private readonly ILogger<SqsFunction> _logger;

    public SqsFunction(ILogger<SqsFunction> logger)
    {
        _logger = logger;
    }

    [Function("ProcessMessage")]
    public void Run([SqsTrigger("%SQS_QUEUE_URL%")] Message message)
    {
        _logger.LogInformation("Received: {MessageId}", message.MessageId);
        _logger.LogInformation("Body: {Body}", message.Body);

        // Process the message...
        // If this method completes without exception, the message is deleted
    }
}

In-Process Model

See a complete example in the sample project.

Add the NuGet package:

dotnet add package Extensions.Azure.WebJobs.SQS

The extension auto-registers via WebJobs startup. Just write your function:

public class SqsFunction
{
    [FunctionName("ProcessMessage")]
    public void Run(
        [SqsQueueTrigger(QueueUrl = "%SQS_QUEUE_URL%")] Message message,
        ILogger log)
    {
        log.LogInformation("Received: {Body}", message.Body);
    }
}

Sending Messages

For the in-process model, there’s an output binding:

[FunctionName("SendMessage")]
public async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req,
    [SqsQueueOut(QueueUrl = "%SQS_QUEUE_URL%")] IAsyncCollector<SqsQueueMessage> messages)
{
    await messages.AddAsync(new SqsQueueMessage
    {
        Body = "Hello from Azure Functions!",
        MessageAttributes = new Dictionary<string, MessageAttributeValue>
        {
            ["Source"] = new MessageAttributeValue
            {
                DataType = "String",
                StringValue = "AzureFunctions"
            }
        }
    });

    return new OkObjectResult("Message sent");
}

For isolated worker, use the output binding on the return type:

[Function("SendMessage")]
[SqsOutput("%SQS_QUEUE_URL%")]
public string Run([HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req)
{
    return "Hello from Azure Functions!";
}

For more control (batch sends, message attributes, delays), use the AWS SDK directly:

[Function("SendMessageWithAttributes")]
public async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req,
    [FromServices] IAmazonSQS sqsClient)
{
    await sqsClient.SendMessageAsync(new SendMessageRequest
    {
        QueueUrl = Environment.GetEnvironmentVariable("SQS_QUEUE_URL"),
        MessageBody = "Hello!",
        DelaySeconds = 5,
        MessageAttributes = new Dictionary<string, MessageAttributeValue>
        {
            ["Source"] = new MessageAttributeValue
            {
                DataType = "String",
                StringValue = "AzureFunctions"
            }
        }
    });

    return new OkResult();
}

Configuration

Set your queue URL in local.settings.json:

{
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "SQS_QUEUE_URL": "https://sqs.us-east-1.amazonaws.com/123456789/my-queue"
  }
}

Authentication

The extension uses the AWS SDK credential chain. If you don’t provide explicit credentials, the SDK looks for them in this order:

1. Environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
2. Shared credentials file (~/.aws/credentials)
3. IAM role for EC2/ECS/EKS

Local Development

For local development, set environment variables in local.settings.json:

{
  "Values": {
    "AWS_ACCESS_KEY_ID": "your-access-key",
    "AWS_SECRET_ACCESS_KEY": "your-secret-key",
    "AWS_REGION": "us-east-1"
  }
}

Or use the AWS CLI to configure a profile:

aws configure

The SDK will pick up credentials from ~/.aws/credentials automatically.

Workload Identity Federation (Recommended for Production)

The best approach for Azure-hosted functions is OIDC federation between Azure AD and AWS. No stored credentials — your function uses its Azure Managed Identity to assume an AWS IAM role.

1. Create an OIDC Identity Provider in AWS IAM that trusts Azure AD
2. Create an IAM role with a trust policy for your Azure Function’s managed identity
3. Use AssumeRoleWithWebIdentity to get temporary AWS credentials

This eliminates credential management entirely. See AWS docs for setup details.

Azure Key Vault (Alternative)

If federation isn’t an option, store your AWS credentials in Azure Key Vault and reference them in app settings:

AWS_ACCESS_KEY_ID=@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/aws-key-id/)
AWS_SECRET_ACCESS_KEY=@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/aws-secret-key/)

This keeps secrets out of your code, though you’ll need to manage rotation.

IAM Roles (Self-Hosted on AWS)

If you’re self-hosting Azure Functions on AWS infrastructure (EC2, ECS, EKS), you can use IAM roles instead of managing credentials.

EC2: Attach an IAM role with sqs:ReceiveMessage, sqs:DeleteMessage, and sqs:GetQueueAttributes permissions.

ECS/Fargate: Use a task IAM role.

EKS/Kubernetes: Use IAM Roles for Service Accounts (IRSA).

Example IAM policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:GetQueueAttributes"
      ],
      "Resource": "arn:aws:sqs:us-east-1:123456789012:my-queue"
    }
  ]
}

Tuning the Listener

Configure polling behavior in host.json:

{
  "version": "2.0",
  "extensions": {
    "sqsQueue": {
      "maxNumberOfMessages": 10,
      "pollingInterval": "00:00:05",
      "visibilityTimeout": "00:00:30"
    }
  }
}

Under the Hood

The listener uses a sequential polling loop rather than a timer:

┌─────────────────────────────────────────────────────────────────┐
│                         Polling Loop                            │
└─────────────────────────────────────────────────────────────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │  ReceiveMessage     │
                    │  (long poll, 20s)   │
                    └─────────────────────┘
                               │
              ┌────────────────┴────────────────┐
              │                                 │
              ▼                                 ▼
     ┌─────────────────┐              ┌─────────────────┐
     │  Messages?  Yes │              │  Messages?  No  │
     └─────────────────┘              └─────────────────┘
              │                                 │
              ▼                                 ▼
     ┌─────────────────┐              ┌─────────────────┐
     │ Execute Function│              │ Wait interval   │
     └─────────────────┘              │ (5s default)    │
              │                       └─────────────────┘
              │                                 │
      ┌───────┴───────┐                        │
      │               │                        │
      ▼               ▼                        │
┌──────────┐   ┌──────────┐                    │
│ Success  │   │ Failure  │                    │
└──────────┘   └──────────┘                    │
      │               │                        │
      ▼               ▼                        │
┌──────────┐   ┌──────────────┐                │
│ Delete   │   │ Leave in     │                │
│ message  │   │ queue (retry)│                │
└──────────┘   └──────────────┘                │
      │               │                        │
      └───────┬───────┘                        │
              │                                │
              └────────────────┬───────────────┘
                               │
                               ▼
                         (repeat loop)

while (_isRunning && !cancellationToken.IsCancellationRequested)
{
    var messagesReceived = await PollAndProcessAsync(cancellationToken);

    if (messagesReceived == 0)
        await Task.Delay(_options.PollingInterval, cancellationToken);
}

This avoids overlapping polls that can happen with timer-based approaches. The full implementation is in SqsQueueTriggerListener.cs.

Long polling (20-second wait time) reduces API calls significantly — instead of hitting SQS every second, the SDK waits for messages to arrive or the timeout to expire.

Local Development

The extension works with LocalStack for local development without real AWS credentials. Setup scripts are in the repo:

# Unix/Mac
./dotnet/localstack/unix/setup-localstack.sh

# Windows (PowerShell)
.\dotnet\localstack\windows\setup-localstack.ps1

This starts LocalStack and creates test queues. Configure your local.settings.json:

{
  "Values": {
    "AWS_ACCESS_KEY_ID": "test",
    "AWS_SECRET_ACCESS_KEY": "test",
    "AWS_REGION": "us-east-1",
    "AWS_ENDPOINT_URL": "http://localhost:4566",
    "AWS:ServiceURL": "http://localhost:4566",
    "SQS_QUEUE_URL": "http://localhost:4566/000000000000/test-queue"
  }
}

The AWS:ServiceURL setting is needed for the in-process model to connect to LocalStack. See the LocalStack guide in the repo for detailed setup instructions.

Source Code

The extension is open source on GitHub. Key files:

• In-process extension
• Isolated worker extension
• Sample functions

Contributions welcome.

Here’s how the server works and some design decisions along the way.

Contents:

• The Architecture
• Tool Registration
• Authentication Without SDKs
• Calling Azure Resource Manager
• Handling Both SKUs
• What Can You Do With It?
• Try It

The Architecture

Here’s the entry point:

const server = new Server(
  { name: "logicapps-mcp", version: "0.1.0" },
  { capabilities: { tools: {} } }
);

registerTools(server);

const transport = new StdioServerTransport();
await server.connect(transport);

MCP uses stdio for communication — the AI assistant spawns the server process and communicates via stdin/stdout. No HTTP server, no ports to configure.

Tool Registration

Each tool is defined with a JSON schema that describes its parameters:

{
  name: "list_run_history",
  description: "Get the run history for a workflow",
  inputSchema: {
    type: "object",
    properties: {
      subscriptionId: { type: "string" },
      logicAppName: { type: "string" },
      top: { type: "number", description: "Number of runs (default: 25)" },
      filter: { type: "string", description: "OData filter" }
    },
    required: ["subscriptionId", "logicAppName"]
  }
}

The AI reads these schemas and knows exactly what parameters to provide. When it calls a tool, the server validates the input and executes the corresponding function.

Authentication Without SDKs

Rather than pulling in the Azure SDK (which adds significant weight), the server uses Azure CLI tokens directly:

export async function getAzureCliToken(): Promise<string> {
  const result = await exec("az account get-access-token --query accessToken -o tsv");
  return result.stdout.trim();
}

This keeps dependencies minimal and leverages the authentication the user already has. If you’re logged into Azure CLI, the MCP server just works.

Calling Azure Resource Manager

All Logic Apps operations go through the ARM REST API. The HTTP client is a thin wrapper that handles auth injection and pagination:

export async function armRequest<T>(path: string): Promise<T> {
  const cloud = getCloudEndpoints();
  const token = await getAccessToken();

  const response = await fetch(`${cloud.resourceManager}${path}`, {
    headers: {
      Authorization: `Bearer ${token}`,
      "Content-Type": "application/json"
    }
  });

  return response.json() as T;
}

The server supports Azure Public, Government, and China clouds — just swap the endpoint configuration.

Handling Both SKUs

Logic Apps comes in two flavors: Consumption (serverless, single workflow) and Standard (App Service-based, multiple workflows). The API paths differ:

• Consumption: /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Logic/workflows/{name}
• Standard: /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/sites/{name}/hostruntime/runtime/webhooks/workflow/api/management/workflows/{workflow}

Each tool detects the SKU and routes to the appropriate API.

What Can You Do With It?

Once configured, you can ask your AI assistant things like:

• “List all Logic Apps in my subscription”
• “Show me failed runs from the last 24 hours”
• “What’s the definition of the order-processing workflow?”
• “Get the trigger callback URL for the HTTP trigger”

The server exposes 18 read-only tools:

Try It

To get started:

npm install -g github:laveeshb/logicapps-mcp

Add it to Claude Desktop or VS Code Copilot, and you can start querying your Logic Apps with natural language.

The code is on GitHub — contributions welcome.

Here’s what’s new.

Contents:

• Search Runs Without OData
• Get Actual Action Inputs and Outputs
• Test Connections
• Get Connection Details
• Access Workflow Versions
• Updated Tool Summary

Search Runs Without OData

The original list_run_history tool supported OData filters, but constructing the right filter string takes effort. The new search_runs tool exposes friendly parameters:

{
  name: "search_runs",
  description:
    "Search run history with friendly parameters instead of raw OData filter syntax.",
  inputSchema: {
    type: "object",
    properties: {
      status: {
        type: "string",
        enum: ["Succeeded", "Failed", "Cancelled", "Running"],
        description: "Filter by run status",
      },
      startTime: {
        type: "string",
        description: "Filter runs starting after this ISO timestamp",
      },
      endTime: {
        type: "string",
        description: "Filter runs starting before this ISO timestamp",
      },
      clientTrackingId: {
        type: "string",
        description: "Filter by correlation/tracking ID",
      },
    },
  },
}

Now you can ask: “Find all failed runs from the last hour” and the AI doesn’t need to construct $filter=status eq 'Failed' and startTime ge '2025-12-24T10:00:00Z'.

Under the hood, it builds the OData filter for you:

const filterParts: string[] = [];

if (status) {
  filterParts.push(`status eq '${status}'`);
}
if (startTime) {
  filterParts.push(`startTime ge ${startTime}`);
}
if (endTime) {
  filterParts.push(`startTime le ${endTime}`);
}

const filter = filterParts.length > 0 ? filterParts.join(" and ") : undefined;

Get Actual Action Inputs and Outputs

The existing get_run_actions tool returns action metadata, but the actual inputs and outputs are behind separate URLs (inputsLink, outputsLink). The new get_action_io tool follows those links:

{
  name: "get_action_io",
  description:
    "Get the actual input/output content for a run action. Fetches the content from inputsLink/outputsLink URLs. Essential for debugging data issues.",
  inputSchema: {
    type: "object",
    properties: {
      type: {
        type: "string",
        enum: ["inputs", "outputs", "both"],
        description: "Which content to fetch (default: both)",
      },
      // ... standard params: subscriptionId, resourceGroupName, etc.
    },
  },
}

The implementation fetches the action metadata, then follows the content links:

// Fetch inputs if requested
if ((type === "inputs" || type === "both") && action.properties.inputsLink?.uri) {
  result.inputs = await fetchContentLink(action.properties.inputsLink.uri);
}

// Fetch outputs if requested
if ((type === "outputs" || type === "both") && action.properties.outputsLink?.uri) {
  result.outputs = await fetchContentLink(action.properties.outputsLink.uri);
}

The content link URLs include SAS tokens, so no additional auth is needed. This is essential for debugging — when a workflow fails, you want to see what data was actually passed to each action, not just that the action ran.

Test Connections

Logic Apps use API connections for external services (SQL, SharePoint, etc.). When things break, the first question is often: “Is the connection still valid?”

{
  name: "test_connection",
  description:
    "Test if an API connection is valid and healthy. Checks connection status and attempts to validate using test links if available.",
  inputSchema: {
    type: "object",
    properties: {
      subscriptionId: { type: "string" },
      resourceGroupName: { type: "string" },
      connectionName: { type: "string" },
    },
    required: ["subscriptionId", "resourceGroupName", "connectionName"],
  },
}

The tool checks the connection status and, if test links are available, actually calls them:

// If status is Connected, it's valid
if (details.status === "Connected") {
  result.isValid = true;
  return result;
}

// If there are test links, try to use them
if (details.testLinks && details.testLinks.length > 0) {
  const testLink = details.testLinks[0];
  const response = await fetch(url, {
    method: testLink.method,
    headers: { Authorization: `Bearer ${token}` },
  });

  if (response.ok) {
    result.isValid = true;
    result.status = "Connected";
  }
}

Quick way to rule out (or confirm) connection issues.

Get Connection Details

Beyond testing, sometimes you need to inspect a connection’s configuration:

{
  name: "get_connection_details",
  description:
    "Get detailed information about a specific API connection including status, configuration, and test links.",
  inputSchema: {
    type: "object",
    properties: {
      subscriptionId: { type: "string" },
      resourceGroupName: { type: "string" },
      connectionName: { type: "string" },
    },
    required: ["subscriptionId", "resourceGroupName", "connectionName"],
  },
}

Returns the full connection metadata including API type, status, creation time, parameter values, and test links.

Access Workflow Versions

Logic Apps (Consumption SKU) keeps a version history. The new get_workflow_version tool retrieves a specific version’s definition:

{
  name: "get_workflow_version",
  description:
    "Get a specific historical version's definition. Only available for Consumption Logic Apps. Use list_workflow_versions to see available versions.",
  inputSchema: {
    type: "object",
    properties: {
      subscriptionId: { type: "string" },
      resourceGroupName: { type: "string" },
      logicAppName: { type: "string" },
      versionId: { type: "string", description: "Version ID (from list_workflow_versions)" },
    },
    required: ["subscriptionId", "resourceGroupName", "logicAppName", "versionId"],
  },
}

Useful when you need to compare what changed between versions, or understand what the workflow looked like at a specific point in time.

Updated Tool Summary

The server now has 23 tools:

The focus for this release was debugging workflows. With these tools, an AI assistant can now help you:

• Search for problematic runs without writing OData
• Inspect what data actually flowed through each action
• Verify connections are healthy
• Compare workflow versions to spot changes

If you’re already using the server, update with npm update -g logicapps-mcp. If not, check out the repo to get started.

What to Expect

I plan to write about:

• Distributed Systems — Lessons learned from building systems at scale
• Azure & Cloud Architecture — Patterns, anti-patterns, and war stories
• AI Infrastructure — How AI is changing the way we build software
• Open Source — Projects I’m working on and contributions to the community

Why Now?

After spending years building cloud infrastructure, I figured it might be worth writing down some of the things I’ve learned along the way. Writing helps me think more clearly, and maybe some of these posts will help someone else avoid the same mistakes I’ve made.

Stay Tuned

I’ll try to post regularly. No promises on frequency, but I’ll aim for quality over quantity.

Thanks for reading!