EAD_Enterprise_Suite_MCP: Command for Claude Code

Certified Notifications — Attachments

Attach one or more documents to a certified notification. Read this before attaching anything: the API imposes an ordering rule here that it does not impose anywhere else, and violating it fails the send after the notification already exists.

The rule

Documents must be registered and uploaded BEFORE any recipient is added, and every document must reach READY_TO_SEND before the notification is sent.

Attaching after recipients, or sending while a document is still PENDING, fails with 409 / 404 NOTIFICATION_NOT_FOUND. This is tested behaviour, not a guess.

The consequence worth internalising: once a recipient exists, you can no longer attach a document. If an upload fails, stop and fix it before adding anyone. A notification that already has recipients can never receive the file you meant to send with it.

The easy way

notification_send_with_attachments does the whole sequence in one call:

notification_send_with_attachments
  caseFileId=<cf-id>
  subject="Your contract"           language=en_GB     type=NO_RESPONSE
  content="<p>Please review the attached document.</p>"
  attachments=[ { file: { source: "path", path: "/abs/path/contract.pdf" } } ]
  recipients=[ { firstName: "Alice", lastName: "Smith", email: "[email protected]" } ]

Each attachment's file accepts four sources:

source	Fields	Use when
path	path	the file is on the server's own machine (stdio/local mode only)
base64	filename, contentBase64	you already hold the bytes
url	url	the file is at an HTTPS URL (fetched with SSRF protection)
n8n-binary	binaryRef	the file came from a previous node in an n8n workflow

The hash, the presigned upload and the READY_TO_SEND wait are handled internally.

If an attachment fails, the tool stops before adding recipients and returns the draft's notificationRequestId. That is deliberate — see the rule above. Retry the failed file with notification_document_add, or discard the draft with notification_request_delete.