Skip to main content
Glama
Sign In
Paperboy CMS

Paperboy CMS

Official
by hybriden
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_upload_link

Get a 15-minute link for uploading LOCAL files (images, PDFs) into the media library — the way to upload files on your own machine, which this server can't read. POST them as multipart/form-data with the returned header, e.g.

Instructions

Get a 15-minute link for uploading LOCAL files (images, PDFs) into the media library — the way to upload files on your own machine, which this server can't read. POST them as multipart/form-data with the returned header, e.g. with curl (several -F file=@… per request is fine). The response lists each stored asset's documentId: set it on an image field with set_field, and give it alt text with update_asset_alt. The link uploads as you, into this site (pass site to upload into another), and expires after 15 minutes. Returns {uploadUrl, headers, expiresAt, example, limits}: PNG, JPEG, GIF, WEBP or PDF, max 5 MB per file, up to 20 files per request. Refused when the server has no PUBLIC_URL configured — then use upload_asset with dataBase64. For a file at a public URL, or a stock photo, use upload_asset instead. Requires the content.create permission (Admin, Editor, Author — an Author only within their own sections).

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": "create_upload_link"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteNoSite slug or id to act in (multisite). Omit to use this server's default site. Call list_sites to see what exists — an empty tree or search usually means the wrong site, not missing content.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only assert a non-read-only, non-destructive, non-idempotent write; the description goes well beyond them by disclosing the 15-minute expiry, the multipart/form-data POST with a returned header, per-file and per-request limits (5 MB, 20 files), supported formats, the PUBLIC_URL refusal condition, and the required content.create permission with role scoping.

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?

The purpose is front-loaded in the opening clause, and the remaining text is information-dense with no filler: each sentence contributes a usage rule, a constraint, or a follow-up step. Nothing here could be removed without losing an operational detail.

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?

Despite having no output schema, the description enumerates the exact response shape ({uploadUrl, headers, expiresAt, example, limits}), the accepted media types, size/count limits, auth requirements, and the refusal/fallback path. For a single-parameter tool with safety already covered by annotations, this leaves nothing an agent needs unstated.

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?

With a single parameter at 100% schema description coverage, the baseline is 3. The description adds actionable meaning beyond the schema by clarifying the multisite behavior ('The link uploads as you, into this site (pass `site` to upload into another)'), which gives an agent the reason to set the parameter.

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 first sentence states a specific verb and resource ('Get a 15-minute link for uploading LOCAL files ... into the media library') and immediately frames its niche versus the nearest sibling by contrasting local-machine files with the server's inability to read them. An agent can distinguish this from upload_asset without opening either schema.

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?

It explicitly names when to use this tool (files on your own machine), when not to (public URL or stock photo -> use upload_asset instead), and the fallback condition (server has no PUBLIC_URL configured -> upload_asset with dataBase64). It even cross-references set_field and update_asset_alt for the follow-up steps.

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