Skip to main content
Glama

Create an email image upload link

lnkdrp_create_email_asset_upload_link
Idempotent

Creates a one-time page on the LinkDrop site where the signed-in person adds one image for HTML email templates (a GIF, PNG, JPEG or WebP file, up to 25 MB) from their own browser. This is the route for an image attached in a chat: a chat attachment has no public address for sourceUrl, and a real image is far too long to copy into dataBase64. Works in every client, with no network access from the agent's environment; needs the person to open the link. The image is checked and stored exactly as lnkdrp_upload_email_asset stores one: the type is read from the file's bytes (SVG and other types are refused), an image up to 10 MB is kept as it is and a bigger one is made smaller to fit, a PDF or other document is refused with a sentence saying to share it as a link, and the workspace's 200-image cap and upload limits apply; the page shows the workspace's limits, and a refused file leaves the link working for another, with a note saying the limit and what to do. name becomes the image's name and alt text; without it the file's name is used. The link works once, for 60 minutes, only for the LinkDrop account this connection acts as, in this workspace, and stops working if this connection's key or sign-in is revoked. Returns { uploadLinkId, url, expiresAt, kind, name, status, next }; lnkdrp_check_upload_link with uploadLinkId answers asset { assetId, url, imgTag, ... } once status is ready. At most 10 upload links per person wait unused in a workspace at once, PDF and image links together (rate_limited).

Input Schema

NameRequiredDescriptionDefault
nameNoA name for the image (1-120 characters); its alt text in imgTag. Without it, the file's name.
idempotencyKeyNoOptional. Without it, an identical call from this connection within 10 minutes returns the upload link the first call made (replayed: true) instead of making another, so a retry after an error or a dropped connection makes no duplicate. A key holds that promise for 24 hours; a new key makes a second upload link with identical settings.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the one-time 60-minute validity, account/workspace scoping, revocation behavior, file validation rules, 10 MB resize behavior, 200-image workspace cap, rate limit of 10 waiting links per person, and what happens after a refused file. This is unusually complete behavioral context for a write-capable tool whose annotations only say it is non-readonly, non-destructive, idempotent, and closed-world.

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 description is front-loaded with the core action and the condition that selects it. It is long and dense, but most clauses carry necessary behavioral constraints, validation rules, or return/next-step information that would otherwise be missing because there is no output schema.

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 complex upload-link creation tool with no output schema, the description includes the returned fields and explicitly names lnkdrp_check_upload_link with uploadLinkId as the follow-up. It also covers constraints, permissions, expiration, and failure behavior, leaving little an agent needs to infer before calling it.

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 both parameters are already well documented. The description repeats the 'name becomes image name and alt text' behavior, which is useful reinforcement but adds little beyond the schema, and it does not explain idempotencyKey behavior beyond what the schema already states. Baseline 3 is appropriate when the schema carries parameter semantics.

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?

The description states a specific verb and resource: creates a one-time upload-link page for adding an image to HTML email templates. It clearly distinguishes this route from lnkdrp_upload_email_asset and from dataBase64/sourceUrl approaches, so an agent can identify it without opening sibling schemas.

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 explicitly says when to use this tool: an image attached in chat lacks a public sourceUrl and is too long for dataBase64. It also explains the operational context that the agent has no network access and the signed-in person must open the link, which is decisive for correct tool selection.

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