Tools

The server exposes the full v1 API surface as tools: the same documents, links, datarooms, folders, branding, visitors, and analytics you get over HTTP. Argument schemas are identical to the REST API's request shapes, so see the linked reference endpoint for full field detail.

The tool set differs slightly by transport, all in how a local file gets uploaded. 63 tools are shared verbatim; the rest depend on whether the server can read your disk:

• Stdio (Claude Desktop, Claude Code) exposes 66 tools: the 63 shared ones plus upload_document, upload_brand_image, and upload_dataroom_branding_image, which read a local file_path directly because the server runs on your machine. add_document_version also accepts a file_path here.
• HTTP (claude.ai Connectors, ChatGPT Apps) exposes 65 tools: the 63 shared ones plus request_document_upload and an upload_document that takes an upload_id or source_url. A remote server can't read your filesystem, so a local document is uploaded in two steps via a presigned URL (see Uploading an attached file below). The two branding image upload tools do not exist over HTTP; set branding images from a public source_url instead.

Everything else is identical across transports.

Documents (6–7)

Document versions (4)

Folders (6)

Team-library folders, for organizing standalone documents outside any dataroom.

Links (8)

Datarooms (10)

Dataroom folders (6)

Dataroom groups (10)

A group is a named audience inside a dataroom: members (by email or domain) plus per-item view/download permissions. Share a group by creating a link with audience_type: "group". A new group sees nothing until permissions are set.

Branding (9)

A team brand is a named set of viewer settings (logo, banner, colors, welcome message, dataroom layout, link preview); one brand is the team default. A dataroom shows exactly one source, chosen by its mode: team_default, team_brand (pinned brand_id), or custom (its own settings). The model is explained once in the guide Brand a data room.

Seven tools are shared by both transports. The two upload_*_image tools are stdio only; every write tool also accepts images as { "source_url": "https://..." }, which works on both transports.

Branding fields on the write tools: brand_color, accent_color, accent_button_color, apply_accent_color_to_dataroom_view, hide_logo, welcome_message, cta_label, cta_url, card_layout, show_folder_tree, viewer_layout_preset, viewer_header_style, hide_folder_icons_in_main, default_language, custom_link_preview_enabled, link_preview_title, link_preview_description, and the four image slots. Several are plan-gated; a blocked write returns 403 plan_restriction with details.fields naming the offending ones (see Plan gating).

Visitors (3)

Analytics (4)

Uploading an attached file (HTTP transport)

request_document_upload uploads a local file over the HTTP transport, followed by either upload_document (to create a new document) or add_document_version (to add a new version to a document that already exists). Over that transport the server can't reach your filesystem, so a file you attach in a chat on an HTTP client (e.g. claude.ai) is uploaded the same way large datasets are handled in MCP generally: a presigned URL used as a side channel, so the file's bytes never pass through the model's context window (no base64 blow-up, no token cost).

The client does this in three steps, the middle one inside its code execution sandbox:

1. request_document_upload with the file's file_name, content_type, and content_length (bytes). Returns:

   {
     "upload_url": "https://s3.../report.pdf?X-Amz-Signature=...",
     "upload_id": "upload_3xA5v7r8K9mN2pQ4",
     "required_headers": {
       "Content-Type": "application/pdf",
       "Content-Disposition": "attachment; filename=\"report.pdf\"; ..."
     },
     "expires_at": "2026-06-13T13:20:15.092Z",
     "expires_in": 3600,
     "curl_command": "curl -X PUT -T <local-file-path> '<upload_url>' -H 'Content-Type: ...' -H 'Content-Disposition: ...'"
   }

2. PUT the raw bytes to upload_url from the code-execution sandbox. The simplest path is the returned curl_command — run it after replacing <local-file-path> with the attached file's path. The signed headers (Content-Type and Content-Disposition) are already baked into it; these aren't optional, dropping either is a 403, which is why a bare curl -T won't do. To PUT it yourself instead, send required_headers verbatim — e.g. in Python:

   import requests
   requests.put(upload_url, data=open(path, "rb").read(), headers=required_headers)

3. Redeem the upload_id:

   • New document — upload_document with the upload_id (and name, plus optional folder_id / create_link) to register the uploaded file as a document.
   • New version of an existing document — add_document_version with document_id + upload_id. The document id, its share links, its dataroom placement, and its version history are preserved. The new version becomes primary in the same transaction; existing links serve it once background conversion finishes, which is usually seconds. Use this to push updated files into a dataroom rather than uploading a second document.

The upload_id is single-use and upload_url expires after expires_in seconds (at expires_at, ~1 hour); if the PUT fails, request a fresh pair. If the file is already hosted at a public HTTPS URL, skip steps 1–2 and pass source_url to upload_document / add_document_version directly.

Allow the storage domain (code-execution egress)

Code-execution sandboxes are network-isolated by default — outbound requests are blocked unless the destination host is on an allowlist. The presigned upload_url points at the storage backend (for Papermark cloud, AWS S3), so if that host isn't allowed the PUT in step 2 fails — a DNS error, a timeout, or a "blocked by allowlist" message — even though the request_document_upload tool call itself succeeded. This is a client-side sandbox setting, not something Papermark controls.

The host to allow is the hostname of the upload_url returned by request_document_upload — read it straight from the response. For Papermark cloud that's an *.amazonaws.com S3 host (e.g. your-bucket.s3.us-east-1.amazonaws.com); a self-hosted or custom-domain deployment uses whatever host its upload_url shows.

claude.ai / Claude Desktop

• Pro / Max (personal): Settings → Capabilities → Code execution and file creation → Allow network egress. Personal plans default to All domains, so the upload works with no setup. If you've narrowed egress, switch to package managers and specific domains and add the storage host.
• Team / Enterprise: the org owner controls this in Organization settings → Capabilities. The default is package managers only, which blocks the storage PUT. An owner must choose package managers and specific domains and add the storage host (e.g. s3.amazonaws.com), or select All domains. Members can't change this themselves — ask an owner.

ChatGPT and other clients

There's no per-user egress allowlist for ChatGPT's code interpreter — its sandbox network is managed by OpenAI. If the sandbox can't reach the storage host, fall back to uploading from a public source_url (upload_document with source_url), or use the stdio transport. Check your client's sandbox-network docs for any equivalent setting.

Result shapes

Tool results mirror the REST API responses field-for-field; the server invents nothing. Two conventions are worth calling out:

• Every resource carries a read-only object field (document, link, dataroom, …) so the model can tell resource types apart.
• delete_* tools return the API's deleted-object acknowledgment, { "id": "…", "object": "…", "deleted": true }, not a custom shape.

Writes are scope-gated

The agent can only call tools whose required scopes are on the token. A read-only token (documents.read, links.read, …) gives you a read-only agent. The write tools (create_*, update_*, delete_*, upload_*, attach_dataroom_document) return a 403 forbidden error envelope, which the MCP client surfaces back to the model so it can apologize and ask the user.

If you want a stricter sandbox, point the server at a non-production environment via PAPERMARK_API_URL (and mint a separate token there with only the scopes the agent needs).

Tool naming

Tool names use snake_case. That's the MCP convention, not a Papermark choice. They're the same in stdio and HTTP transports.