Model Context Protocol (MCP) + Dataverse: The Next Leap for AI and the Power Platform

If you’re even a little bit invested in Power Platform, you’ve probably seen the Model Context Protocol (MCP) popping up in community posts, new features, and the Microsoft docs. If you’re wondering, “Is this just another buzzword, or does it actually make my life easier?” — this post is for you!

Let’s break down what MCP is, what you can do with it (hint: a lot!), and why this matters for every maker, developer, and AI enthusiast on the platform.

What is Model Context Protocol (MCP)?

MCP is a new open protocol from Microsoft that lets Large Language Model (LLM) applications — like Copilot Studio, Claude, VS Code Copilot — connect securely and natively to enterprise data sources like Dataverse. This means that your AI agents can “see” and work with your real Dataverse data, safely and efficiently, with no custom connectors or APIs needed.

Learn more: Connect to Dataverse with Model Context Protocol (preview)

Why Does MCP Matter?

• No more manual queries: Just ask questions in natural language — “How many leads are active?” or “Show me a chart of cases by city” — and your agent (Claude, Copilot, etc.) does the heavy lifting.
• Instant insights and updates: You can fetch, update, and create Dataverse records as simply as sending a chat message.
• Build bots and automations faster: Tools like Copilot Studio can now “think” in real time with your data — great for building conversational agents and process automations.
• Less code, more power: You can do all of this without needing to write FetchXML, SQL, or custom code.
• Future-proof integration: Any AI or LLM tool supporting MCP can plug into your Dataverse data — opening up a huge ecosystem of smart, connected tools.

What Can You Actually Do with MCP + Dataverse?

Here’s just a taste of what’s possible right now (and it’s still just in preview!):

• List all your tables: “Show me all tables in Dataverse.”
• Describe schema: “Describe the account table.”
• Read/query data: “How many contacts live in London?”
• Create/update records: “Add a new contact: John Smith, email john@contoso.com.”
• Build charts instantly: “Create a pie chart showing opportunities by owner.”
• Integrate knowledge sources: “What’s the latest update from the product knowledge base?”

Basically, you can talk to your database, and it talks back with real answers, records, or charts — no code, just conversation.

How to Set Up MCP with Dataverse (Step by Step)

This is easier than you think. Here’s the process, based on Microsoft’s official docs :

Prerequisites:

• Dataverse environment (Power Platform, Power Apps, or Power Automate)
• VS Code installed (for advanced setup)
• Claude Desktop (optional, but great as an MCP client)
• .NET SDK 8.0 (for the MCP server local proxy)
• Your Dataverse tenant ID
• Dataverse connection (created in Power Automate)

What Tools Are Available?

From the official documentation, Dataverse MCP tools include:

• create_record — Insert a row into a table
• describe_table — Get table schema
• execute_prompt — Run a predefined prompt
• list_knowledge_sources — Show available knowledge sources
• list_prompts — List prompts
• list_tables — List available tables
• read_query — Read data from tables
• retrieve_knowledge — Query a knowledge source
• update_record — Update a record

You can enable/disable each tool in your MCP config, so you’re always in control.

Limitations & Tips

• Preview Feature: As of mid-2025, MCP with Dataverse is still in preview — don’t use in production just yet!
• Security: Make sure you understand the permissions you grant your AI client.
• Customization: Tune which tools you expose, and set your own prompts/knowledge sources for maximum flexibility.

Conclusion

Model Context Protocol (MCP) is the next frontier for Power Platform, AI, and no-code/low-code automation. You can connect any MCP-enabled AI client (Copilot, Claude, custom bots) to Dataverse and get natural, conversational access to your enterprise data.

No more clunky queries. No more endless charts. Just instant answers, insights, and updates — straight from your data, with the power of AI.

A big thank you to the amazing video guide creator
Nathan Rose — your step-by-step walkthrough made the whole process so much more approachable and fun for the community.

https://youtu.be/IkBRy8bVtrc?si=CZFlaY36Ojap15GM

How to Master Solution Layering and Troubleshoot Customization Conflicts in Dynamics 365 CRM

If you’ve ever deployed a solution to a Dynamics 365 CRM environment only to find your changes don’t show up, or something strange happens with forms or fields, you’re not alone. Almost every Dynamics admin or customizer has run into the mysterious world of solution layering. It’s not always intuitive, but understanding how solution layers work is absolutely key for troubleshooting post-deployment issues and building a sustainable ALM (Application Lifecycle Management) process.

Let’s break down what solution layering is, how conflicts can occur, and how to confidently resolve them.

What Is Solution Layering in Dynamics 365 CRM?

Solution layering refers to the way Dynamics 365 (and Power Platform/Dataverse) manages multiple sets of customizations, especially when you have more than one solution (managed or unmanaged) touching the same component.

Every customizable object, like a form, view, or field, can have multiple “layers” of configuration applied. The platform keeps track of these layers and uses a clear order to decide what users will see and how components behave.

The Three Key Layers

1. System (Base) Layer:
   The lowest layer. This is the original, out-of-the-box state ,think of it as the bedrock for every component.
2. Managed Solution Layers:
   Each imported managed solution gets its own layer. Managed layers stack on top of the system layer in the order they’re imported. The most recent one always sits above earlier ones.
3. Unmanaged Layer:
   The very top. Any direct customizations made in the environment (through the UI, or via unmanaged solutions) live here. There is only one unmanaged layer per component, and the latest change always wins in this layer.

