Dynamics 365 CRM plugins are a powerful way to enforce business logic on the server but choosing when and how to use them is just as important as writing the code itself. In one implementation for a Netherlands-based sustainability certification organization, the client needed their certification journey to begin with a custom application entity while still ensuring that applicant and company details were captured as leads for downstream sales and engagement processes. This blog explores how a server-side plugin was used to bridge that gap, reliably creating and associating lead records at runtime while keeping the solution independent of UI behavior and future integrations. In this scenario, the certification application was the starting point of the business process, but sales and engagement still needed to operate on leads. Simply storing the same information in one place wasn’t enough, the system needed a reliable way to translate an application into a lead at the right moment, every time. That transformation logic is neither data storage nor UI behavior; its core business process logic, which is why it was implemented using a Dynamics 365 plugin. Scenario: Certification Application Not Flowing into Sales Users reported the following challenge: a. A user submits or creates a Certification Applicationb. Applicant and company details are captured on a custom entityc. Sales teams expect a Lead to be created for follow-upd. No Lead exists unless created manually or through inconsistent automatione. Application and sales data become disconnected This breaks the intended business flow, as certification teams and sales teams end up working in parallel systems without a reliable link between applications and leads. Possible Solution: Handling Lead Creation Through Manual Processes (Original Approach) Before implementing the plugin, the organization attempted to manage lead creation manually or through disconnected automation. How It Worked (Initially) a. A Certification Application was submittedb. Users reviewed the applicationc. Sales team manually created a Lead with applicant/company detailsd. They tried to match accounts/contacts manuallye. Both records remained loosely connected. Why This Might Look Reasonable a. Simple to explain operationallyb. No development effortc. Works as long as users follow the steps perfectly The Hidden Problems 1] Inconsistent Data Entry a. Users forgot to create leadsb. Leads were created with missing fieldsc. Duplicate accounts/contacts were createdd. Sales lost visibility into new certification inquiries 2] Broken Cross-Department Workflow a. Certification team worked in the custom entityb. Sales team worked in Leadsc. No structural linkage existed between the twod. Downstream reporting (pipeline, conversion, source tracking) became unreliable. Workaround to This Approach: Use Server-Side Logic Instead of Manual Steps Practically, the transformation of an application into a lead is business logic, not user behavior. Once that boundary is respected, the solution becomes stable, predictable, and automation-friendly. Practical Solution: A Server-Side Plugin (Improved Approach) Instead of depending on people or scattered automation, the lead is created centrally and automatically through a plugin registered on the Certification Application entity. Why a Plugin? a. Executes consistently regardless of data sourceb. Not tied to form events or UI interactionsc. Can safely check for existing accounts/contactsd. Ensures one source of truth for lead and application linkagee. Works for portal submissions, integrations, and bulk imports This is essential for a client, where applications may originate from multiple channels and must feed accurately into the sales funnel. How the Plugin-Based Solution Works The solution was implemented using a server-side plugin registered on the Certification Application entity. The plugin executes when a new application is created, retrieves the necessary applicant and organization details, performs basic checks for existing accounts and contacts, creates a Lead using the extracted data, and finally links the Lead back to the originating application record. This ensures that every certification application automatically enters the sales pipeline in a consistent and reliable manner. Implementation Steps (For Developers New to Plugins) If you’re new to Dynamics 365 plugins, the implementation followed these core steps: Build and Register the Plugin. Once the plugin logic is implemented, build the project to generate the signed assembly. After a successful build: After registration, every new Certification Application will automatically trigger the plugin, ensuring that a Lead is created and linked without any manual intervention. a. Open the Plugin Registration Toolb. Connect to the target Dynamics 365 environmentc. Register the compiled assemblyd. Register the plugin step on the Create message of the Certification Application entitye. Configure the execution stage (typically post-operation) and execution mode (Synchronous or Asynchronous, depending on business needs) To encapsulate, this solution shows why server-side plugins are the right place for core business logic in Dynamics 365. By automatically creating and linking a Lead when a Certification Application is created, the organization removed manual steps, prevented data inconsistencies, and ensured that every application reliably flowed into the sales pipeline. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

