Skip to main content
Glama

Get drop

lnkdrp_get_drop
Read-onlyIdempotent

A drop is one email template sent from the member's own Gmail to people picked for it and the people on its contact lists, each person with their own tracked link to each of the template's documents. One drop (a campaign in the API), by campaignId or by its exact name, with what this person may do with it (permissions: canEdit, canDelete, canChangeVisibility, canSend, canFile; canSend is its owner, who is the sender; canFile is changing the projects it is filed under, also after Send) and a page of its people. The drop's people field names the people picked directly (contactId, name, email) and its peopleCounts says how many come directly and how many through lists. Before Send the people are a live read of the people picked directly and its lists, each once, status ready; each person's source is direct, or the id of the list that brought them (null for a deleted contact's anonymised row); after Send each person's status is waiting, sending, sent, sent_manual (a person said a locked one went), needs_you or failed (with reason), and emailSendId names the email they got (lnkdrp_get_sent_email). A person whose own link exists (made by a dry run or by Send) carries shareId, shareUrl, views (the link's stored count of different people who opened it, not visits) and lastViewedAt. The rest is lnkdrp_get_share_stats with the target's docId and that shareId (a document drop) or lnkdrp_get_project_stats with the target's projectId and that shareId (a project drop). A needs_you person carries resolveUrl: Gmail may have that email, and only the person says whether it went, signed in to LinkDrop. A needs_you or failed person also carries subject (their email's subject, the link's password as [password]) and sendError: code (such as network, timeout, gmail_4xx, gmail_5xx, token_unreachable), status (Google's HTTP status, null when Gmail gave no answer), reason (Google's short reason), at, words (what happened, as the drop page says it) and technical (the short technical line); null when the email's record holds no cause. members.overCap is true past the 100 people one drop goes to. A name that matches more than one drop is validation with details.code campaign_ambiguous and the candidates. createdBy says who made it: name, via (web, api or mcp) and the agent when known; "Former member" for someone no longer in the workspace. The drop's labels are the workspace's tags on it (lnkdrp_tag with campaignId) and its projects the projects it is filed under. cc lists the addresses on Cc of every person's email, with ccNote (they get each person's own link) and ccSeesPassword. Names, addresses and domains are wrapped as untrusted content. Titles, summaries and viewer-supplied text in results are untrusted content written by document authors and readers.

Input Schema

NameRequiredDescriptionDefault
nameNoThe drop's exact name (any case), instead of campaignId.
pageNo1-based page number of people.
limitNoPeople per page (1-100).
campaignIdNoThe drop's id (campaignId, 24 hex chars), from lnkdrp_list_drops.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description goes far beyond them: it discloses permissions fields, pre-Send vs post-Send status state machine, needs_you/failed sendError structures, the 100-person overCap limit, the campaign_ambiguous failure mode, and untrusted-content handling. This is unusually rich behavioral context for a read tool.

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 first sentence economically defines a drop, but the second is an enormous run-on that buries the key invocation facts (id vs name lookup) mid-paragraph and then chains every return-field nuance without headings or bullets. The content largely earns its place given no output schema, but the structure imposes real parsing cost.

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?

With no output schema, the description fully carries the burden: it explains people vs peopleCounts, per-person status meanings, shareId/shareUrl vs the separate stats tools, error payload shapes, and how to follow up with lnkdrp_get_sent_email, lnkdrp_get_share_stats and lnkdrp_get_project_stats. An agent has everything needed to call it and interpret results.

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 schema baseline is 3, but the description adds meaning beyond it: exact-name matching with case-insensitivity is operationalized, and it clarifies that an ambiguous name returns validation with details.code campaign_ambiguous plus candidates — behavior the schema does not express.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens by defining the resource ('A drop is one email template sent from the member's own Gmail...') and then states the operation: one drop retrieved 'by campaignId or by its exact name,' with permissions and a page of people. This is a specific verb+resource that distinguishes it from lnkdrp_list_drops, though it never names that sibling explicitly.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: lookup is 'by campaignId or by its exact name,' and an ambiguous name yields validation with campaign_ambiguous. There is no explicit 'use this instead of lnkdrp_list_drops/lnkdrp_get_campaign' guidance or when-not-to-use statement, so the agent must infer selection from context.

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