Skip to main content
Glama
Sign In
Dynamics 365 MCP Server

Dynamics 365 MCP Server

by Kenny-666
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

backup_customization

Preview and persist a backup of a saved or unpublished Dynamics 365 web resource, main form, or public view without publishing it.

Instructions

Preview and persist a saved/unpublished Web Resource, main form or public view backup. Requires D365_JOURNAL_DIR. Does not publish.

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": {
      "kind": "<kind>",
      "id": "<id>"
    },
    "name": "backup_customization"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
kindYes
dry_runNo
logical_nameNo
expected_hashNo
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.5/5.0
Behavior3/5

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

Annotations already declare non-read-only, non-idempotent, non-destructive. The description adds two pieces of real behavioral context: a required environment variable and the explicit statement that live publishing does not occur. It still omits where the backup is written, what happens to an existing backup, and how the hash/safety check behaves.

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

Conciseness5/5

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

Three short sentences, each carrying distinct information: action and scope, prerequisite, and exclusion. Fully front-loaded with zero filler.

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 6-parameter, non-idempotent write tool with no output schema and low schema coverage, the key undocumented pieces (dry_run semantics, expected_hash purpose, logical_name role, return value) are missing. What is present is accurate but not sufficient to fully constrain correct invocation.

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 coverage is only 17% (only environment_profile is documented), so the description should compensate more. It does clarify the kind enum by naming the three resource types in prose, but leaves dry_run, logical_name, and expected_hash completely unexplained in both places.

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 concrete verb pair (preview/persist) and names the exact resource kinds (web resource, main form, public view), which lets an agent tell it apart from siblings like publish_web_resource or restore_customization_backup. The dual 'preview and persist' framing is slightly ambiguous about which one a given call performs, keeping it below a 5.

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?

The 'Does not publish' clause and the D365_JOURNAL_DIR prerequisite give useful context, but the description never says when to choose this over restore_customization_backup or the various publish_* tools. Usage is implied by the resource kinds rather than stated.

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