Skip to main content
Glama

Upload email image

lnkdrp_upload_email_asset

Uploads one image for HTML email templates (a GIF, PNG, JPEG or WebP file) and stores it at a public address. An image up to 10 MB is kept exactly as uploaded, on every plan; over 5 MB the answer carries sizeNote (it may load slowly on phones). A bigger file is made smaller automatically, because big images make emails slow to open and more likely to be clipped or land in spam (at most 600px wide, then fewer colours and frames, or lower quality; a GIF stays animated), and the answer carries original { size, width, height } and resizedNote. A sourceUrl or an upload link's page takes a file up to 25 MB; dataBase64 up to 5 MB. One email shows at most 10 images, 20 MB in all; a template saved over that has its images made smaller until it fits. A PDF or other document is not an email image: unsupported_content_type with details.document true. lnkdrp_share_pdf uploads a PDF and makes its share link; lnkdrp_create_share_link makes a link to a document already in LinkDrop. A template carries a document's link through a {{link.url}} or {{link.}} slot. lnkdrp_whoami reports this workspace's limits (capabilities.emailImages). Every image refusal says the limit, why and what to do, with details.limits { perImageBytes, perEmailBytes, imagesPerEmail, workspaceImages }. An image attached in a chat fits neither source (it has no public address, and its base64 is far too long to copy faithfully): lnkdrp_create_email_asset_upload_link makes a one-time page where the person adds it from their browser. An HTML template shows only images uploaded to this workspace; any other source is refused when the template is saved (details.code image_not_an_asset). The source is exactly one of sourceUrl (an https address LinkDrop fetches itself) or dataBase64 (the file's bytes, a data: URL prefix allowed; up to 3 MB when this server talks to a hosted LinkDrop). The type is read from the file's bytes, not its name: SVG and other types are unsupported_content_type, a larger file, or one that cannot be made small enough, too_large, and a workspace keeps up to 200 images (validation with details.code assets_limit) and uploads up to 60 an hour and 300 a day, deleted ones included (rate_limited). A sourceUrl LinkDrop cannot fetch, or that answers an error, is validation with details.code source_unavailable. Returns the image's assetId, name, url, contentType, size, width, height and imgTag: a ready element with the address, alt text from name, width and a style that keeps it inside a narrow mail client, for a template body. Each call stores a new image, even of the same file.

Input Schema

NameRequiredDescriptionDefault
nameNoA name for the image (1-120 characters); its alt text in imgTag.
sourceUrlNoAn https address of the image, up to 25 MB; LinkDrop fetches it.
dataBase64NoThe image file's bytes as base64 (up to 5 MB, 3 MB to a hosted LinkDrop); a data:image/...;base64, prefix is accepted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / dataBase64 / description
      Previous value: -"The image file's bytes as base64; a data:image/...;base64, prefix is accepted."New value: +"The image file's bytes as base64 (up to 5 MB, 3 MB to a hosted LinkDrop); a data:image/...;base64, prefix is accepted."
    • changedInput schema / properties / sourceUrl / description
      Previous value: -"An https address of the image; LinkDrop fetches it."New value: +"An https address of the image, up to 25 MB; LinkDrop fetches it."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the annotations: discloses per-source size caps (25 MB URL, 5 MB base64, 3 MB to hosted LinkDrop), the 10 MB-kept-as-uploaded vs >5 MB sizeNote threshold, automatic downscale rules (600px, colour/frame/quality reduction, GIF stays animated), 200-image workspace cap, 60/hour and 300/day upload rate limits, per-email image and byte budgets, and that each call creates a new asset even for the same file — contextualising the non-idempotent annotation.

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 opening sentence front-loads purpose well, but the body is a single dense block of run-on sentences with deeply nested parentheticals covering limits, errors, alternatives and return shape. Nearly all content is load-bearing, but the lack of grouping or paragraph breaks makes it hard to scan and some error-code detail is buried mid-clause.

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?

No output schema exists, and the description documents the return payload (assetId, name, url, contentType, size, width, height, imgTag and its construction) plus the main failure modes (unsupported_content_type with details.document, too_large, validation/assets_limit, rate_limited, source_unavailable). Nothing material an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description adds real meaning: sourceUrl must be https and is fetched server-side, dataBase64 accepts a data: prefix and has a different cap when talking to a hosted LinkDrop, the type is sniffed from bytes rather than the filename (SVG rejected), and name becomes the imgTag alt 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?

States a specific verb and resource ('uploads one image for HTML email templates') plus accepted formats and that it is stored at a public address. It is clearly separable from lnkdrp_share_pdf (PDFs), lnkdrp_create_share_link (existing documents) and lnkdrp_create_email_asset_upload_link (browser-based one-time upload).

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?

Explicitly routes to alternatives: PDFs go to lnkdrp_share_pdf, existing documents to lnkdrp_create_share_link, chat-attached images (no public URL, base64 too long) to lnkdrp_create_email_asset_upload_link, and workspace limits to lnkdrp_whoami. It also states the source must be exactly one of sourceUrl or dataBase64, which is a use-shape rule, not just a schema fact.

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