Microsoft Dynamics 365 MCP 服务器是一款 MCP 服务器，它提供使用 Anthorpic 的模型上下文协议 (MCP)与 Microsoft Dynamics 365 交互的工具。它允许用户执行各种操作，例如检索用户信息、帐户、与帐户关联的业务机会，以及从Claude Desktop创建和更新帐户。
该项目使用@modelcontextprotocol/sdk库实现MCP服务器和工具，并与Dynamics 365 API集成进行数据操作。
Related MCP server: Dataverse MCP Server
工具名称 | 描述 | 输入 | 输出 |
| 获取有关当前已验证用户的信息。 | 没有任何 | 用户详细信息包括姓名、用户 ID 和业务部门 ID。 |
| 从 Dynamics 365 获取所有帐户。 | 没有任何 | JSON 格式的账户列表。 |
| 获取与给定帐户相关的机会。 |
| JSON 格式的机会列表。 |
| 在 Dynamics 365 中创建新帐户。 |
| 已创建帐户的详细信息（JSON 格式）。 |
| 更新 Dynamics 365 中的现有帐户。 |
| 更新后的帐户详细信息（JSON 格式）。 |
在设置项目之前，请确保已安装以下内容：
Node.js （v16 或更高版本）
NPM （节点包管理器）
具有 API 访问权限的 Dynamics 365 实例
为 Dynamics 365 API 访问配置的 Azure Active Directory (AAD) 应用程序
按照以下步骤在本地设置并运行项目：
git clone https://github.com/your-repo/dynamics365-mcp-server.git
cd dynamics365-mcp-servernpm install在项目根目录中创建一个 .env 文件并添加以下变量：
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.js您应该看到以下输出：
Dynamics365 MCP server running on stdio...导航至“设置”>“开发者”>“编辑配置”
编辑 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"
}
}
}
}重启Claude桌面
现在您应该能够在提示窗口中看到服务器工具
让我们通过调用工具 get-user-info 来测试提示
在终端中运行以下命令
npx @modelcontextprotocol/inspector node build/index.js
前往 🔍 http://localhost:5173 🚀
现在您可以连接到服务器并测试所有工具！！
如果遇到问题，请确保以下事项：
.env 文件已正确配置。
Azure AD 应用程序具有 Dynamics 365 API 所需的权限。
可从您的环境访问 Dynamics 365 实例。
您还可以在代码中添加调试日志来追踪问题。例如：
console.error("Debugging: Loaded environment variables:", process.env);欢迎贡献代码！欢迎提交 Pull 请求或创建 Issue，以解决任何 Bug 或提出任何功能请求。
贡献：
分叉存储库。
为您的功能或错误修复创建一个新的分支。
提交您的更改并提交拉取请求。
感谢您的贡献！😊
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…
