The Gateway Pattern

The Gateway Pattern is the optimal architecture for implementing MCP in Azure Functions. Rather than mapping every tool to a distinct function endpoint, a single McpGateway function serves as a protocol adapter. This function exposes all your API endpoints through a unified entry point.

Request Flow

The interaction follows a structured flow where the client sends a JSON-RPC request to the /api/mcp endpoint. The gateway then validates this request, identifies the user context, and parses the specific method requested. Next, the execution engine uses reflection and dependency injection to find and run the necessary tool. Finally, the system packages the result into a JSON-RPC response and sends it back to the client.

The JSON-RPC Router

MCP operations utilize JSON-RPC 2.0 (a stateless protocol). The gateway must process three core method types: initialize, tools/list, and tools/call.

1. The Initialize Handshake

Before calling any tools, the client “handshakes” with your server to understand its capabilities. This code below defines an Azure Function named McpGateway that acts as an HTTP endpoint for handling JSON-RPC requests. It begins by asynchronously reading the incoming request body and parsing it into a JSON object to extract the method and id fields.

The logic specifically checks if the client is calling the initialize method, which is the standard handshake for the Model Context Protocol (MCP). If it matches, the function returns a successful response containing the protocol version, the server’s capabilities (specifically tool listing), and metadata about the server. This confirms the connection between the client and the server.  

[Function("McpGateway")]
public async Task<HttpResponseData> Run([HttpTrigger(AuthorizationLevel.Anonymous, "post")] HttpRequestData req)
{
    var requestBody = await req.ReadAsStringAsync();
    var jsonRequest = JsonConvert.DeserializeObject<JObject>(requestBody);
    var method = jsonRequest["method"]?.ToString();
    var id = jsonRequest["id"];

    if (method == "initialize") {
        return await CreateJsonRpcResponse(req, id, new {
            protocolVersion = "2025-11-25",
            capabilities = new { tools = new { listChanged = true } },
            serverInfo = new { name = "EnterpriseMcpServer", version = "1.0.0" }
        });
    }
}

Example Input:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {}
  }
}

Example Output:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-11-25",
    "capabilities": { "tools": { "listChanged": true } },
    "serverInfo": { "name": "McpServer", "version": "1.0.0" }
  }
}

2. Dynamic Tool Discovery (tools/list)

Dynamic tool discovery lets your server automatically find and expose available tools without hard-coding them. Instead of maintaining a manual list, you simply mark the methods you want to expose, and the system discovers them at runtime.

You do this using attributes (decorators) to clearly define which classes and methods act as tools:

[AttributeUsage(AttributeTargets.Class)]
public class McpToolProviderAttribute : Attribute { }

[AttributeUsage(AttributeTargets.Method)]
public class McpToolAttribute : Attribute { 
    public string Name { get; set; }
    public string Description { get; set; }
}

The server then uses reflection to scan for these attributes and build a tool list dynamically:

var toolList = Assembly.GetExecutingAssembly()
    .GetTypes()
    .Where(t => t.GetCustomAttribute<McpToolProviderAttribute>() != null)
    .SelectMany(t => t.GetMethods())
    .Where(m => m.GetCustomAttribute<McpToolAttribute>() != null)
    .Select(m => new {
        name = m.GetCustomAttribute<McpToolAttribute>().Name,
        description = m.GetCustomAttribute<McpToolAttribute>().Description,
        inputSchema = new {
            type = "object",
            properties = m.GetParameters().ToDictionary(
                p => p.Name, 
                p => new { type = GetJsonType(p.ParameterType), description = GetDescription(p) }
            ),
            required = m.GetParameters().Where(p => !p.IsOptional).Select(p => p.Name)
        }
    });

Tool Definition Example:

[McpToolProvider]
public class SharePointTools {
    [McpTool(Name = "search_documents", Description = "Search for files in a document library")]
    public string SearchDocs(string query, int limit = 5) => $"Results for {query}";
}

