Microsoft’s July 2026 Dataverse update puts a practical layer around the agent story. The Dataverse plugin is now available for GitHub Copilot, Claude, and Cursor, while Microsoft’s MCP catalog has grown to more than 60 ready servers. Organizations can also bring internal MCP servers under their own controls.
For MSPs that build and run Power Platform environments, the useful part is not another demo of an agent writing code. It is the combination of a familiar developer workflow, Dataverse-aware tooling, and governance that can carry the work into production.
## The Dataverse plugin follows developers into their coding tools
The Dataverse plugin brings Dataverse operations into the coding agent a developer already uses. Microsoft says the plugin can route requests through the Dataverse MCP server, the Python SDK, PAC CLI, or Dataverse CLI. Developers can describe the task in natural language instead of jumping between documentation, browser tabs, admin portals, SDK references, and command-line tools.
That reduces context switching, but it does not remove the need for review. The value for an MSP is a more consistent path from a client request to an examined change:
1. A developer describes the Dataverse task in the coding agent.
2. The plugin selects the appropriate Dataverse tool or interface.
3. The developer reviews the proposed code, command, or data operation.
4. The change goes through the same source control, testing, and deployment process used for other Power Platform work.
The plugin is available through these marketplaces and directories:
– [GitHub Copilot Dataverse plugin](https://awesome-copilot.github.com/plugins/#file=plugins%2Fdataverse)
– [Claude Dataverse plugin](https://claude.com/plugins/dataverse)
– [Cursor Dataverse marketplace](https://cursor.com/marketplace/microsoft-dataverse)
– [Microsoft Dataverse skills on GitHub](https://github.com/microsoft/Dataverse-skills)
Microsoft describes the open-source skill architecture as using least-privilege patterns and documented authentication. The plugin also respects existing Dataverse role-based access control (RBAC). That distinction matters: the agent should operate inside the permissions already assigned to the identity, not become a shortcut around them.
For a multi-client MSP, the immediate benefit is standardization. A team can teach developers one reviewed workflow and apply it across separate environments, rather than letting every engineer assemble a different mix of scripts, SDK calls, and portal actions.
## The MCP catalog gives agents a common connection model
Model Context Protocol (MCP) gives agents a standard way to discover and call tools. Microsoft’s catalog now includes more than 60 ready MCP servers, spanning productivity, developer experiences, business applications, and partner platforms.
The catalog is intended to connect agents to systems customers already run. Microsoft says the same standard can be used across Microsoft 365 Copilot, Copilot Studio, Azure AI Foundry, GitHub Copilot, and other MCP-compatible clients. The Dataverse MCP server is already supported in Copilot Studio, Azure AI Foundry, and other compatible clients.
That is useful for MSP service design. A Dataverse request rarely stops at Dataverse. A support workflow may need a ticket, a customer record, a deployment status, and a notification. A delivery team may need to connect application code with business data and an approval process. A common tool connection model makes those integrations easier to evaluate and repeat.
It also creates a new review point. More connectors mean more possible paths into customer systems. MSPs should treat each MCP server as an integration with an identity, permissions, data boundary, owner, and failure mode. “It connects” is not enough for a managed service.
## Certified MCPs add a trust signal for partner tools
Microsoft’s MCP certification program gives ISVs and partners a path to package and publish MCP servers for customer discovery and adoption. The certification material calls for an MCP manifest with the endpoint URL, a Tools JSON file, and Key Vault-backed authentication details for secrets management.
Once certified, partner MCPs can be published across supported Microsoft experiences, including Copilot Studio and Azure AI Foundry. Certification does not replace an MSP’s own security review, but it can reduce the initial uncertainty around how a partner integration is packaged, authenticated, and presented.
For an MSP, the practical filter is simple: prefer integrations with clear ownership, documented authentication, an explicit data scope, and a support path. A certification badge can help with discovery. It should not be the only approval step.
## Bring Your Own MCP without losing the guardrails
The more interesting option for service providers may be Bring Your Own MCP. Microsoft describes BYO MCP as a way to register a custom tool, proprietary API, internal workflow, or industry-specific system and make it available to agents inside the organization.
The point is flexibility without giving up administration. An organization can register the server once, make it discoverable for the right agent scenarios, and manage it with expectations around admin approval, visibility, and control.
That gives MSPs a reasonable governance model for internal automation and client-specific extensions:
– **Use RBAC at the data layer.** Dataverse agents should run as identities with the minimum roles required for the task. Do not use a highly privileged service account just because it is convenient.
– **Approve servers before exposure.** Record who owns each MCP server, what systems it reaches, which tenants may use it, and which agent scenarios are allowed.
– **Keep access auditable.** Capture agent identity, MCP server, tool invoked, target environment, operation, and outcome. If the platform or connector does not expose enough detail, add logging at the integration boundary before calling it production-ready.
– **Separate client environments.** Treat tenant, environment, and service-account boundaries as part of the design. A shared integration must not quietly become a shared data path.
– **Test destructive operations.** Read-only discovery and reporting are a different risk class from create, update, delete, solution import, or data migration actions. Require explicit approval for the latter.
– **Have a rollback path.** Agent-driven changes still need backups, solution history, deployment gates, and a human escalation route.
Microsoft’s Dataverse plugin already respects Dataverse RBAC and least-privilege patterns. BYO MCP governance is where the MSP has to connect that product behavior to its own operating model: approval records, environment boundaries, logs, and repeatable reviews.
## What MSPs should do next
Start with a small, low-risk pilot rather than enabling every connector at once.
1. **Choose one internal development team and one non-production Dataverse environment.** Use the team’s primary coding agent, whether that is GitHub Copilot, Claude, or Cursor.
2. **Test repeatable tasks.** Good candidates include schema inspection, query generation, test-data cleanup, plugin scaffolding, and documentation updates. Keep production writes out of the first pass.
3. **Compare the workflow with the current one.** Measure time lost to portal and documentation switching, review effort, failed commands, and rework. The goal is not agent activity; it is a safer, faster delivery path.
4. **Map permissions before adding tools.** Document the Dataverse roles, identities, MCP servers, endpoints, and client environments involved.
5. **Define an approval boundary.** Decide which operations an agent may perform automatically, which require a developer review, and which always require a separate change approval.
6. **Verify the audit trail.** Have the team answer a basic incident question: who or what changed this record, solution, or environment, and through which tool?
7. **Turn the result into a client-facing service pattern.** If the pilot works, package it as a controlled Power Platform development or operations offering instead of handing customers an unbounded agent setup.
The ICRC Digital Emblem work Microsoft also discussed this month is a separate, niche signal from the security and humanitarian sector: it explores machine-readable identification for protected medical and humanitarian digital assets. It is a useful reminder that automated defenders need trustworthy signals, but it is not part of the Dataverse plugin or MCP governance model.
## From agent demos to governed deployments
The July Dataverse update makes the agent workflow more practical. Developers can use Dataverse capabilities from GitHub Copilot, Claude, or Cursor, connect to a growing MCP ecosystem, and register internal tools without abandoning enterprise administration.
For MSPs, the opportunity is less about letting an agent run loose and more about making agent use repeatable. Put the plugin inside existing RBAC, source control, testing, deployment, and audit processes. Start with bounded tasks, prove the workflow in a non-production environment, and expand only when the controls are as clear as the productivity gain.
### Sources
– [Dataverse Is Your Agent Data Platform: Here’s What’s New in July 2026](https://www.microsoft.com/en-us/power-platform/blog/2026/07/06/dataverse-july2026/) — Microsoft Power Platform Blog
– [Bring Your Own MCP server](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-tools-for-agent?view=o365-worldwide&toc=%2Fmicrosoft-agent-365%2Ftoc.json&bc=%2Fmicrosoft-agent-365%2Fbreadcrumb%2Fagent365%2Ftoc.json#bring-your-own-byo-mcp-server) — Microsoft Learn
– [MCP certification](https://learn.microsoft.com/en-us/microsoft-copilot-studio/mcp-certification) — Microsoft Learn
– [Making humanitarian protection visible in cyberspace: the promise of the Digital Emblem](https://blogs.microsoft.com/on-the-issues/2026/07/09/making-humanitarian-protection-visible-in-cyberspace-the-promise-of-the-digital-emblem/) — Microsoft On the Issues
