Skip to main content
Glama
Sign In
MCP Hub

MCP Hub

by airano-ir
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

WordPress: Upload media chunked start

wordpress_upload_media_chunked_start

Start a chunked upload session for a large media file to get a session_id and optional upload URL for sending raw bytes, avoiding large base64 in tool calls.

Instructions

[UNIFIED] Start a chunked upload session for a large media file. Returns a session_id for finish/status/abort. On per-user MCP endpoints it also returns a relative upload_url so an agent can PUT raw bytes with curl --data-binary @file, using the same Bearer token, instead of embedding large base64 in tool calls. Use the chunk tool only as the fallback path. TTL 1h, hard cap 500 MB per session.

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": {
      "site": "<site>",
      "filename": "<filename>",
      "total_bytes": "<total_bytes>"
    },
    "name": "wordpress_upload_media_chunked_start"
  }
}

Input Schema

NameRequiredDescriptionDefault
mimeNo
siteYes
sha256No
filenameYes
total_bytesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.13.1

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only declare the mutation/safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false); the description adds substantive context beyond that: session TTL of 1h, a hard 500 MB per-session cap, the returned session_id, the conditional upload_url, and that the same Bearer token authorizes the byte PUT. These are exactly the operational constraints an agent needs before starting a long upload.

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 the core action and return value, then the transport preference, then the numeric limits. Dense but every sentence carries distinct information; only the '[UNIFIED]' tag and the slightly compressed phrasing of the curl clause cost it a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The lifecycle, expiry, size cap, and auth story are complete for a session-start tool with no output schema, so an agent knows what it gets back and how long it has. However, with zero schema description coverage on five parameters, the definition leaves a real gap on how site, mime, and sha256 should be supplied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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

Schema description coverage is 0% across five parameters, so the description carries the full burden, and it explains none of them. The 500 MB cap loosely implies total_bytes and 'large media file' hints at filename, but site, mime, and especially sha256 (an integrity check whose presence usually implies verification behavior) are left entirely undefined.

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 ('Start a chunked upload session for a large media file') and immediately clarifies its role in a multi-call flow by naming the sibling tools it hands off to (finish/status/abort). The agent can distinguish this from the chunk, base64, and URL upload siblings without opening any schema.

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?

Explicitly routes the agent: prefer returning a relative upload_url and PUTting raw bytes with curl, and 'Use the chunk tool only as the fallback path.' That is a real when-to-use/when-not-to-use rule against a named alternative. It stops short of contrasting with wordpress_upload_media_from_base64 or from_url, but the size-based framing implies the split.

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