The Dynamics 365 MCP Server enables interaction with Microsoft Dynamics 365 using the Model Context Protocol (MCP). With this server, you can:
Retrieve authenticated user information (get-user-info)
Fetch all accounts from Dynamics 365 (fetch-accounts)
Retrieve opportunities associated with a specific account (get-associated-opportunities)
Create new accounts in Dynamics 365 (create-account)
Update existing accounts in Dynamics 365 using its ID and updated details (update-account)
Manages environment configuration for Dynamics 365 connection credentials including client ID, client secret, tenant ID, and service URL.
Provides version control for the codebase, allowing collaborative development through clone, branch, and pull request operations.
Hosts the repository for the MCP server code, enabling collaborative development and issue tracking.
Uses Node.js runtime environment (v16+) to execute the MCP server that connects to Dynamics 365.
Manages package dependencies for the project, including the Model Context Protocol SDK.
Displays status badges in the README showing Node.js version, TypeScript version, MCP status, and license information.
Implements the server using TypeScript 4.x for type-safe interaction with the Dynamics 365 APIs.
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., "@Dynamics 365 MCP Server show me all accounts"
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.
The Microsoft Dynamics 365 MCP Server is a MCP server that provides tools to interact with Microsoft Dynamics 365 using the Model Context Protocol(MCP) by Anthorpic. It allows users to perform various operations such as retrieving user information, accounts, opportunities associated with an account, create and update accounts from Claude Desktop.
This project uses the @modelcontextprotocol/sdk library to implement the MCP server and tools, and it integrates with Dynamics 365 APIs for data operations.
Related MCP server: Dataverse MCP Server
Tool Name | Description | Input | Output |
| Fetches information about the currently authenticated user. | None | User details including name, user ID, and business unit ID. |
| Fetches all accounts from Dynamics 365. | None | List of accounts in JSON format. |
| Fetches opportunities associated with a given account. |
| List of opportunities in JSON format. |
| Creates a new account in Dynamics 365. |
| Details of the created account in JSON format. |
| Updates an existing account in Dynamics 365. |
| Details of the updated account in JSON format. |
Before setting up the project, ensure you have the following installed:
Node.js (v16 or higher)
NPM (Node Package Manager)
A Dynamics 365 instance with API access
Azure Active Directory (AAD) application configured for Dynamics 365 API access
Follow these steps to set up and run the project locally:
git clone https://github.com/your-repo/dynamics365-mcp-server.git
cd dynamics365-mcp-servernpm installCreate a .env file in the root of the project and add the following variables:
CLIENT_ID=your-client-id
CLIENT_SECRET=your-client-secret
TENANT_ID=your-tenant-id
D365_URL=https://your-org.crm.dynamics.com
npm run build
node build\index.jsYou should see the following output:
Dynamics365 MCP server running on stdio...Install Claude Desktop
Navigate to Settings > Developer > Edit Config
Edit claude_desktop_config.json
{
"mcpServers": {
"Dynamics365": {
"command": "node",
"args": [
"<Path to your MCP server build file ex: rootfolder/build/index.js>"
],
"env": {
"CLIENT_ID": "<D365 Client Id>",
"CLIENT_SECRET": "<D365 Client Secret>",
"TENANT_ID": "<D365 Tenant ID>",
"D365_URL": "Dynamics 365 url"
}
}
}
}Restart Claude Desktop
Now you should be able to see the server tools in the prompt window
Let's test a prompt by invoking tool - get-user-info
Run following command in terminal
npx @modelcontextprotocol/inspector node build/index.js
Go to 🔍 http://localhost:5173 🚀
Now you can connect to server and terst all the tools!!
If you encounter issues, ensure the following:
The .env file is properly configured.
The Azure AD application has the necessary permissions for Dynamics 365 APIs.
The Dynamics 365 instance is accessible from - your environment.
You can also add debug logs in the code to trace issues. For example:
console.error("Debugging: Loaded environment variables:", process.env);Contributions are welcome! Feel free to submit a pull request or open an issue for any bugs or feature requests.
To contribute:
Fork the repository.
Create a new branch for your feature or bug fix.
Commit your changes and submit a pull request.
We appreciate your contributions! 😊
Create a new account in Dynamics 365
| Name | Required | Description | Default |
|---|---|---|---|
| accountData | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a new account, implying a write operation, but fails to mention critical details such as required permissions, whether the operation is idempotent, error handling, or any side effects. This leaves significant gaps in understanding the tool's 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 a single, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration, earning full marks for brevity and structure.
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 complexity of a creation tool with no annotations, 0% schema coverage, no output schema, and nested objects, the description is incomplete. It lacks details on parameters, behavioral traits, return values, and usage context, making it insufficient for effective tool invocation without additional guesswork.
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 0% description coverage and includes one parameter 'accountData' as an empty object with additionalProperties false, making it effectively undocumented. The description provides no information about what 'accountData' should contain, its structure, or example values, failing to compensate for the schema's lack of detail.
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 ('Create') and resource ('new account in Dynamics 365'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'update-account' beyond the basic verb difference, missing explicit scope or uniqueness details.
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?
No guidance is provided on when to use this tool versus alternatives like 'update-account' or 'fetch-accounts'. The description lacks context about prerequisites, exclusions, or specific scenarios for creation, offering only a basic statement without usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch accounts from Dynamics 365
| 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 'fetch' implies a read operation, but doesn't disclose behavioral traits such as permissions needed, rate limits, pagination, or what 'accounts' includes (e.g., all accounts or filtered). This leaves significant gaps for an agent.
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, efficient sentence with no wasted words. It's appropriately sized and front-loaded, making it easy 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 no annotations, no output schema, and a read operation with potential complexity (e.g., fetching accounts could involve filters or pagination), the description is incomplete. It lacks details on behavior, return values, or context needed for effective use.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is fine here. Baseline is 4 for 0 params, as it doesn't need to compensate for any gaps.
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 ('fetch') and resource ('accounts from Dynamics 365'), making the tool's purpose understandable. However, it doesn't differentiate from sibling tools like 'get-associated-opportunities' or 'get-user-info', which might also retrieve data, so it's not fully specific.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'create-account' and 'update-account', it's implied for read operations, but there's no explicit context, exclusions, or named alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch opportunities for a given account from Dynamics 365
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool fetches data, implying a read-only operation, but lacks details on permissions, rate limits, error handling, or output format. This is a significant gap for a tool with zero annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a simple tool, earning full marks for conciseness.
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 lack of annotations, output schema, and low schema description coverage, the description is incomplete. It doesn't address behavioral aspects like safety, performance, or return values, leaving gaps that could hinder an AI agent's effective use of the tool.
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 description mentions 'for a given account,' which aligns with the 'accountId' parameter in the schema. However, with 0% schema description coverage and only one parameter, the description adds minimal meaning beyond the schema's structure. It doesn't explain the format or constraints of 'accountId,' so it meets the baseline for low parameter count.
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 ('fetch') and resource ('opportunities for a given account from Dynamics 365'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'fetch-accounts' or 'get-user-info', which could involve related data but different resources.
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?
No guidance is provided on when to use this tool versus alternatives. The description implies it's for fetching opportunities linked to an account, but it doesn't specify prerequisites, exclusions, or compare it to other tools that might handle opportunities or accounts differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user info from Dynamics 365
| 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 of behavioral disclosure. It only states the action ('Get user info') without details on permissions needed, rate limits, response format, or whether it's a read-only operation. For a tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence with no wasted words. It is appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
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 no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., auth needs, return values) and does not compensate for the absence of structured data. For a tool with complexity implied by sibling tools, more context is needed.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add param info, but that's acceptable here. Baseline is 4 for zero parameters, as the schema fully covers the lack of inputs.
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 the verb ('Get') and resource ('user info from Dynamics 365'), which provides a basic purpose. However, it lacks specificity about what 'user info' entails (e.g., basic profile, permissions, contact details) and does not distinguish this tool from potential siblings like 'fetch-accounts' or 'create-account', making it somewhat vague.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention context, prerequisites, or exclusions, such as whether it retrieves current user info, requires authentication, or differs from sibling tools like 'fetch-accounts' for account data. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing account in Dynamics 365
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | ||
| accountData | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Update an existing account,' implying a mutation operation, but lacks details on permissions required, whether changes are reversible, error handling, or side effects. This is a significant gap for a mutation tool with zero annotation coverage.
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, efficient sentence with zero waste. It is appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
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 complexity of a mutation tool with no annotations, 0% schema coverage, no output schema, and nested objects, the description is incomplete. It lacks essential details such as behavioral traits, parameter meanings, return values, and usage context, making it inadequate for safe and effective tool invocation.
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 0%, so the schema provides no parameter details. The description adds no information about parameters like 'accountId' or 'accountData,' failing to explain what data can be updated or the format expected. It does not compensate for the low schema coverage, leaving parameters undocumented.
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 ('Update') and resource ('an existing account in Dynamics 365'), making the purpose unambiguous. It distinguishes from 'create-account' by specifying 'existing account,' but doesn't explicitly differentiate from other siblings like 'fetch-accounts' beyond the update action.
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 provides no guidance on when to use this tool versus alternatives like 'create-account' or 'fetch-accounts.' It mentions 'existing account,' which implies a prerequisite of an account ID, but offers no explicit usage context, exclusions, or comparisons to 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.
v1.0.0create-accountfetch-accountsget-associated-opportunitiesget-user-infoupdate-accountScored across 5 tools
Each tool has a clearly distinct purpose with no overlap: create-account and update-account handle account creation and modification, fetch-accounts retrieves accounts, get-associated-opportunities fetches related opportunities, and get-user-info handles user data. The descriptions clearly differentiate the target resources and actions.
The tools follow a consistent verb-noun pattern with hyphens (e.g., create-account, fetch-accounts), except for get-user-info which uses 'info' instead of a more specific noun like 'user'. This minor deviation slightly affects consistency, but the overall pattern is clear and readable.
With 5 tools, the server is well-scoped for managing Dynamics 365 accounts and related data. Each tool earns its place by covering essential CRUD operations for accounts and providing useful related functions like fetching opportunities and user info, without being overly sparse or bloated.
The toolset provides solid coverage for account management with create, fetch, and update operations, plus useful extensions for opportunities and user info. A minor gap exists in lacking a delete-account tool, which agents might need to work around, but core workflows are well-supported.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Official Microsoft MCP Server to query Microsoft Entra data using natural language
API-first CRM for LLMs - contacts, companies, deals and activities over a native MCP server.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