If you define multiple tools (for example, 5 methods with [McpTool]), the server will automatically return all 5 in the response:

Output to LLM:

{
  "tools": [
    { "name": "search_documents" },
    { "name": "get_document" },
    { "name": "create_document" },
    { "name": "update_document" },
    { "name": "delete_document" }
  ]
}

3. The Execution (tools/call)

The final component is the execution engine. Once the AI knows what tools exist, it needs a way to trigger them. The tools/call method maps incoming JSON arguments to C# types and invokes the corresponding method using Dependency Injection (DI). This allows your tools can access databases, logging, or other enterprise services safely.

private async Task<string> InvokeToolAsync(string toolName, JObject arguments)
{
    // Locate the tool metadata in the registry
    var toolInfo = _toolRegistry[toolName];
    
    // Resolve the class instance via DI (Dependency Injection)
    var toolInstance = _serviceProvider.GetRequiredService(toolInfo.Type);
    var method = toolInfo.Method;
    
    // Prepare the arguments for the C# method
    var parameters = method.GetParameters();
    object[] methodArgs = new object[parameters.Length];

    for (int i = 0; i < parameters.Length; i++) {
        var p = parameters[i];
        if (arguments.TryGetValue(p.Name, out var token)) {
            // Convert JSON types to C# types
            methodArgs[i] = token.ToObject(p.ParameterType);
        } else if (p.IsOptional) {
            methodArgs[i] = p.DefaultValue;
        }
    }

    // Execute the logic and handle Async/Sync results
    var result = method.Invoke(toolInstance, methodArgs);
    return result is Task<string> t ? await t : result?.ToString();
}

This execution engine is the bridge between the AI and your application logic. It finds the correct tool, prepares the inputs, runs the method, and returns the result. Everything in a structured way.

Example Input (tools/call): Sends the function name along with the necessary arguments.

{
  "method": "tools/call",
  "params": {
    "name": "Get_record",
    "arguments": {
      "recordId": "REC-99",
      "status": "InProgress"
    }
  }
}

Example Output: The server executes the C# method and wraps the return value into a standardized MCP response format for the AI to process.

{
  "jsonrpc": "2.0",
  "id": "call-456",
  "result": {
    "content": [
      {
        "type": "text",
        "text": "{ recordId: 12, description: \"...\" }"
      }
    ]
  }
}

Best Practices

• Extract JWT tokens from the Authorization header to expose and connect to the server.
• Implement all tools as Task<string>. This aligns with the asynchronous nature of Azure Functions and external Graph API calls.

Conclusion

It can feel time consuming and a bit tedious to set everything up, but once it’s in place, MCP delivers real value. In my opinion, building an MCP server with the gateway pattern isn’t about adding complexity, it’s about creating a clean, secure, and scalable bridge between LLMs and your enterprise systems. With a platform like Azure Functions, this approach improves reliability and security while making it much easier to grow and adapt your capabilities as LLM-powered applications evolve.

What’s Happening?

After August 29, 2025, three major things happen:

• Existing PowerApps cards in Teams will stop working.
• You can’t create new ones.
• Any flows or automations that rely on them will break.

Microsoft is moving everything to Adaptive Cards, which are now seen as the standard format across Teams, Outlook, and your favorite Copilot.

What is Adaptive Cards ?

If you’re not familiar, Adaptive Cards are basically rich, interactive UI snippets described in JSON. You can use them to collect inputs, display dynamic information, trigger actions, or even handle approvals. For example, a help desk ticket card can display fields such as “Title” and “Description,” along with a submit button, allowing users to send this information directly to Power Automate without leaving Teams or Outlook.

Few advantages that I can think for Adaptive cards…

• Adapt to the app they’re in (Teams, Outlook, Windows, etc.).
• Support text, images, buttons, and input fields.
• Look native in light/dark mode.
• Work in multiple places without rebuilding.

In short, it’s piece of a card with one design, but can work on many platforms.

Which option should you select?