In Part 1, we built a simple MCP server in TypeScript that exposed a “getWeather” tool. Now, let’s take the next step: connecting our MCP server to Microsoft Copilot Studio so that Copilot agents can call it directly. This section will cover: Step 1 — Publish Your MCP Server to Azure To make your MCP server accessible to Copilot Studio, you’ll need to host it online. There are multiple ways to deploy it — Azure App Service, Azure Container Apps, or even Azure Functions if you prefer serverless. For example, using Azure App Service: Test using curl to ensure it responds with MCP-compatible JSON: Step 2 — Create a New Copilot in Copilot Studio Step 3 — Add Knowledge Sources Optionally, you can enrich your Copilot by adding: This gives your Copilot a baseline knowledge to answer broader questions, while the MCP server will handle specific tasks (like fetching live weather data). Step 4 — Create a Custom Connector in Dataverse To let Copilot Studio talk to our MCP server, we need a custom connector inside Dataverse/CRM. Step 5 — Add the Custom Connector to Copilot Studio you’ll see the MCP server in your Tools section of copilot. To test the setup, let’s ask Copilot: “What’s the current weather in Mumbai?” On the first attempt, Copilot will prompt you to establish a connection. Simply open the Connection Manager, click Connect, and authorize the link to your MCP server. Once connected, Copilot will fetch the live weather details for Mumbai directly from your MCP server. and click retry on the Test window of your copilot. And just like that, your MCP server is live and fully integrated. It can now provide real-time weather updates for any city mentioned in your conversation with Copilot. You can try out different variations of questions or phrasings — Copilot will intelligently interpret your request, extract the city name, and seamlessly call the MCP server to deliver accurate weather details. Beyond Weather: Business Integrations The same process works for enterprise systems. For example, instead of getWeather, you could expose: By publishing these tools via MCP, your Copilot becomes a true enterprise assistant, capable of pulling structured business data and triggering workflows on demand. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com.

