dhino's Dataverse MCP server vs Microsoft's

Microsoft ships a standard Dataverse MCP server. dhino ships one too. They both connect AI agents to Dataverse, but they govern that access very differently. Here is what changes when you pick dhino.

Why a second MCP server exists at all

Once you point Copilot Studio, the Microsoft Agent Framework, or any other agent at Dataverse through the standard MCP server, the agent inherits whatever the calling user can reach. That is fine for a demo. In production it means an agent built for one task can read every table the user has rights to, write back as that user, and leave a single audit trail that says "the user did it."

The questions stack up quickly. Who is accountable when an agent updates the wrong record? How do you scope what one agent can do versus another? How do you call your own business logic instead of letting the model figure CRUD out on the fly? How do you bring in payment data from Business Central without standing up a second MCP server and reconciling its identity model?

That is the gap dhino's Dataverse MCP server fills. Same protocol. Different governance layer.

The short answer

The Microsoft Dataverse MCP server and the dhino Dataverse MCP server both implement Model Context Protocol over Microsoft Dataverse, but they govern agent access differently. Microsoft's server gives an agent the same reach as the user who invoked it, over standard CRUD, over Dataverse alone. dhino's server narrows that down per agent, exposes your own business actions as named tools, can include data from outside Dataverse, and logs what the agent did, not just what the user did. Same protocol. Different governance layer.

Feature comparison

Both servers speak MCP. The difference is what they let an agent see, do, and prove. Read the table left-to-right per row to see what you give up by sticking with the standard server, and what you gain by adding dhino on top.

Microsoft Dataverse MCP server dhino Dataverse MCP server
Surfaces Dataverse CRUD verbs (create, read, update, delete). Each verb can be turned on or off, but the toggle applies across all tables the user can reach. Per-agent, per-table, per-action scoping. One agent reads Accounts and updates Cases. Another agent has its own scope, defined separately.
As of May 2026, the standard server surfaces built-in CRUD verbs only. Dataverse Custom APIs and Custom Actions are not registered as named MCP tools in its public capability set. Custom Business Actions and Dataverse Custom APIs are registered as named MCP tools. The agent calls defined business logic, not a CRUD chain that has to approximate it.
By default, the agent acts under the invoking user's Dataverse permissions. The agent's effective rights match whoever invokes it, so an admin invocation gives the agent admin-level rights for that call. Agents authenticate to dhino with their own credentials. The scope granted to the agent is separate from what the invoking user can see, so the same person can use different agents with different access without juggling role assignments.
Row-level visibility follows the user's Dataverse security roles. Tightening per agent means duplicating roles for every agent. Row-level and field-level filters configurable per agent. "Only this department," "only active records," or "only the user's own opportunities" are all expressible without inventing new security roles.
Microsoft's Dataverse MCP server is scoped to Dataverse. Combining data from other sources means running and connecting to a separate MCP server per source. One dhino MCP server can combine Dataverse with Business Central, Power BI, or other sources behind a single endpoint. For the agent it looks like one data source.
No durable context layer. Each agent has to be prompted with what entities mean and how they relate. dhino carries durable context: domain concepts ("lease agreement," "qualified opportunity") are defined once with their tables, relationships, and rules, then reused across agents and use cases.
Standard Dataverse auditing captures record-level changes against the invoking user. There is no separate audit dimension for the agent itself. Per-agent audit trail of MCP tool calls, including the call inputs and the result. Each agent's activity can be reviewed independently of the user that invoked it.

Which Dataverse MCP server should you use?

The Microsoft server is the right starting point for many scenarios. dhino is what you add when the governance shape changes.

Use Microsoft's Dataverse MCP server when

  • A single agent acting with the calling user's full permissions is the right shape.
  • CRUD over standard tables is enough; you do not need to expose custom business logic.
  • A single audit dimension (the user) is sufficient for compliance.
  • You only need to reach Dataverse, not other data sources.

Use dhino's Dataverse MCP server when

  • You are building more than one agent and they need different access.
  • You want to expose Custom Business Actions and Custom APIs, not just CRUD.
  • You need the agent's identity and rights to be separate from the invoking user.
  • You need per-agent audit trails or one endpoint that spans multiple sources.

