Skip to main content
Glama
Sign In
Dynamics 365 MCP Server

Dynamics 365 MCP Server

by Kenny-666
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

upload_note_attachments

Destructive

Preview and upload up to 10 note attachments to Dynamics 365 CRM records using validated relationship metadata and a plan hash, with sequential writes that stop on failure or unknown outcome.

Instructions

Preview then upload 1–10 CRM note attachments (5 MiB each, 20 MiB total). Uses validated relationship metadata and a current plan hash. Sequential non-atomic writes stop on failure or unknown outcome; no automatic retries.

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": {
      "parent_collection": "<parent_collection>",
      "parent_id": "<parent_id>",
      "files": "<files>"
    },
    "name": "upload_note_attachments"
  }
}

Input Schema

NameRequiredDescriptionDefault
filesYes
dry_runNo
parent_idYes
expected_hashNo
parent_collectionYes
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.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds real value beyond that: writes are sequential and non-atomic, stop on failure or unknown outcome, and are never retried automatically — exactly the partial-failure semantics an agent needs before calling a destructive batch operation. It stops short of saying what is left behind after a mid-batch failure or what permissions are required.

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?

Three dense sentences with the operation, its limits, and its failure behavior front-loaded; nothing is redundant. The middle sentence's jargon ('validated relationship metadata') is compact to the point of being opaque.

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 batch mutation with no output schema and low schema coverage, the description covers limits and failure behavior well. It is still incomplete on where expected_hash and parent_collection values come from, what a dry-run returns, and how to recover from a partially applied batch.

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% across 6 parameters, so the description must compensate. It clarifies files (count and size ceilings), dry_run ('Preview'), and expected_hash ('current plan hash'), but leaves parent_collection, parent_id ('validated relationship metadata' is too vague), and environment_profile undefined.

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 ('upload') plus resource ('CRM note attachments') and adds scope limits (1-10 files, 5 MiB each, 20 MiB total). The verb alone cleanly separates it from the sibling read/delete tools (list_note_attachments, download_note_attachment, delete_note_attachments).

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?

'Preview then upload' implies the dry_run-first workflow, and the mention of 'a current plan hash' hints that expected_hash must come from a prior planning step. But it never says explicitly when to use this vs. an alternative, nor where the hash/plan comes from, leaving the agent to infer the workflow.

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