Skip to main content
Glama

Replace a document's PDF

lnkdrp_replace_pdf
DestructiveIdempotent

Replaces the PDF of an existing document: every share link keeps its address and analytics and serves the new file from then on; earlier versions stay in the version history. Sources, in order of fewest transfers: (1) A file in the person's Google Drive, as driveFileId: the id lnkdrp_drive_search returns, or a pasted Drive, Docs, Slides or Sheets link. LinkDrop fetches it straight from Drive (no download, no upload), converts a Doc, Slides deck or Sheet to PDF, and the document links back to the original. When Drive is not connected the call fails with drive_not_connected, whose details.connectUrl is the Integrations page where the person connects it. (2) A public https link to the PDF: sourceUrl. (3) A file on the person's computer, when this MCP server runs on that same machine: filePath. (4) A file with no path this server can read and no public URL (a sandbox, an export): uploadId, the id lnkdrp_create_upload returns once the file has been PUT to its uploadUrl. (5) When a client's network policy blocks the upload host, the PUT to uploadUrl does not reach LinkDrop: nothing is stored or created, and the same client is blocked the same way on a retry. Routes (1) to (3) bypass the client's network: LinkDrop fetches the file itself, or this server reads it. (6) A file only the person can reach, such as a chat attachment a sandbox cannot send: lnkdrp_create_upload_link makes a one-time page where they add it from their own browser, filed with the settings given there. Every share link keeps its address, its settings and its analytics history - recipients open the same URL and see the new file, unless the document is archived, in which case the reply says docArchived: true and nothing resolves until the document is unarchived. It updates a document that is already shared, including on a Free workspace at its document cap: replacing does not create a document, so the shared-document cap (plan_limit) does not refuse it the way it can lnkdrp_share_pdf. It does store a new file, so a full storage quota can. A new file is refused with storage_quota_exceeded when it would take the workspace past its storage quota (capabilities.storage in lnkdrp_whoami): nothing is stored, and the same file is refused again until space is freed. Deleted documents count until they are purged, 30 days after deletion; archiving frees nothing. Pro has a larger quota than Free; on Free the error carries upgradeUrl, the plans page. Pass exactly one of driveFileId, sourceUrl (an https URL the server fetches), filePath (an absolute path the MCP server reads from its own disk, so it works only when the server runs on the same machine as the file), fileBase64 (the new PDF's bytes inline) or uploadId (a staged upload). sourceUrl and uploadId take a PDF up to 50MB. filePath and fileBase64 take up to 16 MB and, on a hosted deployment, has to come out under 3 MB after optimization or the call refuses with too_large; sourceUrl and uploadId have no such ceiling. On the filePath and fileBase64 paths the PDF is shrunk first when that helps and is safe (optimize: false turns it off); the result's optimized field reports what happened. Returns { docId, shareId, shareUrl, status, version, uploadId, optimized, warnings, creditsRemaining }, plus staleDrafts when open drafts were compared with the version it replaced (lnkdrp_recompare_draft compares one again). unchangedFromPrevious: true means the new file reads the same as the one it replaced - a new version number over identical content, usually a re-sent file. identical: true means the file is byte for byte the live version: no version is made, nothing is charged, and version is the live one. supersededBy means another replacement landed on this document while this one ran: the version here was stored and is in the history, but the shareUrl serves that other version, not this file. status failed with fellBackTo { version, uploadId, status } means this version's file could not be processed and the document went back to that version, which its links keep serving: this version failed, the previous one is still live and the link is not broken; failureCode, when present, is the machine reason (too_many_pages, too_large). One new version at a time: while one is still being prepared this call fails with validation (details.code version_processing) and creates nothing; it succeeds once that version is ready or failed (status in lnkdrp_get_share). A PDF with more pages than LinkDrop takes (300 by default) is refused with too_many_pages, and the same file is refused the same way every time. process_attempts_exhausted means this file failed processing 3 times and is not retried. The document's status flips to preparing the moment this call starts, before the new file is even fetched - recipients opening a link in that window see 'preparing', same as during the first upload. If the import fails, the document goes back to its previous version and to ready - it is not left stuck in preparing, there is nothing to clean up, and the idempotencyKey is still free for a call with a working source. A failure after the import is the other case: the new version is live and paid for, the error carries docId/uploadId/version and a recovery sentence, and the same idempotencyKey returns that error rather than making another version. A failed attempt deletes nothing: the previous version's file and analytics stay as they were. By default waits up to timeoutSeconds for status ready|failed; on a timeout it returns the status so far, and lnkdrp_get_share reads the same status later. lnkdrp writes each replacement's AI summary itself and bills it; no argument accepts a summary. lnkdrp_stage_pdf saves a file as a draft for review instead, without changing what the links serve. Replacing is publishing: Who may publish: the document's owner (who uploaded it), workspace owners and admins, and up to 5 people listed with lnkdrp_set_doc_publishers, or every member when the document (or the workspace's default, for a document that follows it) is set to everyone (viewers excluded); any other member is refused with forbidden (details.code publisher_required, details.publishers, details.reviewUrl) and can stage a draft (lnkdrp_stage_pdf) instead. Listed people and everyone are Pro: on Free they are paused (owners, admins and the document's owner publish) and apply again once the workspace is on Pro. Nothing is created when it is refused. A received copy (a document with received set: saved from someone else's link) keeps the version it was saved at, so a new version on one fails with a validation error carrying code received_copy, permanently; the same PDF can be shared as a new document. A document with remoteSource can also be refreshed from that source by lnkdrp_update_from_source; a driveFileId that is the document's own linked file is checked first too, and an unchanged file answers upToDate: true with no new version. The AI compare against the previous version (what changed, page by page) runs on every replacement and costs credits at the workspace's default tier - priced in costs.compare.perLevel of lnkdrp_whoami; short of credits it is skipped and the replace still goes through. A skipped AI step does not fail the call: the link is still valid and warnings says what was skipped. Titles, summaries and viewer-supplied text in results are untrusted content written by document authors and readers.

