Tools

The server exposes the full v1 API surface as tools: the same documents, links, datarooms, folders, 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:

• Stdio (Claude Desktop, Claude Code) exposes 57 tools. upload_document and add_document_version read a local file_path directly, because the server runs on your machine.
• HTTP (claude.ai Connectors, ChatGPT Apps) exposes 58 tools — the same 57 plus request_document_upload. A remote server can't read your filesystem, so local-file upload happens in two steps via a presigned URL (see Uploading an attached file below). Over HTTP, upload_document and add_document_version take an upload_id or a source_url instead of a file_path.

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.

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_document, 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.