Skip to main content
Glama
Sign In
Dynamics 365 MCP Server

Dynamics 365 MCP Server

by Kenny-666
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

prepare_choice_candidate

Read-only

Prepares a local candidate for inserting a global Picklist option or applying selected localized label changes from reviewed definitions, without writing changes.

Instructions

Prepare one local global Picklist option insertion or selected localized label changes using reviewed definitions. No writes.

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": {
      "baseline": "<baseline>",
      "source": "<source>",
      "target": "<target>",
      "baseline_hash": "<baseline_hash>",
      "source_hash": "<source_hash>",
      "target_hash": "<target_hash>",
      "value": "<value>",
      "selections": "<selections>"
    },
    "name": "prepare_choice_candidate"
  }
}

Input Schema

NameRequiredDescriptionDefault
valueYes
sourceYes
targetYes
baselineYes
selectionsYes
source_hashYes
target_hashYes
baseline_hashYes
environment_profileNoOptional named environment profile for this call; omit to use the configured default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.3.0

TDQS

C2.6/5.0
Behavior3/5

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

The readOnlyHint=true annotation already tells the agent this is side-effect free, and "No writes" merely restates it. What the description does add is that the output is a local candidate prepared for later use rather than a live change, which is useful framing, but it says nothing about the required baseline/source/target hash agreement or what happens when those hashes are stale.

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

Conciseness3/5

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

Two short sentences, front-loaded with the action, so it is not padded. But the brevity comes at the cost of clarity — "local global Picklist" is awkward enough to slow interpretation, so the compactness does not fully earn its place.

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

Completeness2/5

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

This is a high-complexity tool: 9 parameters, 8 required, nested objects, no output schema, and near-zero schema description coverage. Against that complexity the description leaves out the candidate artifact identity, the hash-matching contract, the meaning of the two modes, and how the prepared candidate is subsequently consumed.

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

Parameters2/5

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

Schema description coverage is only 11% (just environment_profile), so the description must compensate and does not. It vaguely gestures at the two modes (option insertion, localized label selection) but leaves baseline, source, target, value, and all three hashes entirely unexplained, including the critical requirement that the hashes match the reviewed definitions.

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

Purpose3/5

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

The description names a verb ("Prepare") and a resource ("global Picklist option insertion or selected localized label changes"), so the general intent is recoverable. However, the phrase "local global Picklist" is internally confusing, and nothing distinguishes this tool from the closely named sibling stage_isolated_choice_candidate or from prepare_field_label_candidate.

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

Usage Guidelines2/5

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

"using reviewed definitions" hints at a precondition but never states when to call this tool versus stage_isolated_choice_candidate, nor what a "reviewed definition" is or where it comes from. There is no when-not guidance and no named alternative.

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