Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jaj-dataverse-dev-mcp List the available Dataverse environments"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Lightweight MCP server for day-to-day Dataverse and Power Platform development.
Connect your agents to multiple Dataverse environments using your existing Azure CLI identity. The server exposes a thin, agent-friendly layer over the Web API for data, metadata, solutions, components, troubleshooting, and development tasks.
Agent → MCP → Azure CLI identity → Dataverse Web API
Add the server to .vscode/mcp.json:
{
"servers": {
"dataverse-dev": {
"command": "npx",
"args": [ "-y", "jaj-dataverse-dev-mcp" ]
}
}
}Save the file and press Start. The first start may take some time while npx downloads the package.
Sign in with the Azure CLI:
az loginCreate environments.json in your project root with the environments you need:
{
"environments": {
"dev": {
"url": "https://org8ffb6d07.crm.dynamics.com/",
"allowWrite": true
}
}
}Open Copilot and try:
List the available Dataverse environments
Call whoami for the dev environment
Show me the names and IDs of the five most recently created accounts
List the unmanaged solutions
That's it!
Other MCP-compatible agents follow the same pattern: run jaj-dataverse-dev-mcp over stdio and provide access to your local Azure CLI session and connection configuration.
Related MCP server: Dataverse MCP Server
There are already several Dataverse MCP implementations, including Microsoft's own tooling.
This project grew out of day-to-day development work where agents frequently needed capabilities beyond the available specialized tools. In many cases, the agent could solve the task successfully by constructing Dataverse Web API requests directly.
This MCP embraces that approach.
Instead of hiding Dataverse behind a large abstraction, it provides broad access to the Web API through a thin wrapper.
It is also designed for developers and consultants who regularly move between projects, customers, and Dataverse environments.
One MCP server can work with multiple Dataverse environments while using existing Azure CLI identity. No separate app registration, client ID, or client secret is required.
Node.js 20+
Azure CLI installed and signed in
Access to one or more Dataverse environment URLs
# Authentication is based on your current Azure CLI identity:
az login
# Useful variants:
az login --tenant <tenant-id> # Specific tenant, if your tenant is not the default
az login --allow-no-subscriptions # Tenant without subscriptions
az login --use-device-code # Remote/headless environments
# To inspect the currently active Azure CLI account:
az account showEnvironments are configured in environments.json in the project root and identified by friendly names such as dev, test, prod.
Agents use these names when selecting which Dataverse environment to work with.
If an environment is in a different tenant than the default Azure CLI tenant, add a tenantId for that environment.
DATAVERSE_ENVIRONMENTS_PATH can be used to override the config file path at runtime.
Example:
{
"environments": {
"dev": {
"url": "https://YOUR-DEV.crm.dynamics.com/",
"allowWrite": true
},
"test": {
"url": "https://YOUR-TEST.crm4.dynamics.com",
"allowWrite": false
},
"prod": {
"url": "https://YOUR-PROD.crm4.dynamics.com",
"allowWrite": false,
"tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
}
}For better agent behavior, add Dataverse-specific instructions to the project where you use the MCP.
Copy docs/examples/copilot-instructions.md to .github/copilot-instructions.md in the workspace where you use the MCP server, then customize it for your project:
replace YOUR-dev, YOUR-test, and YOUR-prod with the environment names from environments.json
replace YOUR_DEFAULT_SOLUTION with the unique name of the primary Dataverse solution
adjust the default environment and safety rules for the project
Commit the customized file to the project repository so all contributors use the same guidance.
The package can also be launched manually with stdio as default transport:
npx -y jaj-dataverse-dev-mcpFor development or clients that use Streamable HTTP add --http.
Although the MCP is intentionally a thin wrapper around the Dataverse Web API, it can support a broad range of development and troubleshooting tasks, for example:
query and update Dataverse records
inspect tables, columns, metadata, publishers, and solutions
create and configure unmanaged solutions
add existing components to solutions
work with Dataverse actions and functions
export solutions for deployment to other environments
This makes it useful for both direct development tasks and agent-driven workflows where the agent inspects Dataverse, decides on the next action, and performs it through the MCP.
Execute a Dataverse Web API request. The path is relative to /api/data/v9.2/. Supports OData queries, CRUD, functions and actions. Use $select and $top where appropriate to avoid unnecessarily large responses. Do not pass a complete URL.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Optional JSON body for POST or PATCH requests. | |
| path | Yes | Path relative to /api/data/v9.2/. Example: accounts?$select=name,accountid&$top=10 Actions such as AddSolutionComponent are also supported. | |
| accept | No | Optional Accept header. Defaults to application/json. | |
| method | Yes | ||
| prefer | No | Optional Dataverse Prefer header, e.g. return=representation or odata.include-annotations="*". | |
| ifMatch | No | Optional If-Match value, e.g. "*" or an ETag. | |
| environment | Yes | Environment name returned by list_environments. | |
| ifNoneMatch | No | Optional If-None-Match value. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose that the path is relative to /api/data/v9.2/ and that it supports OData queries, CRUD, functions, and actions. However, it does not mention authentication requirements, rate limits, error behavior, or what happens with different methods. For a generic API executor, this is a moderate gap, but the description does convey the core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the core purpose, then adds the path base, supported operations, and a performance tip. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic API executor with 8 parameters and no output schema, the description is fairly complete. It explains the path base, supported operations, and gives a performance guideline. It does not explain return values, but since there is no output schema and the tool is a raw API executor, the response format is inherently variable. The main missing piece is authentication context, but that may be handled by the environment parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88%, so the schema already documents most parameters well. The description adds context about the path being relative to /api/data/v9.2/ and the use of $select/$top, which complements the schema. It does not add much beyond the schema for body, accept, prefer, ifMatch, ifNoneMatch, but the schema descriptions are already sufficient. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Execute'), a specific resource ('Dataverse Web API request'), and the base path ('/api/data/v9.2/'). It also distinguishes itself from siblings by being the only tool that makes raw API requests; siblings like ping, list_environments, and whoami are clearly different operations. The instruction 'Do not pass a complete URL' further clarifies the expected input format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool for OData queries, CRUD, functions, and actions. It also provides a practical guideline to use $select and $top to avoid large responses. It does not explicitly name alternatives or say when not to use it, but the sibling tools are distinct enough that an agent can infer when to use this one. The guidance about not passing a complete URL is a useful usage constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the configured Dataverse environments that can be accessed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only listing operation ('configured' and 'can be accessed') but does not disclose potential errors, authentication requirements, or any side effects. For a simple list tool this is acceptable, but it adds no insight beyond the obvious read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It states exactly what the tool does without any fluff. Perfect conciseness for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is minimal. It does not explain what the returned list contains (e.g., names, IDs, details), nor any pagination or ordering. Since an agent may need to know the format of the result to use it correctly, this is a minor gap. However, given the simplicity, it is marginally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema trivially covers everything. Per the baseline rule, this scores a 4. There is nothing to add in the description since no inputs exist to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and the resource (configured Dataverse environments that can be accessed). This distinguishes it from siblings like ping (connectivity), whoami (user identity), and dataverse_request (general request). The specificity of 'configured' and 'can be accessed' adds useful context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. While the purpose is clear, the agent must infer that this is the tool for enumerating environments. There is no mention of when not to use it or any conditions that would route to a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that the MCP server is running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool is read-only and non-destructive in nature (checking is implied), but doesn't disclose what the exact output is (e.g., a simple 'pong' or a detailed status). It's minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action. It's appropriately sized for a tool with no parameters—no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless health-check tool, the description is nearly complete. It covers the purpose and basic behavior. The only minor gap is the lack of explicit detail about the response format, but given the simplicity, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and is fully covered, so the description adds no parameter details—which is fine. Since there are no parameters, the baseline is 4: there is nothing to compensate for, and the description doesn't need to explain any parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking server liveness. It uses a specific verb ('Check') and a clear resource ('that the MCP server is running'). This is unambiguous and distinguishes it from siblings like list_environments (listing) and whoami (identity).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (for health checks), but doesn't explicitly state when not to use it or mention alternatives. There are no exclusions or comparisons to siblings, so while the context is clear, there's no explicit guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Dataverse user, business unit and organization for the Azure CLI authenticated identity.
| Name | Required | Description | Default |
|---|---|---|---|
| environment | Yes | Environment name returned by list_environments. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden. The verb 'Get' clearly indicates a read-only operation, and the phrase 'for the Azure CLI authenticated identity' establishes the authentication context. However, it does not disclose failure behavior, return format, or any side effects, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence with no filler. It leads with the action verb and immediately specifies what is returned, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one required parameter, and no output schema, the description is reasonably complete: it names what is retrieved and the authentication context. It could add a brief note about the environment parameter's origin, but the schema already provides that, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter 'environment' is documented as coming from list_environments, so the schema carries the semantic weight. The tool description itself does not mention the parameter, but it does not need to because the schema is fully descriptive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and names the exact resources returned: Dataverse user, business unit, and organization. It is clear and distinct from the sibling tools by focusing on identity information, though it does not explicitly contrast itself with siblings like dataverse_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no guidance on when to use it versus alternatives, nor any exclusions or prerequisites. The only contextual clue is 'for the Azure CLI authenticated identity,' which implies identity-related use but is not explicit enough to guide an agent choosing between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.4dataverse_requestlist_environmentspingwhoamiScored across 4 tools
Each tool has a clearly distinct purpose: ping checks server availability, list_environments shows configured environments, whoami returns identity info, and dataverse_request handles arbitrary Dataverse API calls. There is no overlap or ambiguity, as the generic tool is explicitly scoped to the Dataverse Web API.
Tool names do not follow a consistent pattern. ping and whoami are single-word commands, list_environments uses verb_noun, and dataverse_request is a noun_noun combination. While readable, the mixed styles are not predictable.
With only 4 tools, the server is well-scoped for its purpose: a few helper tools plus one powerful generic execution tool. This is a reasonable and focused set, not too thin or bloated.
The dataverse_request tool can execute any Dataverse Web API request (CRUD, OData, functions, actions), providing full coverage of the domain. The auxiliary tools add environment and identity context, leaving no obvious gaps in functionality.
Let AI agents query data and act across all your business apps via MCP.
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
Manage portable AI agent playbooks, Agent Skills, MCP configurations, personas, and memory.
Remote MCP for 1,500+ APIs. Vault-managed credentials; OAuth or API key. Search, load, and execute.