Why does this matter? Because only the topmost value (or a merge of layers, depending on the component) is active at runtime. This is why the changes you just imported sometimes seem to “disappear” or get overridden by something you didn’t expect.

How Do Layer Conflicts Happen?

Let’s say you install a third-party managed solution that customizes the Account form, maybe it adds a couple of new sections. Later, you deploy your own managed solution, which also customizes that Account form (perhaps adding a new section for internal use).

• At runtime, the Account form merges customizations from both solutions, unless they directly conflict (for example, both try to change the header text). In that case, the topmost layer “wins.”
• If someone makes a direct change in production (for instance, hiding a field to fix a quick issue), that unmanaged layer sits above everything else, even above your newly-deployed managed solution.

Common Example:
You deploy a managed solution expecting to see a new field on the form, but it’s not visible to users. You open the solution layers viewer and find an unmanaged change sitting on top (maybe a previous quick fix), which is hiding your field.

Merge or “Last One Wins”?

• Some things merge:
  For example, if two managed solutions add different fields to the same form, both fields are visible, because those additions merge.
• Some things overwrite:
  If two solutions provide a button or field with the same name/ID, or try to set a property like the display name or visibility, the “last one wins.” The topmost solution layer’s value is what the user will see.
• Unmanaged layer always wins:
  Any direct changes made in the environment (the unmanaged layer) always take precedence. That’s why making direct changes in production is risky, it can override everything below.

How to Troubleshoot with the Solution Layers Tool

Dynamics 365 includes a powerful tool for investigating component layering:

1. Go to the Power Apps Maker portal
2. Find the component (form, view, field, etc.) you’re troubleshooting
3. Select it and choose “See solution layers”

You’ll see all the layers, in order, and can review what each solution changed. Properties that were altered by a solution are highlighted.

Pro tip: If you can’t see your recent change in production, check here first. If there’s an unmanaged layer on top, that’s almost always the culprit.

The Unmanaged Layer: A Double-Edged Sword

Unmanaged customizations are a frequent cause of “why isn’t my solution working?” problems. For instance:

• A System Customizer makes a “quick fix” to a form in production, creating an unmanaged layer.
• You deploy a managed solution to update that same form, but your changes don’t appear, because the system uses the unmanaged version as the active layer.

How to fix:

• Either incorporate that unmanaged change into your managed solution and redeploy
• Or: Use “Remove Active Customizations” to delete the unmanaged layer for that component (be aware: this discards those ad-hoc changes!)

Warning: If the unmanaged layer added fields with data, removing it will remove the field and its data.

Resolving Managed Solution Conflicts

When two managed solutions conflict (maybe both add a field with the same name, or try to change the same form property), you have a few options:

1. Manage Layer Order
   Re-import the solution you want to take precedence. (Remember, the most recently imported managed solution is on top.)
2. Adjust the Customizations
   If you own both solutions, tweak them so they don’t overlap (use unique names or separate component responsibilities).
3. Use a Patch or Hotfix Solution
   If you can’t remove the “problem” managed solution (e.g., it’s a core or third-party solution), create a tiny managed patch or hotfix solution. This patch will layer above, overriding the problematic setting or property.
4. Uninstall or Clean Up
   As a last resort, uninstall the managed solution causing the issue, but only if nothing else depends on it.

Dependency Issues: Why Can’t I Uninstall a Solution?

Another layering-related headache: Sometimes you can’t uninstall or upgrade a solution because something else (another solution or unmanaged change) is using its components. You’ll usually get a descriptive error listing the dependencies.

• Use the solution layers viewer to see what’s on top of the component you’re trying to remove.
• Remove or reconfigure any dependent solutions or unmanaged changes first.

How to Use Layering to Your Advantage

Solution layering isn’t just a problem to solve, it’s a powerful tool if you plan for it.

• Modular design:
  Have a base managed solution for your core entities, and layer feature-specific managed solutions on top. Teams can work independently as long as they avoid overlapping components.
• Safe rollbacks:
  If you need to remove a feature, you can just uninstall its solution — everything beneath remains intact.
• Hotfixes:
  Emergency patch needed? Deploy a managed patch solution. It sits on top, overrides what’s needed, and can be rolled back easily.

Best Practices & Tips

• Always use the Solution Layers viewer when troubleshooting.
• Document which solutions “own” which parts of your system to avoid accidental overlap.
• Avoid direct unmanaged changes in production — if you must, plan to integrate them back into a managed solution and remove the unmanaged layer ASAP.
• Check Solution Import logs: These can warn you if components were skipped or a conflict occurred.
• Test all changes in a non-prod environment first. Removing or reordering solution layers can have side effects.

Summary

Solution layering in Dynamics 365 CRM can feel confusing at first, but it’s a robust system for handling complex, multi-team, and even multi-vendor deployments. The trick is to respect the order of layers, avoid unmanaged “quick fixes” in production, and always use the tools Microsoft provides to see what’s going on.

If you ever run into a situation where “my change isn’t showing up” or “something broke after a deployment,” the solution layers tool should be your first stop. With a clear ALM strategy and a little practice, you’ll turn layering from a headache into a feature that helps you build, troubleshoot, and evolve your CRM with confidence.

Extra Reading & Resources:

• Solution layers and merge behavior in Power Platform — Power Platform | Microsoft Learn
• View the history of a solution — Power Apps | Microsoft Learn
• View dependencies for a component in Power Apps — Power Apps | Microsoft Learn
• Solution layers in Power Platform — Power Apps | Microsoft Learn

Got a layering war story or pro tip? Drop it in the comments!