Skip to main content
Glama

Upload HelpCenter Image

helpcenter_upload_image

Upload an image — a screenshot, a diagram, an animated GIF — to the help center, and get back a stable public URL to embed in an article.

This is step one of two. Step two is writing the returned URL into an article's content as an (helpcenter_create_article, helpcenter_update_article, or helpcenter_stage_article_changes for a published article). The response hands you a ready-to-paste snippet: image.snippets.html is an tag, image.snippets.markdown the markdown form for content_format: 'markdown'.

Send the image ONE way:

  • data_base64: the file's bytes, when you hold the file.

  • source_url: the https address of an image already on the web. HelpCenter.io downloads it itself, so nothing large passes through this call. It must be reachable without signing in, on a public host, over https at every redirect, and answer within 15 seconds.

An image already on the web can also go straight into an article: an pointing at another host, written with helpcenter_create_article, helpcenter_update_article or helpcenter_bulk_create_articles, is copied into the help center's own storage when the article is saved (the write's response reports it under 'images'). Use source_url here instead when you want the image's help-center URL before writing the article, or one copy for several articles.

Requires a write-scoped API key. JPEG, PNG, GIF (animated too) and WebP only — SVG is refused. The API checks the file's bytes, not its name, mime_type or address.

SIZE: data_base64 takes at most 4,194,304 bytes (4.0 MB) decoded, which is 5,592,408 base64 characters. That is this hosted server's limit, set by the size of one request it can receive; the API itself takes up to 10 MB, and a self-hosted stdio server has no cap of its own. A larger file is refused before anything is sent — shrink it (crop, scale down, or re-encode a screenshot as JPEG/WebP, a long GIF as fewer frames) and retry. source_url is not held to this limit, because the image never passes through this server: the API's 10 MB applies.

With dedupe on (the default), retrying the same bytes returns the existing image (reused: true, HTTP 200) — for source_url too, once downloaded. With dedupe: false, a retry can create a second copy; check the image list before repeating an uncertain upload.

Always pass alt_text, describing what the image shows — it is what screen-reader users get instead of the picture. It is baked into the returned snippet only; it is not stored with the image.

Args:

  • data_base64 (string): the file's bytes, base64 (standard alphabet; a data URL is accepted). Send this or source_url.

  • source_url (string): an https address the API downloads the image from. Send this or data_base64.

  • filename (string, required with data_base64): e.g. 'billing-settings.png'. Leave it out with source_url, whose image is named after the address.

  • mime_type ('image/jpeg' | 'image/png' | 'image/gif' | 'image/webp', optional, data_base64 only): defaults to the data URL's type, else the filename's extension.

  • alt_text (string, optional, max 255): see above.

  • dedupe (boolean, optional): default true.

Returns: { status: "success", reused, image: { id, url, filename, mime_type, size, checksum, alt_text, snippets: { html, markdown }, created_at } }. HTTP 201 for a new image, 200 when an identical one was reused.

Errors: 403 if the key is read-scoped; 422 if the file is not a supported image or is over the API's 10 MB; 422 if the image at source_url could not be imported — the error says why (not https, a private or unreachable address, too slow, too large, not an image) and nothing was uploaded; 429 past 60 uploads a minute.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "helpcenter_upload_image"
  }
}

Input Schema

NameRequiredDescriptionDefault
dedupeNoDefault true: bytes this help center already uploaded resolve to the existing image instead of a second copy, so a retried upload is safe. Set false to force a new copy.
site_idNoWhich help center to act on: an id from helpcenter_list_sites. Needed when this connection reaches more than one help center; omit it when it reaches one. Applies to this call only — pass it on every call of a task, and ask the user which help center they mean if their request does not say.
alt_textNoWhat the image shows, for readers who cannot see it. Baked into the returned <img> snippet; NOT stored with the image.
filenameNoFile name, e.g. 'billing-settings.png'. Required with data_base64; stored and shown, never used as a path. Not with source_url, whose image is named after the last part of the address's path.
mime_typeNoType of the file, with data_base64 only. Optional: defaults to the data URL's type, else the filename's extension. The API checks the bytes themselves either way.
source_urlNoThe https address of an image already on the web, e.g. 'https://example.com/screenshots/billing.png'. HelpCenter.io downloads it itself, so its bytes never pass through this tool call. Send this OR data_base64, never both; with it, leave filename and mime_type out.
data_base64NoThe file's bytes, base64-encoded (standard alphabet; line breaks are ignored). A data URL (`data:image/png;base64,...`) is accepted too. Send this OR source_url, never both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description adds substantial context beyond that: write-scoped key requirement, accepted formats with SVG refused, byte-level validation, the 4 MB server cap vs the API's 10 MB, 429 after 60 uploads/minute, and dedupe-on retry semantics that effectively soften the idempotentHint=false flag. It stops short of describing what a failed partial state looks like, but the mutation profile is well covered.

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?

Front-loaded with purpose and the two-step framing, then method choice, then limits, then dedupe, then args and errors in scannable blocks. It is long and duplicates several schema descriptions nearly verbatim (alt_text, filename, mime_type), which is waste for an agent that sees both, but the size-limit and error sections earn their space.

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 supplies the full return shape (reused flag, image object, snippets.html/markdown) plus status-code semantics (201 new, 200 reused). Combined with concrete error conditions (403, 422 variants, 429), an agent has everything needed to call this correctly and to interpret both success and failure.

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 baseline is 3, and the description still adds real meaning: the 4,194,304-byte decoded cap on data_base64 and its base64-character equivalent, the requirement that source_url be public, https at every redirect, and answer within 15 seconds, and the note that alt_text is baked into the snippet but not stored. Some of it merely restates schema text (filename's required-with-data_base64 rule), which keeps it off a 5.

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 opening sentence states a specific verb and resource ('Upload an image ... to the help center') and the outcome ('get back a stable public URL to embed in an article'), which separates it cleanly from sibling read tools like helpcenter_get_image or helpcenter_list_images. It also distinguishes the upload path from the inline <img src> path handled by helpcenter_create_article.

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 frames itself as 'step one of two' and names the follow-on tools (create_article, update_article, stage_article_changes). It gives a clear either/or rule for data_base64 vs source_url and then an explicit when-to-prefer-each rule versus writing an <img src> into an article -- 'use source_url here instead when you want the image's help-center URL before writing the article, or one copy for several articles.'

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