GoodSender

Upload Post Image

upload_post_image

Upload an image for a blog post. Send the file bytes as base64 — works in local and hosted MCP. Converted to WebP and stored; returns a stable HTTPS URL. Allowed types: JPEG, PNG, GIF, WebP. Max 10 MB decoded.

A URL this tool returned for this workspace is the only one the API accepts as a cover or an author photo. The URL also works for in-body images. Markdown is not restricted by the API, but external, guessed or placeholder image URLs may not render, and local file paths are not publicly accessible.

The URL has three independent uses, and setting one does not set the others:

COVER. CoverImageURL on create_post or edit_post: the post page/card/social-metadata/newsletter image, described by CoverImageAlt.
AUTHOR PHOTO. AuthorAvatarURL on create_post or edit_post: the photo beside the byline and the author's image in structured data.
BODY ILLUSTRATION. Insert it into Markdown as where the text earns it — a diagram or figure that shows something the prose cannot.

It takes real image bytes, such as a file the user supplied. Nothing else substitutes for them: the blog renders markdown with raw HTML disabled, so inline SVG and fenced mermaid blocks publish as visible literal text rather than as a picture. A markdown table or a structured list is the correct way to carry a comparison or a set of figures.

A body illustration's alt text describes what the image SHOWS. It is what screen readers announce and what appears when the image fails to load; the filename is only a fallback. For the cover, that description goes in CoverImageAlt on create_post/edit_post, and is omitted when the cover only decorates the title.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ContentType": "<ContentType>",
      "DataBase64": "<DataBase64>"
    },
    "name": "upload_post_image"
  }
}

Input Schema

Name	Required	Description
`Filename`	No	Optional original filename, used as a hint for alt text. A descriptive name (retry-queue-latency.png, not image1.png) is the fallback when the alt text is thin.
`DataBase64`	Yes	Raw base64 image bytes, no data-URL prefix - strip any leading data:image/png;base64, before sending. Max 10 MB decoded. These must be real image bytes you actually hold, from a generated image or a file the user supplied; there is no way to synthesise them from a description.
`ContentType`	Yes	MIME type of the bytes you are sending: image/jpeg, image/png, image/gif, or image/webp. SVG is NOT accepted, and would not render even if it were - the blog escapes raw markup.

Output Schema

Name	Required	Description
`URL`	Yes	Stable HTTPS URL of the stored WebP. Assign it as a post's cover via create_post/edit_post's CoverImageURL, as the author's photo via their AuthorAvatarURL, or insert it into Markdown as ![alt](url) for an in-body illustration - the placements are independent.
`Bytes`	Yes	Stored WebP size in bytes.
`Width`	Yes	Stored image width in pixels.
`Height`	Yes	Stored image height in pixels.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

changedInput schema / properties / Filename / description

Previous value: -"Optional original filename, used as a hint for alt text. Give it a descriptive name (retry-queue-latency.png, not image1.png) - it is the fallback when the alt text is thin."New value: +"Optional original filename, used as a hint for alt text. A descriptive name (retry-queue-latency.png, not image1.png) is the fallback when the alt text is thin."

First observedNov 2, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotent=false, destructive=false and openWorld=true, so the mutation and non-idempotency profile is covered. The description adds real value beyond that: silent conversion to WebP, a 10 MB decoded cap, accepted MIME types, and the critical constraint that only URLs minted by this tool for this workspace are accepted by the API. However, it says nothing about overwrite/duplicate behavior on repeated uploads or storage lifetime, which matters for a non-idempotent write.

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?

Core action, transport and limits are correctly front-loaded, and the bulleted three-uses block is scannable. But roughly half the text is cross-tool guidance about CoverImageURL, AuthorAvatarURL and Markdown insertion that belongs with create_post/edit_post, and the SVG/mermaid caveat is restated across both description and schema. It is longer than a 3-parameter upload tool needs.

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?

Limits, accepted types, encoding, and the authoritative-URL constraint are all covered, and an output schema exists so return-value shape need not be explained here. Nothing an agent needs in order to call the tool correctly is missing.

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 coverage is 100%, so all three parameters are documented in-schema, including the data-URL stripping rule and the content-type enum. The description reinforces the 'must be real bytes you actually hold' constraint and links Filename to alt-text fallback semantics, but adds little beyond what the schema already spells out. Baseline 3 applies.

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 up front: 'Upload an image for a blog post,' followed immediately by the transport mechanism (base64) and the result (WebP + stable HTTPS URL). This distinguishes it from the sibling blog_design_image_upload_url, which by name suggests a URL-based upload flow rather than byte 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 says when to use it and what it must not be substituted with: real image bytes only, no SVG, no fenced mermaid, no guessed or placeholder URLs, no local paths. It also enumerates the three downstream uses (cover, author photo, body illustration) and states that setting one does not set the others, which is a genuine disambiguation an agent could otherwise get wrong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All GoodSender tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.