Microsoft Dynamics 365 MCP 서버는 Anthorpic의 모델 컨텍스트 프로토콜(MCP)을 사용하여 Microsoft Dynamics 365와 상호 작용할 수 있는 도구를 제공하는 MCP 서버입니다. 사용자는 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) 애플리케이션
프로젝트를 로컬로 설정하고 실행하려면 다음 단계를 따르세요.
지엑스피1
npm 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 Desktop을 다시 시작하세요
이제 프롬프트 창에서 서버 도구를 볼 수 있어야 합니다.
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);기여를 환영합니다! 버그나 기능 요청이 있으시면 언제든지 풀 리퀘스트를 제출하거나 이슈를 열어주세요.
기여하려면:
저장소를 포크합니다.
기능이나 버그 수정을 위해 새로운 브랜치를 만듭니다.
변경 사항을 커밋하고 풀 리퀘스트를 제출하세요.
귀하의 기여에 감사드립니다! 😊
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…
