Dataverse MCP Server Custom APIs: What Changed

07 Nov 2026

9 min

MCP

AI Agents

Automation

Microsoft's Dataverse MCP Server now exposes custom APIs to connected AI agents, not just standard table reads and writes. That means business logic you already built as a Dataverse Custom API, a discount calculation, an approval check, a shipment-damage workflow, becomes something any MCP-connected agent (Claude, Copilot Studio, a custom harness) can discover and call directly, without a developer writing a new tool wrapper for every agent that needs it.

If you integrate systems for a living, this is the detail worth sitting with. It is not "Dataverse added another API." It is Microsoft choosing where integration logic should live: inside the platform, registered once as metadata, rather than duplicated across every agent you connect to it.

What changed in the Dataverse MCP Server this week?

Before this release, the Dataverse MCP Server gave agents standard CRUD access to tables: query records, create records, inspect schema. Custom business logic, the kind most enterprises wrap in a Dataverse Custom API rather than scattering across plugins and client code, was invisible to the agent. You'd have to hand-build a tool definition for each piece of logic you wanted an agent to reach.

Microsoft's October 26, 2026 announcement closes that gap: the Dataverse MCP Server now discovers and invokes Custom APIs directly from Dataverse metadata. One notable limit: Custom Actions are not currently supported in the Dataverse MCP Server, only Custom APIs. If your business logic still lives in a Custom Action, it stays invisible to agents until you migrate it or wrap it.

The same week, Microsoft also took Copilot UX components to general availability with SharePoint Framework (SPFx) 1.24, letting teams bring interactive dashboards, forms, and business actions into the Copilot conversation itself, built on the MCP Apps model for interactive UI. Two releases, one week, one direction: Microsoft is making Power Platform and Microsoft 365 agent-ready by opening existing business logic and UI to MCP clients, instead of asking every agent builder to reimplement it.

How does an agent actually find and call a custom API?

This is the part worth understanding if you're designing for it, because it is a pattern you'll see repeated elsewhere as MCP matures. Per Microsoft's own description of the flow, the agent doesn't start knowing your Custom API exists. Three distinct MCP tool calls do the work:

search - the agent calls the MCP server's search tool with keywords pulled from the user's request ("damaged shipment," "refund," "follow-up"). The Dataverse MCP server indexes Custom APIs alongside tables, skills, and scopes, and returns a result.
describe - the agent asks for the operation's contract: what parameters it needs, what it returns.
invoke_api - the agent calls it.

No one hand-writes a tool description for the agent. The MCP server derives all three steps from the Dataverse metadata you already created when you registered the Custom API. If you've ever built a REST wrapper for an LLM tool call and manually written the JSON schema description by hand, you'll recognize how much tedious, error-prone glue code this removes, and also how much it depends on your metadata being accurate and complete, because the agent only knows what the metadata tells it.

text

User: "Flag this shipment as damaged and start the replacement process"

Agent -> MCP search("damaged shipment")
MCP   -> returns Custom API path: /customapis/flag_damaged_shipment

Agent -> MCP describe(flag_damaged_shipment)
MCP   -> returns parameter schema (shipmentId, damageType, photos)

Agent -> MCP invoke_api(flag_damaged_shipment, {...})
MCP   -> executes server-side logic, returns result

Why this matters for integration architecture, not just Dataverse admins

Here's the integration implication, and it's the reason this is worth covering beyond a Microsoft feature note: this is a consolidation pattern, not a Dataverse-specific trick. Before MCP-aware discovery, every time you wanted a new agent (a Copilot Studio bot, a Claude-based internal tool, a custom LangChain agent) to trigger a piece of business logic, someone wrote a bespoke tool definition and wired it to that one agent's harness. Logic lived in N places: once in Dataverse, and once per agent integration.

Custom API discovery collapses that to one place. Write the business rule once as a Custom API with clean, well-documented parameters. Every MCP-connected agent that can reach your Dataverse MCP Server gets it for free, present and future, with no additional per-agent wiring. That's the same architectural bet fluidlabs makes when we design custom integrations between large platforms: push the transaction boundary and the business rule into the system of record once, instead of re-implementing it in every connector, bot, or agent that needs to call it.

It also changes what "integration-ready" means for a platform. A system that exposes clean, well-described business logic as discoverable metadata, whether that's a Dataverse Custom API or a Docusign Workflow Builder action, is cheaper to connect to agents than one where the logic is buried in code the agent can't see. If you're an ISV or a platform team deciding how to open your system to agentic clients, "can an MCP client discover and describe my operation without a human writing the wrapper" is now a real design question, not a hypothetical one.