Below are three recommendations you can choose from based on your goals.

1. Adaptive cards in Teams - You can deliver these without coding using Power Automate. Create the card in JSON, post it to a chat or channel, and collect responses directly in Teams. Perfect for quick updates, collecting feedback, or handling approvals. Bots can also send these cards for more dynamic scenarios.

2. Adaptive cards in Copilot Studio - If you’re building in Copilot Studio, you can present Adaptive Cards right in a conversation. For example, when a user says “Log a help desk ticket”, Copilot can show a card asking for details, then trigger your automation once submitted — all inside the chat.

3. Outlook Actionable Messages - These are Adaptive Cards embedded in Outlook emails. The recipient can approve, reject, or submit information without leaving their inbox.

My View

Accept it and move on! You don’t have to stop using Power Apps. But make sure instead of putting the card inside Power Apps, you switch it in Teams, Outlook, or Copilot, then send the responses back to your Power Apps app or Dataverse tables. This way, your backend stays the same, but the front-end experience becomes more modern and works across more places.

I know it’s a tedious task and will take some effort now, but once you’ve moved to Adaptive Cards, your solutions will look cleaner, and with Microsoft backing it you can trust it’s here to stay. You know what I mean! 😉

Useful Resources

• Power Apps cards overview
• Adaptive cards in Power Automate
• “Ask with Adaptive Card” in Microsoft Copilot Studio
• Actionable messages in Outlook

I truly hate restarting my machine. The pain is, all your apps and windows disappear, and it takes forever to get everything back the way it was.

That’s where PowerToys Workspaces is a helpful tool. It’s a desktop manager that lets you save your current desktop setup (all apps and window positions), and later launch everything back in place with just one click.

Here’s the simple guide that you can follow and use the tool:

Install PowerToys and Enable WorkSpaces

Download and install PowerToys from the official link:

https://learn.microsoft.com/en-us/windows/powertoys/install

Open, and turn on Workspaces toggle if it’s turned off.

