El servidor MCP de Microsoft Dynamics 365 proporciona herramientas para interactuar con Microsoft Dynamics 365 mediante el Protocolo de Contexto de Modelo (MCP) de Anthorpic. Permite a los usuarios realizar diversas operaciones, como recuperar información de usuarios, cuentas y oportunidades asociadas a una cuenta, así como crear y actualizar cuentas desde Claude Desktop .
Este proyecto utiliza la biblioteca @modelcontextprotocol/sdk para implementar el servidor y las herramientas de MCP, y se integra con las API de Dynamics 365 para operaciones de datos.
Related MCP server: Dataverse MCP Server
Nombre de la herramienta | Descripción | Aporte | Producción |
| Obtiene información sobre el usuario autenticado actualmente. | Ninguno | Detalles del usuario, incluido nombre, ID de usuario e ID de unidad comercial. |
| Obtiene todas las cuentas de Dynamics 365. | Ninguno | Listado de cuentas en formato JSON. |
| Obtiene oportunidades asociadas con una cuenta determinada. |
| Listado de oportunidades en formato JSON. |
| Crea una nueva cuenta en Dynamics 365. |
| Detalles de la cuenta creada en formato JSON. |
| Actualiza una cuenta existente en Dynamics 365. |
| Detalles de la cuenta actualizada en formato JSON. |
Antes de configurar el proyecto, asegúrese de tener instalado lo siguiente:
Node.js (v16 o superior)
NPM (Administrador de paquetes de nodos)
Una instancia de Dynamics 365 con acceso a API
Aplicación de Azure Active Directory (AAD) configurada para el acceso a la API de Dynamics 365
Siga estos pasos para configurar y ejecutar el proyecto localmente:
git clone https://github.com/your-repo/dynamics365-mcp-server.git
cd dynamics365-mcp-servernpm installCree un archivo .env en la raíz del proyecto y agregue las siguientes 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.jsDebería ver el siguiente resultado:
Dynamics365 MCP server running on stdio...Instalar Claude Desktop
Vaya a Configuración > Desarrollador > Editar configuración
Editar 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"
}
}
}
}Reiniciar Claude Desktop
Ahora debería poder ver las herramientas del servidor en la ventana de solicitud. 
Probemos un mensaje invocando la herramienta: get-user-info 
Ejecute el siguiente comando en la terminal
npx @modelcontextprotocol/inspector node build/index.js
Vaya a 🔍 http://localhost:5173 🚀
¡Ahora puedes conectarte al servidor y probar todas las herramientas!
Si encuentra problemas, asegúrese de lo siguiente:
El archivo .env está configurado correctamente.
La aplicación Azure AD tiene los permisos necesarios para las API de Dynamics 365.
Se puede acceder a la instancia de Dynamics 365 desde: su entorno.
También puedes agregar registros de depuración al código para rastrear problemas. Por ejemplo:
console.error("Debugging: Loaded environment variables:", process.env);¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios o abrir un problema para solucionar cualquier error o solicitud de funcionalidad.
Para contribuir:
Bifurcar el repositorio.
Crea una nueva rama para tu característica o corrección de error.
Confirme sus cambios y envíe una solicitud de extracción.
¡Agradecemos tus contribuciones! 😊
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…