Example: a lease management agent

The table lists capabilities. Here is what they look like when an agent has actual work to do.

With Microsoft's server, the agent reads and writes any Dataverse table the invoking user can reach, using standard CRUD. If the user is an admin, so is the agent. If delete is enabled for the user, the agent can delete. Custom logic in Dataverse, like a tested "RenewLeaseContract" action, is not callable. Combining Dataverse data with payment records in Business Central means a second MCP server and a second integration.

With dhino, the same agent is scoped to LeaseAgreements (read and update), Documents (read), and BillingEvents (create), and nothing else. It cannot delete in any table, regardless of what the user could do directly. It calls "RenewLeaseContract" by name. Payment context from Business Central comes through the same endpoint. Every call by the agent is logged with inputs and outcome, so "the lease agent did it" is a sentence you can actually defend in an audit.

Configuration sits with whoever owns the platform: scopes, action allow-lists, and source mappings are defined once per agent in dhino, not duplicated across security roles in Dataverse. The same configuration pattern underpins data access templates elsewhere in dhino.

Same protocol either way. The difference is whether "the lease agent did it" is a sentence you can actually say in an audit, and whether the next agent you build inherits the same controls or starts from zero.

Related reading

Frequently asked questions

What is a Dataverse MCP server?
A Dataverse MCP server is a Model Context Protocol endpoint that lets AI agents read and act on Microsoft Dataverse data through a defined set of tools. Microsoft ships one. dhino ships one. Both speak the same protocol; what differs is which tools they expose and how they govern who can call them.
Is dhino replacing Microsoft's Dataverse MCP server?
No. Both servers speak the same protocol (MCP) over the same data layer (Dataverse). dhino's server is what you connect agents to when you need finer-grained access control, custom business actions, a service identity per agent, multi-source aggregation, or per-agent audit. If a single agent acting with the user's full permissions over standard CRUD is the right shape, the Microsoft server is enough.
Why not just use Microsoft's MCP server with strict Dataverse security roles?
You can. Dataverse security roles are powerful. The limit is that the agent runs as the calling user, so its permissions are whoever invokes it. Tightening per-agent access through roles means duplicating roles for every agent. dhino keeps the agent's scope separate from the user's, so the same person can invoke different agents with different access without inventing new security roles.
Can dhino's MCP server expose data from outside Dataverse?
Yes. One dhino MCP server can combine Dataverse with Business Central, Power BI, or other sources behind a single endpoint. For the agent, it looks like one data source. The access rules and audit trail apply across all of them.
How are Custom Business Actions different from raw CRUD?
Raw CRUD is "create, read, update, delete" against one table at a time. A Custom Business Action is a named operation that wraps tested business logic, often touching multiple tables and applying rules an agent should not have to re-invent. As of May 2026, Microsoft's standard Dataverse MCP server registers only the built-in CRUD verbs; Dataverse Custom APIs and Custom Actions are not surfaced as named MCP tools. dhino's server registers them, so an agent calling "RenewLeaseContract" runs the tested logic for that operation rather than a CRUD chain that has to approximate it.
Does dhino's MCP server work with Microsoft Copilot Studio and the Microsoft Agent Framework?
Yes. dhino exposes a standards-compliant MCP endpoint. Copilot Studio and the Microsoft Agent Framework both connect to it via the protocol. Other MCP-enabled clients can also connect; we recommend testing your specific client against the endpoint before production.
Where does dhino's MCP server run?
dhino runs as multi-tenant SaaS on Microsoft Azure, with European data residency available for customers that need it. The MCP endpoint is hosted in the same environment as the rest of the dhino platform; no additional self-hosting is required.

See dhino's Dataverse MCP server in action

Bring us one agent you are trying to build or have already shipped. We will walk through the per-agent scope, the custom actions, and the audit trail against your own data, not a demo tenant.

See also how dhino compares overall and dhino Trust .

Last verified against Microsoft's Dataverse MCP server: May 2026.