As artificial intelligence continues to transform how we build and interact with software, AI agents are emerging as the new interface for users. Instead of clicking through menus or filling out forms, users can simply instruct agents to fetch reports, analyze datasets, or trigger workflows. The challenge is: how do these agents access external tools, APIs, or enterprise systems in a secure and standardized way? This is where the Model Context Protocol (MCP) comes into play. MCP is a protocol designed to connect AI agents to tools in a structured, consistent manner. Instead of building ad-hoc integrations for each agent and each tool, developers can expose their tools once via MCP — making them discoverable and callable by any MCP-compliant AI agent. In this article, we’ll explore: What an MCP server is and how it works a) How MCP uses JSON-RPC 2.0 as its communication layer b) How MCP solves the M×N integration problem c) How to implement a simple Weather Data MCP server in TypeScript d) How to test it locally using Postman or cURL What is an MCP Server? An MCP server is an HTTP or WebSocket endpoint that follows the Model Context Protocol, allowing AI systems to query, interact with, and call tools hosted by developers. MCP consists of several components: -Base Protocol – Core JSON-RPC message types -Lifecycle Management – Connection initialization, capability negotiation, and session handling -Server Features – Resources, prompts, and tools exposed by servers -Client Features – Sampling and root directory lists provided by clients -Utilities – Cross-cutting features such as logging or argument completion All MCP implementations must support the Base Protocol and Lifecycle Management. Other features are optional depending on the use case. Architecture: JSON-RPC 2.0 in MCP MCP messages follow the JSON-RPC 2.0 specification — a stateless, lightweight remote procedure call protocol that uses JSON for request and response payloads. Request format: json Copy Edit {   “jsonrpc”: “2.0”,   “id”: 1,   “method”: “methodName”,   “params”: {     “key”: “value”   } } id is required, must be a string or number, and must be unique within the session. method specifies the operation. params contains the method arguments. Response format: json Copy Edit {   “jsonrpc”: “2.0”,   “id”: 1,   “result”: {     “key”: “value”   } } Or, if an error occurs: json Copy Edit {   “jsonrpc”: “2.0”,   “id”: 1,   “error”: {     “code”: -32603,     “message”: “Internal error”   } } The ID must match the request it is responding to. The M×N Problem and How MCP Solves It. Without MCP, connecting M AI agents to N tools requires M×N separate integrations. This is inefficient and unscalable. With MCP, each agent implements a single MCP client, and each tool implements a single MCP server. Agents and tools can then communicate through a shared protocol, reducing integration effort from M×N to M+N. Project Setup Create the project directory: mkdir weather-mcp-sdk cd weather-mcp-sdk npm init -y Install dependencies: npm install @modelcontextprotocol/sdk zod axios express npm install –save-dev typescript ts-node @types/node @types/express npx tsc –init Implementing the Weather MCP Server We’ll use the WeatherAPI to fetch real-time weather data for a given city and expose it via MCP as a getWeather tool. src/index.ts import express from “express”; import axios from “axios”; import { McpServer } from “@modelcontextprotocol/sdk/server/mcp.js”; import { StreamableHTTPServerTransport } from “@modelcontextprotocol/sdk/server/streamableHttp.js”; import { z } from “zod”; const API_KEY = “YOUR_WEATHER_API_KEY”; // replace with your API key function getServer() {   const server = new McpServer({     name: “Weather MCP Server”,     version: “1.0.0”,   });   server.tool(     “getWeather”,     { city: z.string() },     async ({ city }) => {       const res = await axios.get(“http://api.weatherapi.com/v1/current.json”, {         params: { key: API_KEY, q: city, aqi: “no” },       });       const data = res.data;       return {         content: [           {             type: “text”,             text: `Weather in ${data.location.name}, ${data.location.country}: ${data.current.temp_c}°C, ${data.current.condition.text}`,           },         ],       };     }   );   return server; } const app = express(); app.use(express.json()); app.post(“/mcp”, async (req, res) => {   try {     const server = getServer();     const transport = new StreamableHTTPServerTransport({});     res.on(“close”, () => {       transport.close();       server.close();     });     await server.connect(transport);     await transport.handleRequest(req, res, req.body);   } catch (error) {     if (!res.headersSent) {       res.status(500).json({         jsonrpc: “2.0”,         error: { code: -32603, message: “Internal server error” },         id: null,       });     }   } }); const PORT = 3000; app.listen(PORT, () => {   console.log(`MCP Stateless HTTP Server running at http://localhost:${PORT}/mcp`); }); Testing the MCP Server Since MCP requires specific request formats and content negotiation, use Content-Type: application/json and Accept: application/json, text/event-stream headers. Step 1 — Initialize curl -X POST http://localhost:3000/mcp \   -H “Content-Type: application/json” \   -H “Accept: application/json, text/event-stream” \   -d ‘{     “jsonrpc”: “2.0”,     “id”: 1,     “method”: “initialize”,     “params”: {       “protocolVersion”: “2025-06-18”,       “capabilities”: { “elicitation”: {} },       “clientInfo”: { “name”: “example-client”, “version”: “1.0.0” }     }   }’ Example response: {   “jsonrpc”: “2.0”,   “id”: 1,   “result”: {     “protocolVersion”: “2025-06-18”,     “capabilities”: { “tools”: { “listChanged”: true } },     “serverInfo”: { “name”: “Weather MCP Server”, “version”: “1.0.0” }   } } Step 2 — Call the getWeather Tool curl -X POST http://localhost:3000/mcp \   -H “Content-Type: application/json” \   -H “Accept: application/json, text/event-stream” \   -d ‘{     “jsonrpc”: “2.0”,     “id”: 2,     “method”: “tools/call”,     “params”: {       “name”: “getWeather”,       “arguments”: { “city”: “London” }     }   }’ Example response: {   “jsonrpc”: “2.0”,   “id”: 2,   “result”: {     “content”: [       {         “type”: “text”,         “text”: “Weather in London, United Kingdom: 21°C, Partly cloudy”       }     ]   } } To conclude, we have built an MCP-compliant server in TypeScript that exposes a weather-fetching tool over HTTP. This simple implementation demonstrates: How to define and register tools with MCP How JSON-RPC 2.0 structures communication, and how to make your server compatible with any MCP-compliant AI agent. From here, you … Continue reading Creating an MCP Server Using TypeScript →