Skip to main content
Glama
thenavidm

substack-mcp

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Upload an image

upload_image

Upload an image to Substack's CDN and get a URL for post bodies or cover images. Accepts PNG, JPEG, GIF, WebP up to 10MB from a URL or absolute local path.

Instructions

Upload an image to Substack's CDN and get back a URL you can use in a post body or as a cover image.

Give exactly one of url or path. PNG, JPEG, GIF and WebP are accepted, up to 10MB. HEIC and SVG are not.

The returned URL is unlisted rather than secret: anyone who has it can fetch it, even before the post is published.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoAn http(s) URL to download and re-host. Private, loopback and link-local addresses are refused.
pathNoAbsolute path to an image on the machine running this server. Use this for a locally generated image. Must be absolute, since a relative path would resolve against the server's working directory rather than yours.
post_idNoAttach the image to a specific post or draft id.
publicationNoWhich connected publication to act on, matched loosely against its hostname (for example 'example.substack.com' or just 'example'). Defaults to the first connected publication.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.0.1
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv2.1.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare this is a non-readonly, non-idempotent, open-world write, so the safety profile is covered. The description adds genuinely new context beyond them: accepted formats, the 10MB ceiling, and the important note that the returned URL is unlisted-not-secret and fetchable before publication.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, each doing distinct work: purpose, parameter rule, constraints, security caveat. The most decision-relevant facts are front-loaded with zero filler.

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?

With no output schema, the description still explains the return value (a URL), and it covers inputs, format limits, and the privacy semantics of the result. Nothing 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.

Parameters4/5

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

Schema coverage is 100%, so the per-parameter docs already carry the load (baseline 3). The description adds the mutual-exclusivity rule for url vs path, which the schema does not express, plus format/size limits, lifting it slightly above baseline.

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 ('Upload an image to Substack's CDN') and immediately names the output ('get back a URL you can use in a post body or as a cover image'). No sibling overlaps with image hosting, so an agent can select this unambiguously.

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?

Gives the key usage constraint ('Give exactly one of url or path') and the downstream purpose (post body or cover image). It doesn't explicitly route away from an alternative, but no competing upload tool exists among the siblings, so there is little to exclude.

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

Deploy Server

Other Tools