Skip to main content
Glama
Sign In
Dynamics 365 MCP Server

Dynamics 365 MCP Server

by Kenny-666
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

update_record_with_journal

Destructive

Preview and conditionally update simple Dataverse record fields using a persistent before-image and optimistic concurrency to prevent conflicting writes.

Instructions

Preview and conditionally update simple record fields with a persistent before-image. Requires D365_JOURNAL_DIR and native optimistic concurrency.

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": {
      "collection_name": "<collection_name>",
      "id": "<id>",
      "data": "<data>"
    },
    "name": "update_record_with_journal"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
dataYes
dry_runNo
expected_hashNo
collection_nameYes
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

A3.6/5.0
Behavior4/5

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

Annotations already declare non-readonly, non-idempotent, destructive. The description adds meaningful behavior on top: a persistent before-image is written (implying recoverability via rollback_record_journal), the call can be previewed with dry_run, an environment variable must be configured first, and concurrency is enforced. It stops short of describing what a hash mismatch or a dry_run returns.

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?

A single dense sentence with no filler, front-loading the action and the journaling behavior before the prerequisites. It is arguably too compressed, but nothing is wasted.

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 6-parameter mutation with no output schema and low schema coverage, the definition omits how the before-image is surfaced, what happens on optimistic-concurrency failure, and the semantics of the required parameters. Enough to know it is a journaled conditional update, not enough to call it confidently.

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?

Schema description coverage is only 17%, so the description carries compensation duty. It does explain the intent of dry_run (preview) and expected_hash (optimistic concurrency), but leaves collection_name, id, the 1-20 property constraint on data, and environment_profile entirely to the bare schema. Partial compensation at best.

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

Purpose4/5

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

States a specific compound purpose: preview and conditionally update record fields, with a persistent before-image journal. It distinguishes itself implicitly from plain update_existing_record by naming the preview and journal aspects, but never names a sibling explicitly and 'simple record fields' is left undefined.

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

Usage Guidelines3/5

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

Gives prerequisites (D365_JOURNAL_DIR must be set, optimistic concurrency required) which implies when the tool can be called, but never says when to choose it over update_existing_record or when a rollback via rollback_record_journal is the better path. Usage is implied rather than directed.

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