Skip to main content
Glama

Upload an image from a web address

upload_image_from_url

Upload an image the site fetches from an https address (the editor’s “from a web address”), with its licence, credit and source, stored as a new image (a lossless WebP at its full resolution, colour profile kept, other metadata dropped). The image is public at /img/w/…/ once stored, before any review — unless you set hold: true, which stores it held for a proposal: /img serves it only to you and to reviewers (never cached), it is in no list, and only your own proposal may name it, until a reviewer approves that proposal and releases it. A rejected or withdrawn proposal leaves it held, never deleted. The real run answers its mediaId: pass it to propose_entry_change as image_media_id to propose it for an entry. Refused (url_upload_disabled) while an admin has switched uploads from a web address off. Audited, with the address. Dry run by default; every run needs confirm_rights: true.

Input Schema

NameRequiredDescriptionDefault
urlYesThe image’s own https address (the file itself, not the web page it is on). The site fetches it; this tool never does.
holdNotrue: store it held, for a proposal (see above). Pass the mediaId to propose_entry_change as image_media_id.
creditNoWhom to credit, as shown beside the image — the author or rights holder. Needed by the licences that say so.
sourceNoWhere you found the image (a web page), kept for a rights question; never shown publicly. Left out, the address it was fetched from is kept.
dry_runNotrue (the default): write nothing — show the change and the exact request it would send. false: make the change.
licenseYesHow the image may be reused: "cc0-1.0" (CC0 1.0), "public-domain" (Public domain), "cc-by-4.0" (CC BY 4.0, needs a credit), "cc-by-sa-4.0" (CC BY-SA 4.0, needs a credit), "supplied" (Supplied by the subject, needs a credit), "permission" (Used with permission, needs a credit), "none" (No licence, only with the upload-unlicensed permission).
confirm_rightsYestrue: you confirm the image may be published under this licence.

Output Schema

NameRequiredDescriptionDefault
noteNoA dry run: what to do next to make the change, in words.
resultNoA real run: the route’s own answer, where the tool adds facts of its own beside it.
confirmNoA dry run of a change that needs it: the exact target to send back as `confirm` with dry_run: false.
dry_runNotrue: a dry run, which wrote nothing. Absent from a real run.
replayedNoA real run with an idempotency_key already used for this change: the first call’s answer, given back; nothing was written now.
would_sendNoA dry run: the exact request the real run would send (`method`, `path`, any `headers` such as an Idempotency-Key, and its `body`, `form` or `query`), or the requests, in order.
may_edit_liveNoA dry run of a live edit: whether this key’s account may edit this entry live.
refused_becauseNoA dry run the real run would be refused for: why, in words.

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?

With annotations already covering readOnly=false, openWorld=true, idempotent=false, and destructive=false, the description adds substantial behavior: public storage at /img/w/…, held-image visibility restrictions, non-deletion after rejected proposals, audit logging, dry-run default, disabled-state refusal, and required rights confirmation.

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 core purpose is front-loaded and the dense paragraph contains little filler. It is long, but the length is mostly justified by the number of state transitions and constraints it must disclose.

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 mutation tool with an output schema, the description is complete enough to call safely: it covers storage format, visibility, hold semantics, proposal integration, rejection behavior, dry-run defaults, disabled-state refusal, and audit logging.

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 already defines the parameters thoroughly. The description still adds workflow meaning beyond the schema, especially the hold/proposal interaction with propose_entry_change and the significance of dry_run and confirm_rights.

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: it uploads an image the site fetches from an https address and stores it as a new lossless WebP. It also clearly distinguishes this from sibling uploads by naming the editor’s “from a web address” flow and explaining the site-side fetch.

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?

It gives clear usage context: use this for an image at an https address, use hold: true when storing for a proposal, and pass the returned mediaId to propose_entry_change. It does not explicitly contrast with upload_image or search_commons_images, so it stops short of full alternative routing.

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.