Skip to main content
Glama
Sign In
Dynamics 365 MCP Server

Dynamics 365 MCP Server

by Kenny-666
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

update_crm_user_profile

Destructive

Preview and update selected CRM user profile fields or enabled status with ETag confirmation and readback, requiring explicit acknowledgement for access changes.

Instructions

Preview then update selected CRM user profile fields or enabled status with metadata-confirmed ETag and readback. Changing isdisabled requires explicit acknowledgement; roles, business unit, domain and passwords are excluded.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "user_id": "<user_id>",
      "changes": "<changes>"
    },
    "name": "update_crm_user_profile"
  }
}

Input Schema

NameRequiredDescriptionDefault
changesYes
dry_runNo
user_idYes
expected_hashNo
allow_access_changeNo
environment_profileNoOptional named environment profile for this call; omit to use the configured default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.2

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as a non-idempotent destructive write, and the description meaningfully adds beyond that: preview/dry-run before commit, metadata-confirmed ETag concurrency control, readback verification, and an acknowledgement gate for the access-disabling field. It stops short of saying what a mismatch or a failed acknowledgement actually returns or whether disabling revokes active sessions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, with the preview-then-commit model and the scope exclusions front-loaded. The density ('metadata-confirmed ETag and readback') is slightly compressed but each clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with a nested changes object and no output schema, the definition covers the critical safety story (preview, concurrency token, acknowledgement). It is still incomplete on two fronts: the semantics of allow_access_change and environment_profile, and the failure behavior when the hash does not match or acknowledgement is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 17%, the description must carry more weight; it does hint that 'preview' maps to the dry_run flag and 'ETag' maps to the expected_hash concurrency token, and it bounds which fields 'changes' may contain. However, allow_access_change is never explained, and the description calls the precondition token an 'ETag' while the schema exposes a 64-hex expected_hash, leaving an agent unsure of the exact relationship.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (preview then update), a specific resource (CRM user profile fields / enabled status), and bounded scope via the explicit exclusion list (roles, business unit, domain, passwords). Together with the exclusions, an agent can separate this from siblings like manage_user_roles or create_onprem_domain_user without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Preview then update' establishes the intended two-step workflow, and 'changing isdisabled requires explicit acknowledgement' gives a concrete precondition. The exclusion list implicitly routes the agent elsewhere for roles/domain/password work, though it never names the sibling tool to use instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools