LinkDrop

Create drop

lnkdrp_create_campaign

Same as lnkdrp_create_drop, under its earlier name: the same arguments and the same answers. 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.

Input Schema

Name	Required	Description
`cc`	No	Addresses on Cc of every person's email (up to 5), as a real Cc on that one email. Each is a plain address, once; one equal to a person's own address is left off that person's email, and the sender's own address is refused at Send. Everyone on Cc gets the recipient's email as it is, with that recipient's own link, so their opens count as that recipient's.
`name`	Yes	The drop's name (1-80 characters, one line).
`docId`	No	The document each person gets their own link to (24 hex chars), for a template with no links of its own. Give docId or projectId, or neither when the template has links.
`emails`	No	People picked directly, by address (up to 100): an address that is not a contact yet becomes one, named by name when given. Each is a plain address or { email, name }.
`listIds`	No	The contact lists it sends to (up to 20 ids, from lnkdrp_list_contact_lists); each person once, however many lists they are on.
`projectId`	No	The project each person gets their own link to (24 hex chars), for a template with no links of its own. Give docId or projectId, or neither when the template has links.
`contactIds`	No	People picked directly, by contact id (up to 100, from lnkdrp_list_contacts); a person also on one of its lists is on it once.
`projectIds`	No	The projects the drop is filed under (up to 20 ids); not what it links to.
`templateId`	Yes	The email template it sends (24 hex chars), from lnkdrp_list_email_templates.
`visibility`	No	private: only its owner sees the drop. team: everyone in the workspace sees it. A private list or template keeps it private.
`description`	No	What the drop is for (up to 500 characters).

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so safety is covered. The description adds genuinely non-structured domain context — that each recipient gets their own tracked link to each template document and mail is sent from the member's own Gmail — but it says nothing about side effects of creation itself, such as whether auto-created contacts are persisted or whether duplicate drops are allowed (idempotentHint=false implies not).

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?

Two sentences, front-loaded with the alias relationship, followed by compact domain context for 'drop'. Nothing is redundant, though the second sentence is dense and could be split for readability.

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

Completeness3/5

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

For an 11-parameter mutation with no output schema, the definition defers almost everything to the sibling's contract ('same args, same answers'), which is a reasonable shortcut but leaves the return value vague and gives no deprecation policy. The parameter space is fully covered by the schema, so the gap is mainly around which tool to call and what comes back.

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

Parameters3/5

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

Schema description coverage is 100%, so all 11 parameters are already documented in detail, including constraints and semantics. The description only says 'the same arguments', adding no meaning beyond the schema. Baseline 3 applies.

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 first clause anchors the tool to lnkdrp_create_drop ('same arguments, same answers'), so an agent can infer the create-a-drop verb plus resource without opening the schema. The second sentence defines what a drop actually is, which further secures the purpose. It stops short of a direct verb+resource statement of its own, relying on the sibling name to carry that weight.

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

Usage Guidelines2/5

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

'Under its earlier name' hints that this is a legacy alias, but the description never states the selection rule — nothing tells the agent to prefer lnkdrp_create_drop or when this name should still be used. With two behaviorally identical siblings in the list, an agent has no basis to choose between them.

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

All LinkDrop tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?