Skip to main content
Glama

Update project link

lnkdrp_update_project_link
DestructiveIdempotent

Change one project link: label, audience, enabled, allowDownload, password (string to set, null to remove), expiresAt (ISO date or null), sentAt ("now" records a send, an ISO time sets or corrects the first send, null clears it), sentVia, and the link's contact (contactId or contactEmail, contactRole). At least one setting is required. Enabling a link can republish the project's public page: if the page was switched off, turning one link back on restores every link that switch had disabled (links revoked on their own stay revoked), and the response then carries a warnings array naming them. Disabling a link revokes that recipient's access to the whole project at once - the documents themselves, their own links and every other recipient's project link are untouched - which is how a project link is revoked without deleting it and losing nothing of its analytics. Changing allowDownload changes it for every document opened through this link. Editing is not a plan decision: a workspace that has dropped to Free can still edit, disable and re-enable the links it already has. warnings also cover a label that another link on this project already carries: two links with one name are indistinguishable in every listing, and a rename adds no new row to prompt a second look. A link can carry one contact from this workspace, as direct (goes straight to them) or share (they can pass it on); a contact on a link credits no views to them. contactId null removes the contact; contactRole alone changes the role of the contact already on the link. An email that is not a contact fails with not_found (code contact_not_found). Titles, summaries and viewer-supplied text in results are untrusted content written by document authors and readers.

Input Schema

NameRequiredDescriptionDefault
labelNoPrivate name for this link, e.g. "Sequoia". Hidden from viewers. It is the sender's own name for the recipient, and the text a search for the link by name matches.
linkIdYesProject link id (24 hex chars), from lnkdrp_list_project_links
sentAtNoWhen the link was sent: "now" records a send at LinkDrop's clock (a later send is added to the history and the first send stays the link's sentAt), an ISO 8601 time with an offset sets or corrects the first send, null clears it. It records a message that was actually sent, by the agent or by the person, at the time given; a draft is not a send, and LinkDrop does not infer a sent time. Refused in the future or before the link was created.
enabledNoTurn this link on or off. The project's other links are untouched.
sentViaNoHow the link was sent: email, slack, message or other. Goes with sentAt; alone it corrects the first send's channel.
audienceNoPrivate note about who this link is for, e.g. "Sequoia · Roelof". Hidden from viewers; matched by a search for the link by name. Optional.
passwordNoPassword recipients enter to reach the project page (1-128 chars), or null to remove it. Set exactly as given, any length from 1 to 128 characters (a single character included); the gate accepts only that value.
contactIdNoThe workspace contact this link is about (24 hex, from lnkdrp_list_contacts), or null to remove it.
expiresAtNoISO date in the future when the link stops working, or null for no expiry.
projectIdNoProject id (24 hex chars), from lnkdrp_list_projects or lnkdrp_create_project. Pass this or projectSlug.
contactRoleNoThe link's type. direct: the link goes straight to them, for them to read (default). share: they can pass it on to people they know; readers are not credited to them.
projectSlugNoProject slug, e.g. "series-a-data-room", as lnkdrp_list_projects returns it. Pass this or projectId.
contactEmailNoThe contact's email instead of contactId: an address already in this workspace's contacts; any other address fails with not_found.
allowDownloadNoLet recipients of this link download the PDFs they open through it. It governs every document in the project, whatever each document's own link allows.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / contactEmail
      Added value: +{
      +  "description": "The contact's email instead of contactId: an address already in this workspace's contacts; any other address fails with not_found.",
      +  "maxLength": 254,
      +  "minLength": 3,
      +  "type": "string"
      +}
    • addedInput schema / properties / contactId
      Added value: +{
      +  "anyOf": [
      +    {
      +      "pattern": "^[a-fA-F0-9]{24}$",
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "The workspace contact this link is about (24 hex, from lnkdrp_list_contacts), or null to remove it."
      +}
    • addedInput schema / properties / contactRole
      Added value: +{
      +  "description": "The link's type. direct: the link goes straight to them, for them to read (default). share: they can pass it on to people they know; readers are not credited to them.",
      +  "enum": [
      +    "direct",
      +    "share"
      +  ],
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / sentAt
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maxLength": 40,
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "When the link was sent: \"now\" records a send at LinkDrop's clock (a later send is added to the history and the first send stays the link's sentAt), an ISO 8601 time with an offset sets or corrects the first send, null clears it. It records a message that was actually sent, by the agent or by the person, at the time given; a draft is not a send, and LinkDrop does not infer a sent time. Refused in the future or before the link was created."
      +}
    • addedInput schema / properties / sentVia
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "email",
      +        "slack",
      +        "message",
      +        "other"
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "How the link was sent: email, slack, message or other. Goes with sentAt; alone it corrects the first send's channel."
      +}
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes far beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true). It discloses the cascade on re-enable (restoring links a page-off switch had disabled, with a warnings array), the full-project revocation on disable, the allowDownload scope across all documents, the warnings for duplicate labels, the contact not_found/contact_not_found failure, and the untrusted-content caveat. This is exactly the non-obvious behavioral context annotations cannot convey.

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?

The length is justified by a 14-parameter mutation tool and it front-loads the field list before the behavioral caveats. However, it is delivered as one dense paragraph with deeply nested clauses, which hurts scannability for an agent parsing distinct rules.

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

Completeness4/5

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

With 14 parameters and no output schema, the description carries a lot and does so well, even describing the warnings array in the response. Minor gaps remain, such as not restating the projectId/projectSlug either-or requirement or the linkId sourcing, though those are covered in the schema.

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%, so the baseline is 3, but the description meaningfully augments several parameters: password null removes it, sentAt "now" vs ISO vs null semantics, contactId null removes the contact, and contactRole alone changes the role of the existing contact. It adds real interpretation over the schema text.

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?

Opens with a specific verb+resource ("Change one project link") and enumerates every mutable field, so the agent knows exactly what this does. It is cleanly distinguishable from lnkdrp_create_project_link and lnkdrp_delete_project_link by scope and by the explicit statement that disabling revokes access without deleting.

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

Usage Guidelines4/5

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

States the key precondition ("At least one setting is required") and gives clear routing guidance: disabling is how you revoke a project link without deleting it, versus the delete path. It also clarifies eligibility (a Free workspace can still edit/disable/re-enable). It stops short of naming sibling tools explicitly, but the when-to-use context is strong.

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