Skip to main content
Glama

Upload Media Batch

postly_upload_media_batch
Idempotent

Uploads up to 50 files with bounded concurrency and a 30-second overall deadline. Returns completed, processing, failed, not_started, or unknown for every item with its stable idempotency key. Unknown uploads may still complete; reconcile stored media or retry with the same key.

Input Schema

NameRequiredDescriptionDefault
workspace_idNoDestination Media Library workspace ID. Omit to use the oldest available writable workspace within this connection. Check media_library in the result for its workspace_id and registration status.
media_uploadsYes

Output Schema

NameRequiredDescriptionDefault
codeNo
failedNo
messageNo
resultsNo
unknownNo
completedNo
elapsed_msNo
processingNo
not_startedNo
all_succeededNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / media_uploads / items / properties / workspace_id
      Added value: +{
      +  "description": "Destination Media Library workspace ID. Omit to use the oldest available writable workspace within this connection. Check media_library in the result for its workspace_id and registration status.",
      +  "type": "string"
      +}
    • addedInput schema / properties / workspace_id
      Added value: +{
      +  "description": "Destination Media Library workspace ID. Omit to use the oldest available writable workspace within this connection. Check media_library in the result for its workspace_id and registration status.",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • addedOutput schema / properties / processing
      Added value: +{
      +  "items": {
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  3. Changed4 schema fields changed
    • addedOutput schema / properties / elapsed_ms
      Added value: +{
      +  "type": "integer"
      +}
    • addedOutput schema / properties / not_started
      Added value: +{
      +  "items": {
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / results
      Added value: +{
      +  "items": {
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / unknown
      Added value: +{
      +  "items": {
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  4. Added

TDQS

A4/5.0
Behavior5/5

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

Annotations only declare idempotency and an open-world, non-destructive profile. The description goes well beyond that by disclosing bounded concurrency, a 30-second overall deadline, the full set of per-item terminal states (completed/processing/failed/not_started/unknown), and the fact that 'unknown' uploads may still land server-side. That is exactly the partial-failure semantics an agent needs and cannot get from structured fields.

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?

Three sentences, zero filler, and the most decision-relevant facts (batch limit, deadline, per-item statuses, retry rule) are front-loaded in that order. Every clause carries information an agent acts on.

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

Completeness4/5

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

An output schema exists, so the description is not obligated to explain return values, yet it still summarizes the status vocabulary and the reconciliation path, which is helpful. The main gap is the absence of any statement about auth/permission needs or how this relates to the single-file upload tool, which matters for a write operation with openWorldHint.

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 50%, and the schema itself already documents workspace_id, url, data, file, and file_name in detail. The description only reinforces the idempotency_key concept ('stable idempotency key'), adding little about the media_uploads item shape or the workspace_id fallback. This is the baseline case where the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Uploads up to 50 files') and quantifies the batch scope, so an agent immediately understands this is the bulk variant. It never names the sibling postly_upload_media, so the batch-vs-single distinction is left for the agent to infer from the tool name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives real recovery guidance for the 'unknown' outcome ('reconcile stored media or retry with the same key'), which is genuinely useful. However, it never states when to choose this batch tool over the single-file postly_upload_media sibling, nor any precondition such as the workspace requirement, so routing between the two is left implicit.

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