Skip to main content
Glama

upload_image

Put an image from a public https link into the account's Mailercloud content library and get its hosted address, to use in create_dnd_email_template, edit_dnd_email or create_template. PNG, JPEG or GIF, up to 3 MB and 4000 pixels a side; up to 100 uploads an hour per account. Use dry_run: true to check the image first.

Input Schema

NameRequiredDescriptionDefault
dry_runNoCheck the image without uploading it
image_urlYesPublic https address of a PNG, JPEG or GIF image, up to 3 MB and 4000 pixels a side

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only declare the safety profile (not read-only, open-world, non-idempotent, non-destructive); the description goes further with format/size/pixel caps and a 100-uploads-per-hour rate limit, which are traits an agent cannot see elsewhere. It does not say what happens on repeat uploads of the same URL, leaving the non-idempotent hint unexplained.

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 compact sentences, front-loaded with the action and result, then constraints and the dry_run tip. Some format/size text duplicates the schema, but the density is proportionate to the information conveyed.

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, yet the description tells the agent what is returned (a hosted address usable in other tools), along with input constraints, rate limits and a validation path. An agent has everything needed to call this correctly.

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 documented including the https/format/size constraints. The description largely restates the image_url constraints and only adds a light clarification of dry_run's purpose, which earns the baseline 3 rather than more.

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 (put an image into the account's content library) plus the concrete outcome (get its hosted address). It also ties the result to named downstream consumers, so an agent can tell immediately what this tool is for versus the template-creation siblings.

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?

Explicitly names the follow-up tools (create_dnd_email_template, edit_dnd_email, create_template) and prescribes a dry_run pre-check, which is real usage guidance. It stops short of stating when not to use it or what to do instead for non-public/non-https images, so no exclusions are given.

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