Where does this break?

A few places worth flagging before you build on it:

Custom Actions aren't covered yet. If your team standardized on Custom Actions (common in older Dataverse solutions, since Custom APIs are the newer, cleaner mechanism), that logic is invisible to the MCP server until you migrate it to a Custom API or add a wrapper.
Discovery quality depends entirely on your metadata. The search step matches on keywords and metadata descriptions. A Custom API with a vague name and no description is functionally undiscoverable to an agent, the same failure mode as a REST endpoint with no documentation, just moved one layer up.
Authorization still has to be real. MCP discovery makes an operation easy to find; it does not replace scoped authorization. The same access controls that gated the Custom API for a human-built client still need to gate it for an agent, and this is exactly the category of problem the Model Context Protocol and its OAuth scope model are meant to address as the spec matures. Treat an agent calling your Custom API with the same suspicion you'd apply to any external caller.
One unverified data point, flagged for transparency: at publication there's no confirmed public rollout stage (preview vs. broad GA) for this specific capability beyond Microsoft's announcement post itself (unverified beyond that post). Check your tenant's release notes before you plan around it in production.

How does this compare to the Docusign agentic integration pattern?

If you've read our guide to connecting AI agents to Docusign over MCP, the shape here will look familiar. Docusign shipped its own MCP connector for the same reason Microsoft just extended Dataverse's: agents need a standard, discoverable way to trigger real business transactions, not just read data. The common thread across both platforms is the same architectural question: where does the logic that triggers a real-world action live, and how many places does it have to be rebuilt?

That question is also exactly what Baton solves on the other side of the equation. Where Dataverse's custom API support lets an agent discover and call logic that already lives in Dataverse, Baton's job is making sure that an event in a source platform, a CRM record, a form submission, an external webhook, reliably triggers the right Docusign Workflow Builder run on the first try, with HMAC verification and retries handling the failures a one-off webhook script won't. Different layer, same principle: consolidate the triggering and transaction logic in one place instead of rebuilding it per integration.

What should integration teams do now?

If you run Dataverse and you're building or planning agent integrations, three practical steps:

Inventory your Custom Actions. Anything still built as a Custom Action is invisible to the MCP server today. Decide what's worth migrating to a Custom API versus what stays internal-only.
Audit your Custom API descriptions and parameter schemas before you expose them to agents. Discovery quality is a direct function of metadata quality, not a Microsoft problem you can defer.
Treat agent callers as external callers for authorization purposes. Discoverability is not authorization. Scope what an agent can actually invoke the same way you'd scope an external API consumer.

FAQ

Does the Dataverse MCP Server support Custom Actions as well as Custom APIs? No. Per Microsoft's announcement, Custom Actions are not currently supported in the Dataverse MCP Server; only Custom APIs are discoverable and callable by connected agents.

How does an MCP-connected agent find a Dataverse Custom API without a developer writing a tool definition? The agent calls the MCP server's search tool with keywords from the user's request, then a describe tool to learn the parameter contract, then invoke_api to execute it. All three steps are derived from Dataverse metadata registered when the Custom API was created, per Microsoft's description of the flow.

What else did Microsoft ship the same week as Dataverse MCP custom API support? Microsoft took Copilot UX components to general availability with SPFx 1.24, letting teams bring interactive forms, dashboards, and business actions directly into the Copilot conversation using the MCP Apps model.

Is this the same Model Context Protocol used by Claude and Docusign's MCP connector? Yes. The Dataverse MCP Server, Docusign's MCP connector for Claude, and Copilot Studio all implement the same open Model Context Protocol specification for connecting LLM-based agents to tools and data, which is why the discovery pattern (search, describe, invoke) looks similar across platforms even though the underlying systems don't.

The takeaway

Microsoft just made the case, in production, for pushing business logic behind one well-described API surface instead of wiring it into every agent harness separately. If you're already running Dataverse, that case is made for you: audit your Custom APIs, fix the vague ones, and decide what else deserves the same treatment. If you're wiring agents into Docusign, Salesforce, or another large platform and want that same consolidation without rebuilding it from scratch, talk to the fluidlabs team about a working session on your agent integration architecture, or browse the rest of our Docusign IAM and integration resources for the Docusign side of this same pattern.