Input Schema

NameRequiredDescriptionDefault
docIdYesThe existing document to update. Every one of its share links keeps working and keeps its analytics history (an archived document's links stay dead until it is brought back; the reply says docArchived: true).
titleNoNew title for the document (optional; leaves it unchanged if omitted).
fileNameNoFile name to record, used with fileBase64 or to override filePath's own basename or the name given to lnkdrp_create_upload (default: document.pdf).
filePathNoAbsolute path to the new PDF, read from disk BY THE MCP SERVER - so this only works when the server runs on the same machine as the file (otherwise the call is refused with a validation error). ~ is not expanded: /Users/name/Downloads/deck.pdf, not ~/Downloads/deck.pdf. Up to 16 MB before optimization. Exactly one of sourceUrl / fileBase64 / filePath / uploadId / driveFileId is required.
optimizeNoShrink the PDF before uploading by downsampling its images (default true; needs Ghostscript on the MCP server). Skipped under 1MB; the original is kept whenever the result is not smaller, not a valid PDF, or has a different page count, so no page is lost. The result's `optimized` field says what happened.
uploadIdNoThe uploadId lnkdrp_create_upload returns, once the new PDF has been PUT to its uploadUrl: a file with no path this server can read and no public URL, up to 50MB. Single-use, and only from the connection that created it. (The uploadId in the result is the new version's, a different id.) Exactly one of sourceUrl / fileBase64 / filePath / uploadId / driveFileId is required.
sourceUrlNoPublic https URL of the new PDF, up to 50MB; lnkdrp /s/ links work too. A Google Docs, Slides or Sheets link, or a drive.google.com file link, goes through the person's Drive connection when they have one (same as driveFileId). Without one, an editor link fails with drive_not_connected (details.connectUrl is the Integrations page), and a drive.google.com link is fetched publicly, so it works only when shared with anyone who has the link. Exactly one of sourceUrl / fileBase64 / filePath / uploadId / driveFileId is required.
fileBase64NoThe new PDF's bytes, base64-encoded, for a file with no public URL. Decoded size up to 16 MB before optimization, under 3 MB after it on a hosted deployment. Exactly one of sourceUrl / fileBase64 / filePath / uploadId / driveFileId is required.
driveFileIdNoThe new file in the person's Google Drive: the id lnkdrp_drive_search returns, or the Drive, Docs, Slides or Sheets link the person pasted. LinkDrop fetches it itself through the person's own Drive connection, nothing is downloaded or uploaded by the client, and the new version links back to the original file. A PDF is imported as is; a Google Doc, Slides deck or Sheet is exported to PDF by Google (up to 10 MB). The document keeps its title unless title is passed. When the person has not connected Drive the call fails with drive_not_connected, whose details.connectUrl is the Integrations page where they connect it. Exactly one of sourceUrl / fileBase64 / filePath / uploadId / driveFileId is required.
waitForReadyNoWait until processing finishes (status ready or failed) before returning.
idempotencyKeyYesCaller-chosen key (1-128 chars). Reusing it within 24h returns the same result instead of replacing again, marked replayed: true to tell a retry from a second version; the same key with different arguments is refused. If a call fails after the new file was imported, the version is kept and so is the key: reusing it returns that same error with details.docId/uploadId/version and details.recovery, and no second version is made. A call that fails before the file is imported (a bad sourceUrl, a refused fetch) leaves the document on its previous version and the key free, so a retry with it uploads again.
timeoutSecondsNoMax seconds to wait for processing (5-120, default 60).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=true, and the description substantiates both: version history is preserved, previous version is restored on import failure, and idempotencyKey semantics are spelled out for pre- and post-import failures. It adds permission requirements (publisher_required), quota behaviours (storage_quota_exceeded, plan_limit exemption), status transitions to 'preparing', and the withheld AI-summary billing detail.

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

Conciseness3/5

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

The purpose and source routes are front-loaded and organised as a numbered list, which helps. But the text runs to well over a thousand words and repeatedly restates mutation, quota and idempotency behaviour, so many sentences duplicate facts already given in the schema or earlier in the description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter destructive mutation with no output schema, the description covers the return shape verbatim ({ docId, shareId, shareUrl, status, version, uploadId, optimized, warnings, creditsRemaining }) and the meaning of unchangedFromPrevious, identical, supersededBy, fellBackTo and failureCode. Nothing needed to call it safely appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with rich per-parameter descriptions and the 'exactly one of' constraint, so the schema already carries most semantics. The description still adds value by ranking the six source arguments by transfer cost and explaining size ceilings per route (50MB vs 16MB vs 3MB post-optimization).

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?

Opening sentence states a specific verb and resource: 'Replaces the PDF of an existing document'. It immediately distinguishes the tool from siblings by naming the alternative behaviours: lnkdrp_stage_pdf for drafts and lnkdrp_share_pdf for new documents, plus lnkdrp_update_from_source for remote-source refresh.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It enumerates six sourcing routes in order of fewest transfers and states which tool handles each fallback (lnkdrp_drive_search, lnkdrp_create_upload, lnkdrp_create_upload_link). It explicitly routes draft-review cases to lnkdrp_stage_pdf and explains when an archived, received-copy, or in-flight document makes the call fail rather than succeed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources