What the Dataverse MCP can and can’t answer
Point an agent at Microsoft's Dataverse MCP and it can query your data, read your schema, and change records. Ask it which plugin writes a column and it stops, for a reason worth understanding before you plan around it.
Microsoft ships a Dataverse MCP server. You enable it per environment, point Copilot Studio, VS Code, Claude or any other MCP client at https://<org>.crm.dynamics.com/api/mcp, and your agent gets typed access to the environment.
It is well built and it removes a lot of drudgery. It is also scoped to a specific job, and the boundary catches people out because the thing it will not do is the thing you most want an agent for.
What it actually exposes
Fifteen tools, and they group into four jobs. Worth reading as a set, because the shape of the set is the answer to the whole question.
| Job | Tools |
|---|---|
| Query and search | read_query for Dataverse SQL SELECT, search_data across structured and unstructured data, search across table schemas and business skills, describe for details on tables, records, schemas, skills and apps. |
| Change records | create_record, update_record, delete_record. |
| Change schema | create_table, update_table, delete_table. |
| Skills and files | upsert_skill, delete_skill, init_file_upload, commit_file_upload, file_download. |
describe_table, list_tables and fetch were removed and folded into describe. The old search became search_data, and searchnow searches metadata. If you keep tool allow-lists by name in your MCP client, they need revisiting. Microsoft's documentation is the current list.
Read that grouping again and the boundary is visible in it. Every tool operates on data and schema. None of them operates on logic.
The question it stops at
Ask an agent holding these tools which plugins write account.creditlimit, and you will usually get something honest and partial. It will query the metadata, list the plugin steps registered against the account table, and then tell you it cannot say which of them writes that particular column.
The registration says a plugin runs on this table. What it writes is inside the compiled assembly, and nothing in the tool list opens that.
The same holds across every other authoring surface. A cloud flow's column writes live in its definition JSON. A classic workflow's live in XAML. A form script's live in JavaScript. A canvas app's live inside the packaged app. Dataverse stores all of it faithfully and interprets none of it, which is the same boundary the platform's own dependency checker has.
What an agent can do about it, and where that stops
Here is the part usually left out, because it complicates a tidy story.
read_query is more powerful than it first looks. The definitions are rows in tables, so an agent can go and get the raw material:
Pull that back and a capable agent can read the XAML or the JSON and tell you, correctly, that this particular workflow sets creditlimit. For one component that works well, and if that is your question you may not need anything else.
Where it breaks
- Scale.One workflow's XAML is a few kilobytes. A mature environment has hundreds of components across five formats, and asking an agent to pull and read all of them to answer one question is a context problem long before it is a cost problem. It is fine for a hunch and hopeless for an inventory.
- Determinism. Ask twice and you can get two answers, because the model is reading rather than parsing. That is acceptable while exploring and not acceptable as the basis for a migration plan or a security review.
- Compiled assemblies. The plugin bytes are reachable, and they are IL. An agent pulling base64 out of a table is not going to decompile it usefully in context, so plugin writes stay invisible no matter how you query.
- Canvas apps. The packaged app is not in Dataverse at all; it lives behind the Power Apps API. No amount of Dataverse SQL reaches it, which is why any tool that does column-level canvas analysis has to ask for a separate permission.
So the honest summary is not that an agent cannot answer dependency questions. It is that an agent can answer them one component at a time, non-repeatably, with two surfaces permanently out of reach.
Since 15 December 2025, Dataverse MCP tools are billed when accessed by agents created outside Copilot Studio, with search_data at a higher rate than the rest. Some Dynamics 365 Premium and Microsoft 365 Copilot licences cover Dynamics data access. A brute-force approach that pulls every definition to answer one question is worth costing before you build a habit around it.
If you are driving Dynamics with an agent
The practical takeaway is to be deliberate about which questions go where.
- Data questions, schema questions, record changes and search: the Dataverse MCP is the right tool and you should use it.
- One-off “what does this specific flow do” questions: pull the definition with
read_queryand let the agent read it. Quick and good enough. - Anything that has to be complete, repeatable, or cover plugin code and canvas apps: that needs the definitions parsed ahead of time rather than read on demand, because the parsing is the hard part and doing it per question does not converge.
That last category is the one worth designing for, because it is where agent-driven Dynamics work usually stalls. The agent is capable. The environment simply has not been read into a form it can query.
What parsing those definitions involves, by hand →