You can open the editor using by selecting “Launch editor” from PowerToys Workspaces settings or by using the shortcut Win+Ctrl+ `

Open Your Desired Setup

Now open all the apps and windows you want to save. I have 3 screens with VS Code, browser tabs, Outlook, Teams, and more.

Once everything is ready, click on “Create workspace”

Capture the Workspace

Click the “Capture” button and PowerToys will take a snapshot of your current layout.

You’ll see an editor where you can:

• Give your workspace a name
• Remove windows you don’t want to include
• Create a desktop shortcut

After editing, click on “Save workspace”

Open Workspace

And that’s it. Your saved workspace will now appear in the PowerToys dashboard.

Even after restarting machine, you can launch it anytime and all your apps will reopen exactly where you had them before.

Try it out! Create a workspace and let me know how it goes for you.

Powertoys utilities:

If you are curious about other utilities that tool offer, check out below list.

If I had to pick from this list, I would start with Color Picker, Text Extractor, and ZoomIt (which is underrated)

If you’re already using PowerToys or planning to start using it now, let me know your favorite utility in the comment box below.

In this blog, I’ll show you how to use the Send HTTPS Request feature effectively. We’ll create a simple agent that fetches random quotes from the Breaking Bad API (I just love using this API to show examples). The API response will return a quote along with the author’s name (character name) from the series.

Follow the steps below.

Step 1: Create a New Agent

Go to Copilot Studio and click on the New agent button. For this example, we’ll create the agent from scratch, without any use of AI.

Click Create.

Step 2: Add a Topic

You’re inside your brand-new agent! Let’s add a new topic. This is where we’ll place our HTTP request logic.

Topics are like conversation flows. They define how your agent responds in different scenarios.

Create a manual topic (From blank) for this demo.

By default, you’ll see some system generated and custom topics.

Step 3: Add Trigger Phrases

Now, you’ll see a trigger created. This is where you define phrases or description that will start the topic.

Enter the following two phrases:

• Give me a breaking bad quote

• New quote

Step 4: Send an HTTPS Request

Click the + icon, choose Advanced, and then select Send an HTTPS Request.

We’re going to call an open-source API to get quotes from Breaking Bad.

Enter this URL: https://api.breakingbadquotes.xyz/v1/quotes

Set the method to GET.

Also:

• Set the response type to any

• Create a variable (I called mine Quote) to store the response

This API returns a quote and author, we’ll grab and display only quote.

Step 5: Send the Quote to the User

Let’s show the result to the user. Add a Send a message node.

In the message box, use the following Power Fx formula to get the quote text:

First(Topic.Quote).quote

This pulls the first item from the response and shows the quote.

Final Step: Name, Save & Test

Give your topic a name like Get Quote, then click Save. Your topic flow should look something like this:

Now, click Test, type “Give me a breaking bad quote”, and your agent will fetch a quote from the API and show it!

We just used the GET method here, but Copilot Studio also supports POST, PUT, and DELETE.

Share your thoughts below!

Happy building!🐱

As I mentioned earlier, it’s not practical to rely on the ShareGate user interface for each site. That’s where I recommend a better approach -> using PnP PowerShell module.

PnP PowerShell Script:

No big deal! Here’s the scenario I mentioned earlier: you want to run a script that checks each item’s Status (a choice column in your SharePoint list), and if it’s set to “Pending”, the script should update it to “Approved”.

Tip: By default, ShareGate uses PowerShell v5.0, but PnP requires PowerShell v7 to run any scripts. So, if you want to run the PnP module from the same shell, use the pwsh command to launch the script.

As of now, this kind of conditional check from source and update it to destination isn’t possible using ShareGate alone.

Don’t know your client ID?, As of September 9th, 2024, this has become mandatory step. This article will guide you through how to do so.

This was just a simple use case. Yours might be more advanced. All the best tackling it!

Feel free to drop your thoughts or questions in the comments section below, I’d love to help if you’re trying something similar.

Thanks again for reading. I hope you’re finding these posts helpful.

At first, I thought, “Wait, what?” Because what they were asking for just isn’t something ShareGate supports out of the box—neither through the UI nor the ShareGate PowerShell module. But after a bit of head-scratching (and lots of coffee ☕), I came up with a workaround to get the job done.

Before I get into the how, let’s back up a bit.

What Is Conditional Mapping?

If you’ve ever used ShareGate, you’ve probably worked with mapping configurations—where you can map metadata from the source to the destination. But what’s different about conditional mapping?

Conditional mapping means applying logic to the mapping process. In other words, you want to compare the value from a source column and based on a certain condition, modify it before it gets migrated to the destination.

Example: Imagine you’re migrating a list where the Status column sometimes contains the value "Pending". During migration, you want to check for that and replace it with "Approved" only when that condition is met. That’s conditional mapping.

Sounds simple enough, right?

But Can ShareGate Do That?

If you go into ShareGate’s UI and try to modify metadata mappings, here are the options you’ll find:

• Set mapped value

• Set a custom value

• Ask Value (Manual mode only)

• Set mapped value or default

• Ignore

Nowhere in that list do you see an option like “If Title contains X, replace with Y.” So no, ShareGate doesn’t support conditional logic in metadata mappings.

What About Modifying the .sgt Template?

“Can I edit the ShareGate migration template (.sgt) file with PowerShell and add some conditions there?”

Good question. I tried that too—and unfortunately, it didn’t work. If you try to forcefully apply a modified template with custom conditions, ShareGate throws a template read error. So that door’s closed as well.

What’s the Workaround?

There are two practical ways to achieve conditional mapping:

Option 1: Export & Modify Metadata

• Export the source list metadata to an Excel file (screenshot below).

• Manually update the data in Excel to reflect your desired changes.

• Use Import & Copy in ShareGate to push that modified data to the destination.

This works fine if you’re only dealing with a few sites or lists. It gives you full control over the values that will be written. But let’s be honest, are you really going to do that for dozens of sites? Probably not. It’s time-consuming and error-prone at scale.

Option 2: Use PnP PowerShell After Migration

This is the smarter, scalable approach.

Migrate the content as-is using ShareGate. Then, use the PnP.PowerShell module to run a script that goes through the migrated items and applies your conditional logic.

For example, you can run a script that checks each item’s Status column, and if it contains “Pending”, it updates it to “Approved”. Simple, powerful, and works across sites.

Coming Up Next…

In my next blog post, I’ll walk you through how to write a PnP PowerShell script—and how to execute it directly from the ShareGate migration PowerShell terminal.

So if you’ve ever faced this limitation and wanted a way around it, stay tuned!

Declarative agents in Microsoft 365 Copilot are a type of AI assistant that helps businesses automate tasks and workflows by following predefined instructions and using enterprise data. They work within tools like Teams, Word, and PowerPoint to boost productivity. For example, a customer service agent can provide real-time order updates using an API plugin, to improve support quality. 

Today, we will create a custom declarative agent using an open-source API to demonstrate how agents can interact with external data sources.

Open Source API Overview:

We’ll be using the Breaking Bad API, an open-source API that provides quotes from the popular TV series Breaking Bad. The API response will return a quote along with the author’s name (character name) from the series.

👇Sample Response from API 👇

Let’s get started!

Step 1: Creating a Custom Declarative Agent Using Microsoft Toolkit Extension

Let’s begin by creating a custom declarative agent using the Microsoft Toolkit extension. Follow these step-by-step instructions to set up your agent: 

1. Launch the Microsoft Toolkit Extension and click on Create a New App under Create a Project or Explore Samples
2. Choose Agent as your app type
3. Select Declarative Agent to build an agent powered by Microsoft 365 Copilot
4. Click Add Plugin to connect external APIs to your agent
5. Choose Start with a New API to set up a fresh connection for your agent
6. Pick None for authentication since the Breaking Bad API doesn’t require it
7. Opt for TypeScript as programming language for a smoother experience
8. Select a folder to store project files (pro tip: avoid saving it in the C drive for better organization)
9. Finally, give your agent a name like BreakingBad Agent and hit the setup button

Wohooo! 🎉 You’ve Successfully Created Your Declarative Agent with an API Plugin! After completing the setup, a new window will pop up in VS Code with your project structure ready. But wait—there’s more! 

By default, the project folder includes a demo API plugin. However, this plugin uses a local json file as its data source. Since we want to fetch real-time data from an actual API, we will need to remove the existing demo setup.

Clean Up the Default Files

Now that your declarative agent is set up, it’s time to remove the default files that use local data. Since we will be working with a live API instead, delete the following files from your project directory: 

• appPackage > apiSpecificationfile > repair.yml 

• appPackage > repairDeclarativeAgent.json 

• src > RepairsData.json 

• src > functions > repairs.ts

Don’t worry about the files we just deleted. We’re going to create the essential files needed for our Breaking Bad Agent from scratch. Up next, we’ll fetch real-time data directly from the API and configure the agent to use it.

Step 2: Create a New Function File for the Breaking Bad API Integration

Next, we need to create a new file where our agent will interact with the Breaking Bad API. 

1. Navigate to: src > functions
2. Create a New File: Name it quotes.ts

Now, copy and paste the following code into quotes.ts. This function will act as an Azure Function responsible for sending requests and receiving quotes from the live Breaking Bad API.

import { app, HttpResponseInit } from "@azure/functions"; 

export async function quotes(): Promise<HttpResponseInit> { 

  const breakingbadResponse = await fetch('https://api.breakingbadquotes.xyz/v1/quotes'); 

  const breakingbadData = await breakingbadResponse.json(); 

  return { 

    status: 200, 

    jsonBody: { 

      quotes: breakingbadData, 

  }, 

  }; 

} 

app.http("quotes", { 

  methods: ["GET"], 

  authLevel: "anonymous", 

  handler: quotes, 

});

If you encounter the error Cannot find module '@azure/functions' or its corresponding type, don’t worry! This is a common issue, and the required modules will be automatically installed when you run the agent for the first time.

Step 3: Create the API Specification File

Now, let’s create the API specification file that will define how the declarative agent interacts with the Breaking Bad API.

1. Navigate to: appPackage > apiSpecificationfile
2. Create a New File: Name it quotes.yml

openapi: 3.0.0 

info: 

  title: Breaking bad Quote API 

  description: Random Quote api from the Breaking Bad TV series with author 

  version: 1.0.0 

servers: 

  - url: ${{OPENAPI_SERVER_URL}}/api 

    description: The quotes api server 

paths: 

  /quotes: 

    get: 

      operationId: getQuotes 

      summary: get all breaking bad quotes with author 

      description: Returns a single random quote from the Breaking Bad TV series with author 

      responses: 

        '200': 

          description: A random quote from the Breaking Bad TV series with author 

          content: 

            application/json: 

              schema: 

                type: object 

                properties: 

                  results: 

                    type: array 

                    items: 

                      type: object 

                      properties: 

                        quote: 

                          type: string 

                          description: Breaking bad quote with author 

                        author: 

                          type: string 

                          description: The author name of the quote

Step 4: Update the ai-plugin.json File

Now, let’s update the ai-plugin.json file so that the declarative agent is properly linked with the Breaking Bad API and the Azure Function. 

1. Navigate to: appPackage. 
2. Open the File: Open ai-plugin.json
3. Remove: The "Static_template" entry
4. Update: The runtimes URL and the function name as shown below:

{ 

  "$schema": "[https://developer.microsoft.com/json-schemas/copilot/plugin/v2.2/schema.json](https://developer.microsoft.com/json-schemas/copilot/plugin/v2.2/schema.json)", 

  "schema_version": "v2.2", 

  "namespace": "Breakingbadquotes", 

  "name_for_human": "Breakingbadquotes Plugin", 

  "description_for_human": "Generate random quotes from the Breaking Bad TV series.", 

  "description_for_model": "Plugin for generating random quotes from the Breaking Bad TV series.", 

  "functions": [ 

    { 

      "name": "getQuotes", 

      "description": "Returns a random quote with author from the Breaking Bad TV series.", 

      "capabilities": { 

        "response_semantics": { 

          "data_path": "$.quotes", 

          "properties": { 

            "title": "$.quote", 

            "subtitle": "$.author" 

          }  

        } 

      }  

    }     

  ], 

  "runtimes": [ 

    { 

      "type": "OpenApi", 

      "auth": { 

        "type": "None" 

      }, 

      "spec": { 

        "url": "apiSpecificationFile/quotes.yml", 

        "progress_style": "ShowUsageWithInputAndOutput" 

      }, 

      "run_for_functions": ["getQuotes"] 

    } 

  ], 

  "capabilities": { 

    "conversation_starters": [] 

  } 

}

Step 5: Update the manifest.json File

The manifest.json file serves as the app manifest for your declarative agent. It is specifying the agent’s identity and the declarative agent configuration files. We’ll update it to reflect the Breaking Bad agent setup.

1. Navigate to: appPackage
2. Open the File: open manifest.json
3. Update: The "copilotAgents" section as shown below:

You can also update the icon of your application in the same file. First, download any image and make sure it’s 192x192 pixels. Replace the existing icon with your new image by saving it as color.png in your project folder. If you choose to change the name of the image, make sure to update it in the application manifest.json file.

{ 

  "copilotAgents": { 

    "declarativeAgents": [ 

      { 

        "id": "breakingBadDeclarativeAgent", 

        "file": "breakingBadDeclarativeAgent.json" 

      } 

    ] 

  } 

}

Step 6: Create the quotesDeclarativeAgent.json File

We need to create the agent manifest file which defines how the declarative agent behaves and interacts with the Breaking Bad API.

1. Navigate to: appPackage
2. Create a New File: Name it quotesDeclarativeAgent.json

Add the Following Content:

{ 

    "$schema": "[https://developer.microsoft.com/json-schemas/copilot/declarative-agent/v1.2/schema.json](https://developer.microsoft.com/json-schemas/copilot/declarative-agent/v1.2/schema.json)", 

    "version": "v1.2", 

    "name": "Breaking badquotes", 

    "description": "This declarative agent helps you get a random quote from the Breaking Bad TV series.", 

    "instructions": "$[file('instruction.txt')]", 

    "conversation_starters": [ 

          { 

            "text": "Give me a random quote from Breaking Bad with author name?" 

        }    

    ], 

    "actions": [ 

        { 

            "id": "quoteplugin", 

            "file": "ai-plugin.json" 

        } 

    ] 
}

Step 7: Update the instructions.txt File

The instructions.txt file plays a crucial role in declarative agent setup. It defines how the agent should behave, respond to user queries, and interact with the Breaking Bad API. This make sures that the agent stays focused on its purpose and maintains a consistent user experience.

Update it with the Following Content:

You are an assistant specialized in retrieving quotes from the provided API, ensuring a smooth and delightful user experience. Your responses should include the quote and its author. 

Guidelines: 

- Exclusive API Use: Do not perform web searches; rely solely on the provided API for data retrieval. Do not proceess any other request. This is solely for breaking bad quotes nothing else, keep in mind! 

- Response Format: Present the quote followed by the author's name.  

- Error Handling: If the API does not return a quote, respond with: "I'm sorry, I couldn't retrieve a quote at this moment." 

- User Interaction: Maintain a friendly and engaging tone to ensure a delightful user experience.

Showcase: The Final Outcome of All Efforts

To run and debug your declarative agent, click on the Run and Debug icon in VS Code, which can be found on the left sidebar. The process will take approximately ~10-15 minutes to initialize. During this time, a sign-in prompt will appear where you’ll need to log in with your Microsoft 365 account credentials.

Once signed in, if you are not automatically redirected, you can manually visit office.com/chat?auth=2 to access the Copilot interface.

Select the prompt we defined earlier, and it will prompt you to process the query. Click on Always Allow to proceed.

Final Output:

How to Verify if It’s Working and Fetching Data from the API

• Verify via Localhost: Open the terminal in VS Code and click on Start Backend. Once it’s running, you’ll see the local host URL, which should begin with localhost:7071/api/quotes. Open this URL in your browser, and it will return a JSON response with the quote data.
• Verify via Agent Request: Another way to check is by sending a request from the agent. This will invoke the getQuote function, which generates a unique ID each time. The response will include text indicating that the function was programmatically called.

Bonus: How does the breaking bad quotes agent work?

When a user requests a Breaking Bad quote in Microsoft 365 Copilot, the agent works in a few simple steps: 

1. Manifest Check: The agent starts by checking its task list in the manifest file
2. API Connection: It then refers to the API specification to understand how to connect to the Breaking Bad API
3. Data Fetch: The agent sends a request to an Azure Function, which fetches a random quote and the author’s name from the API
4. Data Return: The quote and author are returned in a structured JSON format
5. User Display: Finally, the agent displays the quote clearly in the Copilot interface

Conclusion

It’s been a bit of a ride, hasn’t it? But hey, we’ve finally done it! We have successfully created a declarative agent using the Breaking Bad API, but the process can be applied to any API, including those requiring authentication with API key or OAuth.

if you hit any bumps along the way, don’t hesitate to drop a comment below. If you found this helpful, give it a thumbs up or click on your favorite emoji button below. Good luck, and happy coding!

Appendix

This post is inspired by the following resources:

• Introducing New Agents in Microsoft 365
• Extending Copilot for Microsoft 365
• Workshop on Building Declarative Agents for Microsoft 365 Copilot
• Breaking Bad Quotes API
• Breaking Bad Icon by Icons8

Start-Job is ideal to use when …

• Tasks take a long time to complete
• You want to avoid module conflicts by isolating them in separate jobs
• You need to resolve assembly conflicts by running jobs in isolated processes

How to Use Start-Job

I will try to explain this with a simple example below.

Example : Displaying the Date and Time using Get-Date

Below example shows how to run a background job in PowerShell to get the current date and time. It uses Start-Job to begin the job, waits for it with Wait-Job, gets the result using Receive-Job, and cleans up with Remove-Job.

# Start a background job to display the current date and time

$job = Start-Job -ScriptBlock {
    Get-Date 
}

# Check if the job is complete
Write-Output "Job ID: $($job.Id) started."
Wait-Job -Job $job

# Get the result of the job
$jobResult = Receive-Job -Job $job
Write-Output "The current date and time is: $jobResult"

# Clean up
Remove-Job -Job $job

Output

It’s quite simple, isn’t it? Just make sure to use Remove-Job to clean up after your job is done. If you skip this step, it can lead to duplication or conflicts with other jobs.

Why I recommend to use Jobs?

Numerous reasons but, the major reason is that some PowerShell modules can conflict when loaded together in the same session. For example, Microsoft Graph and PnP PowerShell might have overlapping dependencies. Running these modules or assemblies in separate jobs make sures that they operate independently without issues.

Try it out and let me know how you use it in your own scripts!

The Problem

In a recent coding effort, I found myself faced with the classic choice between JavaScript’s forEach and for… loops. As I was iterating through an array of data, I realized that my code required asynchronous operations.

Async/Await in forEach: Initially, I opted for the simplicity of forEach, but soon hit a roadblock. Despite my attempts to use async/await within the loop, I encountered unexpected behaviour. The asynchronous nature of forEach proved to be a block which led to unhandled promises and unpredictable results. Here’s what I was using:

// Using forEach (causes issues with async/await)
dataArray.forEach(async (item) => {
  await processItem(item); // This won't behave as expected
});

The solution

The solution is simple. Use for loop not foreach (of course when doing asynchronous operations).

// Using for loop (structured and reliable)
for (const item of dataArray) {
  await processItem(item); // Awaits completion before moving to the next item
}

No rocket science right? Now, why did I choose for loop? 🎬 the answer is simple, I found relief in its structured approach to asynchronous iteration. With async/await, each loop iteration awaited the completion of asynchronous tasks.

Hi, I’m Nirav. I’m a Developer focused on the Microsoft 365 domain, and I work at Creospark Consulting firm located in Toronto, Canada. In addition to working on development and consultation projects, I’m an active contributor to the Microsoft 365 and Power Platform community.

I’ve been working with Microsoft technologies for around 4 years. I’ve started adopting multiple technologies throughout my career. My areas of expertise include SharePoint Framework (SPFx), React, PowerShell, Azure DevOps, PowerApps and Robotic Process Automation with Power Platform.

I hold the following certifications:

• Microsoft Certified: Power Platform Functional Consultant Associate
• Microsoft Certified: Power Platform App Maker Associate
• Microsoft Certified : Create and Manage Canvas Apps with Power Apps
• Microsoft Certified : Implement AI models with Microsoft Power Platform AI Builder
• Microsoft 365 Certified: Teams Administrator Associate
• Microsoft 365 Certified: Fundamentals
• Microsoft Certified: Azure Fundamentals
• Microsoft Certified: Azure AI Fundamentals
• Microsoft Certified : Power Platform Fundamentals
• Microsoft Certified : Create and manage automated processes by using Power Automate

For a long time, I’ve had the thought of creating a blog to share knowledge and help others. I’m building this space to discuss the problems I solve. While it’s primarily focused on the Microsoft ecosystem, I’ll also share tips and tricks that I find helpful across other areas.

Enjoy! 😺

Nirav